Re: Filesystem Capabilities in 2.6?

[Bernd Eckenfels]

In article <[e-mail]> you wrote:
> I think it was a mistake to have permissions be part of the inode in the
> first place, but that's UNIX for you. A direntry-based approach is _so_ 
> much more flexible, and doesn't really have any downsides. 

The main downside is the problem, that an object then can have multiple
different permissions and there is no easy way to ensure a basic level:

a- the kernel can't drop priveledges on a modified object easyly (this would
require your attribution to contain a version or checksumed reference)
b- the user can't drop/restrict a object once he knows that it's data is now
more sensitive (he has to worry about all old hard and softlinks to the
file)
c- how do you handle renames or moves of the data instances? move the
associated permissions of the moved entry and let all others point to nil
like breakign symlinks?

Greetings
Bernd