Dan Price wrote:
On Fri 13 Oct 2006 at 02:04PM, Brian Kolaci 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


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

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.

It seems like making it RBAC-aware may be complicated compared to
doing something similar to the live upgrade tools where many of the
commands are symbolic links to ludo.  I was thinking just leave zlogin
as it is, but create something like zconsole as a link to zlogin and
just have zlogin recognize it was invoked as zconsole and perform its
normal processing as if '-C' was added.

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.

The problem here is non-console access is unauthenticated and isn't logged.
So if you give someone console access, you also give them free root access
to all local zones.

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.


I'll discuss with the customer and add a call record, thanks !


zones-discuss mailing list

Reply via email to