[rsbac] To-Do List for 1.2.3

Peter Busser peter at adamantix.org
Sun Sep 28 19:53:17 MEST 2003


> > - Are access rights supposed to change when the file gets renamed (or a new 
> > name created and the old deleted)?
> Right now I see the problems caused by software upgrades important, and from
> that point of view, it's best if permissions depend on path, not inode.
> Other than that aspect, again neither path nor inode based approach seems
> clearly superior.

Well, you don't have to solve every little problem in the kernel code. If you
want to set permissions based on a path, then you can write a utility that will
do that for you.

I did that for instance with the RSBAC policy support tool, which is part of
Adamantix unstable.

> But I don't want to give X programs any rights to any subdirs of ~. Hence, I
> don't want subdirs of ~ to inherit its rights.

You mean that if you start a web-browser, you cannot even save files to your
home directory? Or you cannot access the home directory when you start a
virtual shell?

> Now I agree that the "skip inheritance" flag would make the system much more
> complex. That's bad. At the same time, in absence of path based permission
> system, I can't come up with any feasible solution for the ~/.Xauthority
> problem.

You can simply skip the inheritance by setting the attribute to the value you

> And about the RC type numbers - I'm thinking they are much too visible. 
> When I create an RC type, I'm really not interested in what number it's
> going to get. Same goes for RC role numbers ofcourse, maybe also to some
> other such rsbac numbers.

That is also something that I put in the RSBAC policy support tool. You specify
RC roles, types and rights by name and the tool deals with all the numbering

Peter Busser
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world

More information about the rsbac mailing list