Hi! > > I believe AA breaks POSIX, already. rename() is not expected to change > > permissions on target, nor is link link. And yes, both of these make > > AA insecure. > > AA is supposed to allow valid access patterns, so for non-buggy apps + > policies, the rename will be fine and does not change the (observed) > permissions. That still breaks POSIX, right? Hopefully it will not break any apps, but... > > > If that is the only way to implement AA on top of SELinux - and so far, > > > noone has made a better suggestion - I'm convinced that AA has technical > > > merit: it does something the on-disk label based approach cannot handle, > > > and for which there is demand. > > What demand? SELinux is superior to AA, and there was very little > > demand for AA. Compare demand for reiser4 or suspend2 with demand for > > AA. > > SELinux is superior to AA for a certain scenario of use cases; as we can > see here, it is not superior to AA for _all_ use cases. The scenario where it does not seem superior is "I have system with AA here and I'd like to keep using it". > > > The code has improved, and continues to improve, to meet all the coding > > > style feedback except the bits which are essential to AA's function > > Which are exactly the bits Christoph Hellwig and Al Viro > > vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html > > . I believe it takes more than "2 users want it" to overcome veto of > > VFS maintainer. > > A veto is not a technical argument. All technical arguments (except for > "path name is ugly, yuk yuk!") have been addressed, have they not? There still is "it does not work with long pathnames". Plus IIRC we have something like "AA has to allocate path-sized buffers along every syscall". I guess Al Viro or Christoph Hellwig would be able to detail on that. I don't think they are vetoing stuff for fun. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
