All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com,
	corbet@lwn.net, neilb@suse.de, npiggin@suse.de,
	hooanon05@yahoo.co.jp, bfields@fieldses.org,
	linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com,
	philippe.deniel@CEA.FR, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V16 04/12] vfs: Allow handle based open on symlinks
Date: Mon, 12 Jul 2010 15:12:07 +0530	[thread overview]
Message-ID: <87d3utyr2o.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <E1OYEIL-0005si-EO@pomaz-ex.szeredi.hu>

On Mon, 12 Jul 2010 10:23:21 +0200, Miklos Szeredi <miklos@szeredi.hu> 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@linux.vnet.ibm.com>
> > ---
> >  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 ?

> 
> Actually, open_by_handle() should be a good place to start supporting
> O_NOACCESS from the start.  I.e. neigher read, nor write access is
> permitted on the file.

Yes that would be ideal. But that will include much larger change. I was
hoping we could get something in this merge window with the change
suggested above ?

> 
> 
> > +			return -ELOOP;
> > +		if (flag != O_RDONLY)
> > +			return -ELOOP;
> > +		break;
> >  	case S_IFDIR:
> >  		if (acc_mode & MAY_WRITE)
> >  			return -EISDIR;

-aneesh

  reply	other threads:[~2010-07-12  9:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12  6:35 [PATCH -V16 0/12] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 01/12] exportfs: Return the minimum required handle size Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 02/12] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-07-12  8:15   ` Miklos Szeredi
2010-07-12  9:33     ` Aneesh Kumar K. V
2010-07-12 16:38       ` Miklos Szeredi
2010-07-12  6:35 ` [PATCH -V16 03/12] vfs: Add open by file handle support Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 04/12] vfs: Allow handle based open on symlinks Aneesh Kumar K.V
2010-07-12  8:23   ` Miklos Szeredi
2010-07-12  9:42     ` Aneesh Kumar K. V [this message]
2010-07-12 16:56       ` Miklos Szeredi
2010-07-12  6:35 ` [PATCH -V16 05/12] vfs: Support null pathname in readlink Aneesh Kumar K.V
2010-07-12  8:02   ` Miklos Szeredi
2010-07-12  6:35 ` [PATCH -V16 06/12] vfs: Support null pathname in faccessat Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 07/12] vfs: Support null pathname in linkat Aneesh Kumar K.V
2010-07-12  8:05   ` Miklos Szeredi
2010-07-12 10:58     ` Aneesh Kumar K. V
2010-07-12 17:05       ` Miklos Szeredi
2010-07-13  5:47     ` Matt Helsley
     [not found]     ` <E1OYE1D-0005qC-AI-8f8m9JG5TPIdUIPVzhDTVZP2KDSNp7ea@public.gmane.org>
2010-07-13  5:47       ` Matt Helsley
2010-07-12  6:35 ` [PATCH -V16 08/12] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 09/12] x86: Add new syscalls for x86_64 Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 10/12] vfs: Export file system uuid via /proc/<pid>mountinfo Aneesh Kumar K.V
2010-07-12  7:19   ` Aneesh Kumar K. V
2010-07-12  8:27     ` Miklos Szeredi
2010-07-12  6:35 ` [PATCH -V16 11/12] ext3: Copy fs UUID to superblock Aneesh Kumar K.V
2010-07-12  6:35 ` [PATCH -V16 12/12] ext4: " Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d3utyr2o.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@sun.com \
    --cc=bfields@fieldses.org \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=neilb@suse.de \
    --cc=npiggin@suse.de \
    --cc=philippe.deniel@CEA.FR \
    --cc=sfrench@us.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.