> > >   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.
> 

It seems reasonable to amend this case to say:

        1.
        Any process with priv_sys_resource running in the global zone's
        system project (project 0) will not subject to project.* or zone.*
        resource controls.  System daemons which wish to be subject to the
        global zone's resource controls can drop priv_sys_resource.

        2.
        The "user.root" project will be removed, and root's default project
        will be set to the "system" project via /etc/user_attr.

I'm not sure if (2) can be delivered via patch.  I need some guidance here.
I'm also not sure how implementable (1) is until I do more investigation.

-Steve

> Gary..
>       
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to