Re: RC separation of duty

From: Vadim Kogan <vadim@scam.XCF.Berkeley.EDU>
Subject: Re: RC separation of duty
Date: Mon, 1 Nov 1999 12:54:22 -0800 (PST)

Next Article (by Subject): Re: RC separation of duty ao@morpork.shnet.org (A. Ott)
Previous Article (by Subject): Re: RC separation of duty ao@morpork.shnet.org (A. Ott)
Top of Thread: RC separation of duty ao@morpork.shnet.org (A. Ott)
Next in Thread: Re: RC separation of duty ao@morpork.shnet.org (A. Ott)
Articles sorted by: [Date] [Author] [Subject]

On 1 Nov 1999, A. Ott wrote:

> This is not restricted to *nix systems. Most commercial systems of all  
> types have no such concept. Very many even have an omnipotent admin  
> account.

NW4+.

> My concept is to give sub-admins control over role and type subsets. They  
> can change everything inside their subsets, but never leave it. Sure the  
> different subsets of separate roles can overlap, e.g. the default role 0  
> would be contained in several sets to get new users working in different  
> areas. Once they are in an area, other sub-admins have no control over  
> them anymore.

I think you're limiting yourself to roles, while you also have a nice ACL
with inheritance AND blocking mechanism. Think about how it's done in
NW4+.

In fact, in NW way things can go even funnier - you can have a container
with its own admin, in which there is a user who is NOT an admin in that
container, but IS admin in some other container (possibly even on higher
level).

Now, here's something that was discussed here before, but is not available
in NW: being able to have "50% admin" permissions to some container and
combine that with another "50% admin" permissions owned by another user
and get access to admin the container (and, unless there is blocking
involved, all objects in that container/subcontainers).

There is another plus in such "container" structure. It makes it easier to
present structure to user. I know you gonna scream that it's lame, but it
is really important to be able to have good UI.

I should also say that groups/roles are opposite of containers in most
part. Group is made to give many objects same control over something.
Containers can be used to give one object control over multiple objects.
That is groups are many-to-one and containers are one-to-many. Obviosly
either one can be extended to give both possibilities.

Unlike NW, we have a special container with subcontainers that is called
"kernel" - it got ttys, ports, devices, etc, etc, etc.

Ok, gotta get my ass to class ;-)

Vadim.

-
To unsubscribe from the rsbac list, send a mail to
majordomo@morpork.shnet.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.