linux-kernel - Re: [PATCH -V18 04/13] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20100823090604.6c735c80@notabene>
Date:	Mon, 23 Aug 2010 09:06:04 +1000
From:	Neil Brown <neilb@...e.de>
To:	Andreas Dilger <andreas.dilger@...cle.com>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Christoph Hellwig <hch@...radead.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	"adilger@....com" <adilger@....com>,
	"corbet@....net" <corbet@....net>,
	"npiggin@...nel.dk" <npiggin@...nel.dk>,
	"hooanon05@...oo.co.jp" <hooanon05@...oo.co.jp>,
	"bfields@...ldses.org" <bfields@...ldses.org>,
	"miklos@...redi.hu" <miklos@...redi.hu>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"sfrench@...ibm.com" <sfrench@...ibm.com>,
	"philippe.deniel@....FR" <philippe.deniel@....FR>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -V18 04/13] vfs: Allow handle based open on symlinks

On Sat, 21 Aug 2010 01:13:52 -0600
Andreas Dilger <andreas.dilger@...cle.com> wrote:

> On 2010-08-20, at 18:09, Neil Brown <neilb@...e.de> wrote:
> > How about a new AT flag:  AT_FILE_HANDLE
> > 
> > Meaning is that the 'dirfd' is used only to identify a filesystem (vfsmnt) and
> > the 'name' pointer actually points to a filehandle fragment interpreted in
> > that filesystem.
> > 
> > One problem is that there is no way to pass the length...
> > Options:
> >   fragment is at most 64 bytes nul padded at the end
> >   fragment is hex encoded and nul terminated
> >   ??
> > 
> > I think I prefer the hex encoding, but I'm hoping someone else has a better
> > idea.
> 
> That makes it ugly for the kernel to stringify and parse the file handles. 

We already parse filenames into components separated by '/'.  Is HEX decoding
that much more ugly.

Filehandles are currently passed between the kernel and mountd as HEX
strings, so at least there is some precedent.

> 
> How about for AT_FILE_HANDLE THE FIRST __u32 (maybe with an extra __u32 for alignment) is the length and the rest of the binary file handle follows this?  In fact, doesn't the handle itself already encode the length in the header?

That part of a filehandle that nfsd gives to the filesystem is one byte out
of a 4-byte header, plus the tail of the filehandle after the part that
identifies the filesystem.
This 'one byte' does imply the length, but it doesn't necessarily encode it.
Rather it is a 'type'.  So it cannot really be used to determine the length
at the point when the filehandle would need to be copied from userspace into
the kernel.

I don't think there is any precedent for passing a 4-byte length followed by
a binary string, while there is plenty of precedent for passing a
nul-terminated ASCII string.

[[ Following this approach I would like to avoid any filehandle-specific
syscalls altogether.
Just use a *at syscall with AT_FILE_HANDLE for filehandle lookup, and use
getxattr('system:linux.file_handle') to get the filehandle for a given path.

Ofcourse we would need to at *at versions of the *xattr syscalls, but that is
probably a good idea anyway.
]]

NeilBrown

> 
> Cheers, Andreas--
> 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/

--
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/