OK, I see I've fallen into the "What does running SRSS in a local zone
mean?" trap again.
Some custs, e.g. an ASP, might like to run multiple SRSS on a server, in
separate zones, to provide isolation for different customers.
Some custs, e.g. a development house, might like to run SRSS in a
*global* zone, but log users into separate zones. That's very
different, and seems to be what you're describing.
It's important to consider these separately - their design would seem to
have little in common. We've had requests for both and I'm sure we can
find lots of people who want each of these flavors. I'm less certain
how many would be satisfied with lack of audio and devices. In fact,
our strategy is going the other way - providing better access to
devices, since that seems to be our key differentiator.
Also, please never underestimate the impact of playing the "it's only a
small matter of software" card :)
-Bob
Jim Klimov wrote:
Hello Bob,
Wednesday, November 12, 2008, 5:53:02 AM, you wrote:
BD> Dave McGuire wrote:
On Nov 11, 2008, at 1:09 PM, Bob Doolittle wrote:
Most of our users aren't interested in running in environments where
devices are unavailable - they might as well be using VNC for such
situations...
BTW, considering the bonuses (and overhead) of VNC, was there
any comparison, even if personally subjective, concerning the
performance of native Sun Ray XServer de-jour vs. VNC added
in the middle? Does it lag or is it invisible?
Huh? I know quite a few people using Sun Rays, and NONE of them use
devices.
BD> Not even audio? That requires a device.
Concerning device creation:
I too think it's a small price for running SRSS in a zone.
Again, SSGD does it ;)
We don't use audio, but primarily because most of our users
use uttsc, and video streams from sites like youtube or movie
player applications lag and squeak (ultimately lagging 4 secs
behind as was noted on the list, due to RDP issues) and the
related screen-updates often cause SunRay session disruprions,
at least when I use it from home via our town LAN (but I wrote
on this a couple of months back).
We also rarely use storage mapping, because current Solaris
pcfs lacks support for non-7bit-ASCII characters in filenames,
and our USB thumb drives contain Russian-named files every now
and then (so whole directories appear empty). Alas, I couldn't
convince my colleagues that Russian doesn't exist in IT - thus
USB drives don't exist for them now ;)
Concerning the general concept of SRSS in Solaris local zones:
If we consider the developers' scenario I suggested earlier,
these developers would be roots in their own private zones
(kind of like private virtual WinXP's in VDI setups).
If this scenario is used for an office or for some browsing
kiosks (non-root users), the root-related security issues or
complications you mentioned would be minimal, and principal
inability to create devices might even be a security bonus
and/or a resource-saver on server side.
Besides, services in a local zone running as root are indeed
running as, well, root. Whatever security at filesystem- or
process- level is needed - it is there. Perhaps some Solaris
OS capabilities are not implemented in the local zones' kernel
side, but many such features are simply disabled by default
and can be enabled by global zone's administrator thru the
local zone's attributes (and perhaps its reboot).
One issue that possibly remains is the global zone root user's
access to any local zone's data, but in such zoned scenarios
the global zone's tasks are usually limited to administrative
access anyway. So the global zone becomes rather a hypervisor
or RSC-type of a remote control/management interface for the
local zones. And the zone won't start anyway if its filesystem
root is not "chmod 700" and owned by "root:root", according to
similar security considerations.
If root (or any-user) access to the global zone running SRSS
instances in local zones is restricted just as much as it is
restricted on a standalone global-zone SRSS server, I don't
think this should be any more security threat at all.
But we get the bonus of, for example, zone-root migration to
a more capable or suitable server whenever needed. In some
of our darker practice, we can even have different package
versions in local and global zones, since migration doesn't
always dictate upgrading. (One exception we've had so far
were ZFS libraries an utilities, and those influenced the
specific case of mounting ZFS datasets delegated to a zone)
To summarize, while the issues you mentioned concerning the
use of SRSS in local zones are really quite serious in general,
there are - in practice - quite many setups and users to whom
these issues are irrelevant or not applicable.
IMHO, after some limitation/checks introduced into SRSS code,
it can quite run in local zones lacking e.g. storage and audio
devices, and it might even be a benefit in certain use-cases.
There may be efficiency- and migration-related bonuses, and
root-related security issues can be disregarded in some cases
as not adding a threat level (unless someone finds a way to
break out of a zone, I don't know of such examples as of yet).
Am I dead wrong? ;)
It might not even take very much coding, just a few if()'s
added here and there, and "not-supporting" such a platform
for a while would ease field-testing and not burden your QA
team - kinda like SRSS working sometimes on certain releases
of OpenSolaris Nevada when we're lucky...
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
