Gary Winiger wrote: > Sorry, just catching up, so I may be repeating stuff already covered and > I know I've gotten long winded. > > Gary.. > ====== > First off, what seems to me to be necessary is a clear definition of > the target use for the OpenSolaris live CD install. It seems like it > could range anywhere from the high school student on a $500 single user > laptop to the multi-user enterprise customer in a highly secure environment > (think banking where it's your personal $$ that will be lost). > > IMO, they may have entirely different requirements. What is the vetted > requirements document for the project? >
The graphic installer on the live CD is oriented at desktop/laptop users. The forthcoming text installer is oriented at server-class systems. > Secondly, it seems to me a clear definition of the administrative model > for OpenSolaris is needed. This also could range from sudo/su root does > everything to the administrative user is granted a set of authorizations > and commands that let them setup just what can be done by whom without > having to resort to running interactively with privilege. > > IMO, they may be at different ends of the of the spectrum. What is the > vetted administrative model for OpenSolaris? At one time I was told that > Craig Payne was the Engineering manager in charge of defining the model. > Some engagement there would be helpful. I've heard little of that in the 2 years we've worked on building OpenSolaris releases. Absent other engagement, the anticipated direction has been essentially what you refer to below as "MacOS X style". Dave > Without these two areas vetted, any suggestions may need significant > adjustment. > > Reading snippets from Greg Lavender and Bill Nesheim today: > Greg: > Our job is to continue to advance Solaris as the market leading > enterprise OS, exploiting Sun hardware innovations, as well as create > innovative OS-based technologies that enable market winning integrated > software+hardware systems, such as the S7000 family of storage > appliances and other that are to be determined. > > Bill: > I intend to call our new organization Solaris Platform Engineering. I > believe that this is a very suitable name both in the sense that we > continue to be responsible for delivering low level support for Systems > group Platforms, and also in the sense that the Solaris OS releases we > deliver serve as a stable Platform for application deployment. > > I'm not sure if they are targeting S10, OpenSolaris, Solaris Next with > their comments, but it would seem to me that the direction is more toward > the multi-user enterprise than the single user laptop. With that in mind, > my suggestions for the installed OpenSolaris, Solaris Next system are: > 1. /etc/default/login:PASSREQ=YES > 2. The current Nevada enforcement for PASSREQ=YES continue unchanged > 3. The installer require root to have a password -- see the > alternatives below. > 4. An initial user account be generated which requires a password. > That account is granted the root role and no explicit Rights > Profiles. > 5. That the user be given instructions how to set up a passwordless > "single user system" if they wish. > > That's pretty much how I manage my Solaris Boxes. > > An alternative is the Mac OS X style -- not using Solaris RBAC features as > the primary mechanism: > 1 and 2 as above > 3. Deliver root as a "no login" account. (passwd -N equivalent) > 4. An initial user account be generated which requires a password. > The initial account is given a user_attr(4) entry that grants the > "solaris.system.maintenance" authorization to the user. > (See PSARC/2008/321 No Root Login) > 5. The initial account is granted sudo(1m) access. > > I've not looked closely under the covers of Mac OS X, but that's > how it feels like Mac OS X works to me except Mac OS X does most things > through GUIs that require administrative authentication. > > And now my hoped for alternative which requires (and is aligned with) my > hoped for vetted administrative model: > 1 through 4 as directly above with slight modification that > the initial user is granted sufficient authorizations to configure > the system. > 5. administer the system by authorization driven interfaces that > provide separation of duties rather than the administer running > a shell with privilege.
