Messages in this thread | | | From | Bernd Eckenfels <> | Subject | Re: Filesystem Capabilities in 2.6? | Date | Sun, 3 Nov 2002 00:02:43 +0100 |
| |
In article <Pine.LNX.4.44.0211021025420.2413-100000@home.transmeta.com> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |