Re: Alternative user management approach

[Russell Coker <russell@xxxxxxxxxxxx>]

On Saturday 25 June 2005 20:28, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
> Ok this all sounds good, but how do we come to a consensus.
>
> Do we need an "role attribute" to define "user" roles.

I think we need a role attribute to solve the problem of the ugly 
in_user_role() macro.

> roleattribute staff_r user;
> roleattribute user_r user;
> roleattribute sysadm_r user;
>
> Then do we need a mechanism in policy to associate roles with "user" roles?

Firstly I think we should stick to the established terminology for the moment.  
We have SE Linux identities which determine the roles that are permitted, and 
we have a mapping mechanism to determine the SE Linux identity from the Unix 
UID.  The current mapping mechanism is to look for a match between the Unix 
account name and a SE Linux identity and use that identity if it exists, 
otherwise use "user_u".  We are talking about having a config file using 
user-name and group-name.

The group-name thing could become fun if we have multiple names for the same 
GID (it's not recommended but it works at the moment) and the GID is the 
primary group for some users.  The Unix user-name is unambiguous as we start 
with the name for every operation AFAIK.

> How does all this work with MLS ranges?

How does it cause problems with MLS?

> Do we have a new file which associates uids to user roles?

Unix account names not UIDs.  I think a mapping file is the only way.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.