On Fri 13 Oct 2006 at 02:04PM, Brian Kolaci wrote:
> [EMAIL PROTECTED] wrote:
> >>I propose that zlogin be split into two different programs, one
> >>for console access and one for running programs and/or shell.
> >>A simple way to do this (and would be backward compatible) would be to
> >>create a hard link to zlogin, say 'zconsole' that when it is executed
> >>the program can test arg0 and automatically apply the -C functionality
> >>if it is called zconsole.  This would allow better separation of
> >>duties and allow two different profiles in exec_attr to differentiate
> >>what zone administrators can do.
> >
> >
> >There have been some discussion of using SMF authorizations with zones
> >to provide this level of control.  One CR of interest is
> >
> >    4963290 RFE: implement flexible zone administration that
> >        doesn't require uid=0
> >
> >dsc
> 
> I believe the RFE covers quite a bit of this and seems to
> be most of what the customer is looking for.  However the functionality
> of zlogin should still be split into two different programs or somehow
> devise a way to allow one set of users that can do 'zlogin -C' for console
> access and another group of users that can get regular 'zlogin' direct
> access.

RBAC would allow this-- AFAIK you simply need to make the program in
question be RBAC-aware.  SMF commands like 'svcadm' are an example of
this-- if you have a particular authorization, you can manipulate a
particular service.

> Its the all-or-nothing of zlogin that is currently at question.
> If you can specify via RBAC two different profiles, one for 'zlogin -C'
> and another with normal 'zlogin', then at least you can separate the access
> control out via RBAC.  If you can't, then it should be split to two
> separate programs.

We certainly never imagined a world in which console access would
be OK, but non-console access would not be.

You should probably add a call record to 4963290 for your customer.  Or
mail me the name of the customer, contact details, etc, and I will do it
for you.  Just to set expectations, we're not likely to get to this in
the short term unless there is a significant outcry for this-- we're too
heavily engaged in other priorities.  We'd be supportive of someone in
the wider community who wished to take a cut at this, but I expect it to
be non-trivial.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to