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... -- Best regards, Jim Klimov mailto:[EMAIL PROTECTED] _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
