> > > This will not help root logins directly, but could by setting:
> > > 
> > >   usermod -K project=system root
> > 
> >     Or perhaps deliver root's entry this way to start with.
> Would that be a reasonable change to make via patch?  Perhaps this change
> could be delivered to nevada, but not backported.
> It would be confusing to deliver this change, and also deliver the "user.root"
> project.  If we made root's default project "system", then the "user.root"
> project should be removed.  "user.root" is kind of a bug anyhow, as SMF does
> not run root services in "user.root".  Currently, only root processes spawned
> by login/pam run in "user.root".

> > > Perhaps this issue should be run as a seperate fasttrack?  I need to 
> > > investigate the implementation impact.
> > 
> >     I'm looking for this case to define how to preserve the current
> >     model of "unlimited" unless one asks for a limit model in the
> >     global zone.  I believe it is important from a system integrity and
> >     maintenance perspective.  Other's may have different opinions.
> >     If there is a compelling reason to deliver in phases, please discuss
> >     that.
> The global zone will have no swap limit by default.  The default zone.max-swap
> rctl delivered on the global zone is UINT64_MAX, which is essentially
> unlimited.  Is that what you mean?

        My point(s) here is not so much how things get done, but that
        the global zone is in some ways special.  IIRC, before this
        project, the GZ doesn't have a swap limit.  After this project
        an administrator could set swap limit on the GZ.  Granted this
        is administrative action and they get what they deserve/ask for.
        However, it seemed to me that part of this case "should" (my
        judgement) include some way to override the limit in case 
        override is really desired.  As implied, perhaps by putting
        root into project 0 at login or as part of daemon/service start
        is a way to bypass the administrator's choice in the GZ for
        some processes.  What I didn't see as part of this case is
        the architecture to allow this bypass.  Perhaps I'm off base
        for thinking it's necessary to protect against inadvertantly
        not being able to administer the system from the GZ.

zones-discuss mailing list

Reply via email to