jamie at FreeBSD.org
Thu May 14 17:44:25 UTC 2009
Julian Elischer wrote:
> Jamie Gritton wrote:
>>> prison0 contains three fields that were system globals: pr_root,
>>> pr_host, and pr_securelevel. I've kept the globals rootvnode and
>>> hostname, and take care that when one is changed the other changes too
>>> (not yet true for hostname - read on). But I've actually removed the
>>> global securelevel, instead forcing people to use securelevel_gt() and
>>> securelevel_ge() (or in very rare cases to check prison0.pr_securelevel
>>> directly). I chose to do that because while using the global rootvnode
>>> and hostname may be incorrect, using the wrong securelevel is, well,
>>> insecure. Actually it would be insecure to use the wrong rootvnode too,
>>> but I'm not convinced removing that global is worth the headache.
> not sure why you want to keep hostname a true global
> It seems to me that it is an eminently virtalizable property.
> though possible a special hostname might exist for the base system
> for error messages etc.
> kind of like V_hostname an G_hostname :)
It was mostly for the number of times I saw that global being used -
didn't want to upset the order of things too much. I didn't see nearly
as much use of securelevel with the advent of securelevel_ge() and
securelevel_gt(). But I suppose the G/V_hostname thing has already
gotten that ball rolling.
There is at least one place that uses the global securelevel directly
(i.e. prison0.securelevel). The same could be done for hostnames, which
does a pretty good job of pointing out that this is the global hostname
being used. Because you're right - the hostname is at the center of of
what it means to have a jail identity.
Then there's rootvnode, the third global that's superseded by
hierarchical jails. I could also remove that, allowing the use of
prison0.pr_root for those who need the real root.
More information about the freebsd-virtualization