Given a lack of supportive feedback, I'm going to revoke the proposed amendment
below. To mitigate a zone admin setting a problematic swap limit on the global
zone, we will enhance zonecfg to:
1. Print a warning when setting swap (and lwp) limits on the global
zone. Since the swap limit will not go into effect until reboot,
the admin has a change to modify his setting before it takes
affect.
2. Enforce a reasonable minimum when setting swap (and lwp) limits
on the global zone.
Currently, the rctl framework provides many mechanisms by which the admin
can make the system difficult to manage. For instance, setting task.max-lwps
on project "user.root" can prevent root login. If we want to make changes to
prevent admins from resource-controlling their way out of the box, I think we
need a broader case to address the whole problem.
-Steve
On Tue, Oct 31, 2006 at 03:24:18PM -0800, Steve Lawrence wrote:
> > > > 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
