On Wed 14 May 2008 at 08:42AM, james hughes wrote: > > On May 14, 2008, at 2:13 AM, Dan Price wrote: > > >On Tue 13 May 2008 at 03:00PM, Gary Winiger wrote: > >>This project enables a policy where "root" can never be used > >>directly by > >>administrators as an account providing full system access. > >>In a Major release this policy may be made the default. > > > >To be clear: I'm agnostic about the goodness of this idea; I'm > >concerned that the defintion of "default" is not clear, and that the > >zones case has not been fully explored here. > > I hope the previous message helps with this...
Well it does in the sense that it provides the motivation and context. I was really trying to point out something different, but wasn't clear. It also doesn't answer my questions about sys-unconfig. To back up slightly to my confusion: The text of the case says: > In a Major release this policy may be made the default. This statement is vague-- if this case is approved, does that mean that a team working on a major release may make this the default without further review? Or does it mean that in the event of a major release, PSARC would see another case which effects this change? If the latter, then please rewrite: "This case does not set this policy as the default for the system. A future major release could adopt this policy as the default, although further architectural change will be required in order to support non-global zones and to alter existing installation technologies (if supported) to properly provision non-root users. Future cases will address this." There is a new requirement being placed on the installation technologies here-- when this policy is active, then delivering /etc/passwd from packages is no longer enough to provision the system-- and so when this policy is the default, wider changes are going to be needed. And that is what I think needs resolution here. There should be a clear specification of what an installer should do-- otherwise, you'll see all sorts of bizarre stuff happening with packages and install-time provisioning (as we saw in DP1 and DP2). > >In a sense, a zone is the "most pure" > >version of this problem, since it doesn't get much provisioned by an > >installer, really-- it just gets laid out on the system, and lets > >sysidtool do the rest. > > Agreed that the zone issue has not been fully explored and we should > do this before approving this case. I did create a zone on DP1 and ran > into this bug, and I seem to remember using "zlogin -S" or something > like that to get around the lack of a root password. Fixing this is > mandatory. Great! As an aside, DP1 zones support (and 2008.05 zones support for that matter) isn't really representative of anything other than a hack and slash attempt to get *something* working in the allotted time. It should not be regarded as architecture. For further background on how this issue has impacted zones, you may wish to review: http://defect.opensolaris.org/bz/show_bug.cgi?id=681 -dp -- Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp
