linux-kernel - Re: [PATCH -V19 00/15] Generic name to handle and open by handle syscalls

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]

Date:	Mon, 13 Sep 2010 00:52:27 +0530
From:	"Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	miklos@...redi.hu, hch@...radead.org, viro@...iv.linux.org.uk,
	adilger@....com, corbet@....net, neilb@...e.de, npiggin@...nel.dk,
	hooanon05@...oo.co.jp, bfields@...ldses.org, miklos@...redi.hu,
	linux-fsdevel@...r.kernel.org, sfrench@...ibm.com,
	philippe.deniel@....FR, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V19 00/15] Generic name to handle and open by handle syscalls

On Tue, 07 Sep 2010 15:24:29 +0200, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Tue, 07 Sep 2010, Aneesh Kumar K. V wrote:
> > On Tue, 07 Sep 2010 13:36:03 +0200, Miklos Szeredi <miklos@...redi.hu> wrote:
> > > On Tue, 07 Sep 2010, Aneesh Kumar K. V wrote:
> > > > Any update on this. Are you ok with syscall approach which is limitted to
> > > > CAP_DAC_READ_SEARCH  ?
> > > 
> > > My gut reaction is: "not another bunch of xattr syscalls!".  It
> > > doesn't feel right, this interface is too specialized to warrant a
> > > full set of filesystem syscalls.
> > 
> > 
> > Are you ok with rest of syscalls other than the handle based xattr one ?
> 
> No, not really.  Only xattrs stand out from the rest as the "API that
> shouldn't be" and adding more to that pile makes me feel especially
> bad.
> 
> But xattrs aside, I still don't think we need another interface for
> file handles that duplicates the existing filesystem APIs.
> 

As per your suggestion i started looking at handlefs details and below
is my take on the approach.

handlefs would be an internal kernel mount like pipefs and would have
inode object mapping to the returned file descriptor of
open_by_handle_at syscall for symlinks. For regular files we can do what
we already does and for symlinks we will create inodes in handlefs and
their inode operation will in turn result in call out of inode operations
of the actual symlinks. Based on the above

a) We still need open_by_handle_at syscall
b) We still need handle based link syscall, because we need to support
   creating hardlinks based on handle, and the existing linkat syscall
   takes the oldpath name.
c) We still need handle based readlink syscall, because the existing
   readlinkat syscall takes pathname.
d) we can drop stat, chown and xattr syscall because they are introduced
   specially for symlinks as we don't allow open on symlinks.
e) It would be nice to have handle based stat syscall to avoid two
   syscall overhead for fetching file attributes when implementing a
   file server, where fetching file attribute is a common operation. 

With the above from the current patch series we can drop chown and
xattr syscalls. Would it be ok if we get the series with the those two
syscall patches dropped upstream as i work on supporting symlinks with
handlefs approach ?

-aneesh

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