On Mon, 12 Jul 2010, Aneesh Kumar K. V wrote: > On Mon, 12 Jul 2010 10:23:21 +0200, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Mon, 12 Jul 2010, Aneesh Kumar K.V wrote: > > > The patch update may_open to allow handle based open on symlinks. > > > The file handle based API use file descritor returned from open_by_handle_at > > > to do different file system operations. To find the link target name we > > > need to get a file descriptor on symlinks. > > > > > > We should be able to read the link target using file handle. The exact > > > usecase is with respect to implementing READLINK operation on a > > > userspace NFS server. The request contain the file handle and the > > > response include target name. > > > > > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx> > > > --- > > > fs/namei.c | 10 +++++++++- > > > fs/open.c | 9 ++++++++- > > > include/linux/fs.h | 1 + > > > 3 files changed, 18 insertions(+), 2 deletions(-) > > > > > > diff --git a/fs/namei.c b/fs/namei.c > > > index 4d590a3..a6a8093 100644 > > > --- a/fs/namei.c > > > +++ b/fs/namei.c > > > @@ -1456,7 +1456,15 @@ int may_open(struct path *path, int acc_mode, int flag) > > > > > > switch (inode->i_mode & S_IFMT) { > > > case S_IFLNK: > > > - return -ELOOP; > > > + /* > > > + * Allow only if acc_mode contain > > > + * open link request and read request. > > > + */ > > > + if (acc_mode != (MAY_OPEN_LINK | MAY_READ)) > > > > Why require MAY_READ? > > a value of 0x0 for flag in open(2) implies a read ? Yes. However a value of 0x3 is not defined in POSIX, and in linux it's a sort of weird O_NOACCESS: it requires both read and write permission on the file but allows neither read or write. Requiring permission is because on device files the open can have side effects. Not sure if open_by_handle() really wants to allow device opens, that's another thing to think about. 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