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. Thanks, Miklos -- 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
