[rsbac] To-Do List for 1.2.3

[Amon Ott]

On Sonntag, 28. September 2003 23:10 quoth Samuli Kärkkäinen:
> On Sun, Sep 28, 2003 at 10:56:20PM +0200, Peter Busser wrote:
> > > This is indeed one way to solve this issue. However if rsbac really
> > > were path based it would also solve the "~/.Xauthority problem" and
> > > remove the necessity of "restoring" all permissions after any rpm/deb
> > > update.
> >
> > Computers like numbers. Paths are not numbers. Therefore computers do not
> > like them. I-node numbers exist for a good reason. Any path-based access
> > control mechanism will be computer unfriendly. In other words: It will be
> > slow and cost a lot of memory. Therefore people will hate it.
> >
> > It would really be a nice idea if you could implement it efficiently.
>
> My belief is that unix uses heavily inodes mainly because hard links
> necessitate user visible inodes.

I think they use numbers, because they are smaller, faster and easier to 
handle.

> I imagine that rsbac needs to store a fairly small number of paths,
> basically only as many as there are settings for in the FD menu. That would
> be around 10-100. Hence the memory footprint should be neglible. Be it
> inodes or filesystem paths, they are likely stored in a hash table. Hence
> the performance different comes from having to compute a hash key of a path
> instead of a inode. Granted there is some difference there, but I suspect
> that's not enormous. After all kernel needs to do that stuff every time a
> file is opened/stat'd.

In my experience, all attribute objects sum up to a few thousand items, which 
would not be such a bad problem. Seaching would certainly be slower, because 
you would have to make more comparisons or compute a hash over the string, 
and path names would still be relative to mount points.

Amon.