linux-kernel - Re: [PATCH -V16 04/12] vfs: Allow handle based open on symlinks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Jul 2010 18:56:31 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
CC:	miklos@...redi.hu, hch@...radead.org, viro@...iv.linux.org.uk,
	adilger@....com, corbet@....net, neilb@...e.de, npiggin@...e.de,
	hooanon05@...oo.co.jp, bfields@...ldses.org,
	linux-fsdevel@...r.kernel.org, sfrench@...ibm.com,
	philippe.deniel@....FR, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V16 04/12] vfs: Allow handle based open on symlinks

On Mon, 12 Jul 2010, Aneesh Kumar K. V wrote:
> On Mon, 12 Jul 2010 10:23:21 +0200, Miklos Szeredi <miklos@...redi.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@...ux.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 ?

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/