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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to