Darren J Moffat wrote: > Given that 2007/078 stores the hostid in /etc/hostid (for x86 only) was > any consideration given to just using the same mechanism for zones > rather than having a different one ? >
Yes, I considered it for a time but settled on the solution presented in the case because storing a non-global zone's hostid in its configuration file is consistent with the current way the zones subsystem works. Pertinent zone configuration information is stored in the zone's configuration file, so it seems natural to store hostid information there as well. Furthermore, splitting a zone's configuration across many files (say, the zone's XML configuration file in /etc/zones and the zone's /etc/hostid file) unnecessarily complicates zone configuration and booting. For example, suppose we want to configure a new zone with some hostid. If the zone does not already exist (i.e., if it is not installed), then where would we store the hostid? In the zone's configuration file. But if it will be stored in the zone's configuration file, then why create a separate /etc/hostid file for the zone later when the hostid is already accessible in the zone's configuration file? Storing a zone's hostid in an /etc/hostid file is superfluous. Additionally, James Carlson made a good point about the security provided by storing non-global zone hostids in their /etc/zone configuration files. Darren J Moffat wrote: > Why is it acceptable to have a zone's hostid in the clear in the global zone /etc/zone/<zonename>.xml for SPARC and x86 file yet it isn't acceptable to have the hostid in the clear in /etc/hostid for x86 - even when the source code for the silly obfuscation is open source. > What exactly is your concern? If it is the inconsistency between my case and PSARC/2007/078 in that /etc/hostid is obfuscated and non-global zone hostids (as stored in their configuration files) are not, then I agree that obfuscating the system's hostid is pointless given that anyone can examine the source and discover how to circumvent it. I am in favor of removing the obfuscation in /etc/hostid, but I hesitate to agree that this falls within the scope of my case. Brian Ruthven wrote: > Just to make sure this has been covered: > > PSARC/2007/078 (hostids for x86) mentions the legal implications of software licensing against hostids. This case proposes that the hostids are user-supplied, thus may need a Sun Legal check too. > > Brian > If I remember correctly (please correct me if I am misunderstanding your reference), the concern in the PSARC/2007/078 mail was that placing the system's hostid in an /etc/hostid ASCII file would not only invite more license circumvention, but also make it appear as though we (Sun) are encouraging license circumvention and thus betraying our ISVs that use hostids for licensing. Are you concerned that non-global zone hostid emulation might have similar consequences? If so, then I would argue that the concern is unwarranted in this case. We must remember that zones are configurable virtualized execution environments, like virtual operating systems. (I say this not because I think you do not already know it, but to focus our attention on the purpose of zones in order to make a more salient point.) They are *meant* to look and feel like machines distinct from their physical host. Emulating hostids is simply another way to customize the virtualized environments that zones provide so that system consolidation can be more easily facilitated with zones and zone migration across physical nodes can be more flexible when legacy licensed software is in jeopardy (as my case states). We are providing non-global zone hostid emulation for these reasons alone and should clearly state this in our documentation (as I made an effort to do in my proposed man page changes). It is possible that license circumvention might increase slightly with the introduction of non-global zone hostid emulation, but I doubt that it would be a significant increase. For one thing, faking hostids is already possible and easily accomplished (for example, see http://www.software.com/downloads/purchase/Solaris-Hostid-Controller-buy833075.html). If a user wants to circumvent hostid-based licensing, then he can do so today in a variety of ways at little or no cost (except perhaps two minutes of his time) with Sun-developed technologies. Adding non-global zone hostid emulation will not open any new doors to unscrupulous users. Additionally, using non-global zones for the sole purpose of circumventing licensing for a handful of programs is a relatively expensive solution to an easily-solved problem. Zones take disk space, cpu time, and memory, whereas a five- or six-line DTrace script that intercepts sysinfo(2) system calls is much cheaper. Non-global zone hostid emulation will not enlarge the hostid-based licensing circumvention problem that our ISVs already face. Furthermore, I claim that if users were to abuse hostid emulation to circumvent software licensing, a use which would not fall within our stated (documented) intentions for the technology, then we would not be responsible for their actions. If arguing that the potential for such abuse justifies rejecting non-global zone hostid emulation, then destructive DTrace scripting should be eliminated because of the ability it grants users to (easily) circumvent hostid-based software licensing. However, I imagine that we would not eliminate destructive DTrace scripting or consider providing it a betrayal of our ISVs because such abuses fall outside of the stated purposes for the technology. If that is the case, then non-global zone hostid emulation should be permitted as well. My two cents, Jordan
