Re: Single home directory type for all roles.

[Russell Coker <rcoker@redhat.com>]

On Thu, 2004-12-09 at 14:45 -0500, Daniel J Walsh wrote:
> >A bug IMHO.  If we have two roles that become almost equivalent then the
> >sensible thing to do is remove one.  If we decide that for Fedora strict
> >policy we don't want to have any regular users be denied the ability
> >perform administrative tasks then the correct thing to do is to make
> >staff_r the default user role.
> >
> I want to go back to the separation between user and staff without the 
> differences in file system.

That's impossible.  If you can write to someone's .bashrc file or
similar then you can get their privs.

> >It's easy enough for anyone to add a new role if they need more roles
> >than the default policy provides.
> >
> Not without relabing the file system.

The expected practice should be to create the role before creating the
user who will have it.  This means that there should not be a need to
relabel.  There is only a need to relabel if you change the roles that
are permitted after the machine has been running.  But that also means
you may have to have the user logout first to prevent processes becoming
unlabeled.

>   Currently if I want to add a new 
> role, say student that has less privs
> then user,  I need to massively rewrite the policy.  If we came up with 
> a policy that shared homedir and tmpdir
> file contexts between all types of users, I could begin to create 
> additional default roles for people.

For what benefit?  If they share file types and they share X access
(with xdm logins) then what benefits can we gain from multiple roles?

Multiple roles will still increase administrative overhead even without
multiple file types.  So multiple roles with the same types gives you
some of the overhead with almost none of the benefit.


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