[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3zkwgqp3c.fsf@linux.vnet.ibm.com>
Date: Sat, 21 Aug 2010 15:12:15 +0530
From: "Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Nick Piggin <npiggin@...nel.dk>, Neil Brown <neilb@...e.de>
Cc: Al Viro <viro@...IV.linux.org.uk>,
Christoph Hellwig <hch@...radead.org>, adilger@....com,
corbet@....net, 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 -V18 04/13] vfs: Allow handle based open on symlinks
On Sat, 21 Aug 2010 18:30:24 +1000, Nick Piggin <npiggin@...nel.dk> wrote:
> Thanks, I had both of the same concerns as Christoph with API
> change and exposing symlink fds last time I looked at the patces,
> actually.
>
> But they can probably be worked around or avoided. I think the more
> important thing is whether it is worth supporting. This is
> all restricted to root (or CAP_DAC_READ_SEARCH) only, right, and
> what exact semantics they want. I would like to see more discussion
> of what this enables and some results.
>
> For the case of avoiding expensive network revalidations in path name
> lookup, do we even need to open symlinks? Could the security issues be
> avoided by always having handle attached to an open fd?
>
For implementing a userspace file server that use handle for
representing files (like NFS) we would require to have the ability to do
different file system operations that can operate on symlink to work on
handle too.
-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/
Powered by blists - more mailing lists