> > > 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:
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.
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.
zones-discuss mailing list