On Tue 2009-11-24 12:53:09, Miklos Szeredi wrote: > On Tue, 24 Nov 2009, Jeff Layton wrote: > > Since it's clear that these symlinks do need to have special semantics, > > perhaps the approach you suggest would be the best thing. I'll have to > > think about it a bit more. > > open() is not the only thing you need to think about. Anything that > checks read or write permission on the inode (truncate, utimes, > *xattr) would have to be changed to respect the open mode. > > See, this is not just about hacking the proc follow_symlink code to > check some lookup intent. It's about changing the permission checking > mechanism for theses beasts. And since the permission checking is > inode based, this is not at all trivial to do. > > I still believe leaving the current semantics and documenting them is > the best option. I believe that current semantics is ugly enough that 'documenting' it is not enough... and people want to port from other systems, too, not expecting nasty surprises like this... 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
