From: "J. Bruce Fields" <bfields@fieldses.org>
To: Andreas Dilger <adilger@sun.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
hch@infradead.org, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] vfs: Add open by file handle support
Date: Fri, 26 Feb 2010 14:24:36 -0500 [thread overview]
Message-ID: <20100226192436.GC23556@fieldses.org> (raw)
In-Reply-To: <AD5A6061-9B7B-4B29-A458-822E781C2588@sun.com>
On Sat, Feb 20, 2010 at 11:58:34AM -0700, Andreas Dilger wrote:
> On 2010-02-18, at 22:42, Aneesh Kumar K.V wrote:
>> +long do_sys_open_by_handle(int dfd, struct file_handle *fh, int
>> flags)
>> +{
>> + if (!capable(CAP_SYS_ADMIN))
>> + /* Allow open by handle only by sysadmin */
>> + return -EPERM;
>
> Hmm, I guess this avoids some of the security concerns, but makes it a
> lot less useful. I was thinking this could be used for e.g. user NFS
> serving or such, but if it is limited to root only then you might as
> well just set up the in-kernel NFSd. By making the handle hard to forge
> (e.g. generate random key per superblock, sha1(ino+gen+key) and store
> that into fh; someone with more security experience can think of a better
> scheme) then you can reasonably safely dispense with the CAP_SYS_ADMIN
> check because you can be sure that the proper path traversal has been
> done by a trusted process and there is no more exposure than unix socket
> fd passing.
The problem with filehandles is that they never die; they have to
survive essentially indefinitely, even across server reboots.
A file descriptor has a better-defined lifetime.
A "secret" that can never be expired doesn't strike me as a very good
secret.
--b.
next prev parent reply other threads:[~2010-02-26 19:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-19 5:42 [RFC PATCH] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-02-19 5:42 ` [RFC PATCH 1/3] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-02-20 18:15 ` Andreas Dilger
2010-02-22 5:15 ` Aneesh Kumar K. V
2010-02-19 5:42 ` [RFC PATCH 2/3] vfs: Add open by file handle support Aneesh Kumar K.V
2010-02-20 18:58 ` Andreas Dilger
2010-02-20 20:13 ` Brad Boyer
[not found] ` <FB88A140-C2EB-4E62-9769-D2524C874C8C@sun.com>
2010-02-22 2:46 ` Brad Boyer
2010-02-26 19:21 ` J. Bruce Fields
2010-02-28 17:55 ` Andreas Dilger
2010-02-28 19:00 ` J. Bruce Fields
2010-03-01 18:25 ` Oleg Drokin
2010-03-01 21:25 ` J. Bruce Fields
2010-02-22 6:13 ` Aneesh Kumar K. V
2010-02-22 6:31 ` Dave Chinner
2010-02-26 19:24 ` J. Bruce Fields [this message]
2010-02-19 5:42 ` [RFC PATCH 3/3] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-02-19 9:34 ` [RFC PATCH] Generic name to handle and open by handle syscalls Andreas Dilger
2010-02-19 9:49 ` Aneesh Kumar K. V
2010-02-20 19:01 ` Andreas Dilger
2010-02-22 6:27 ` Aneesh Kumar K. V
2010-02-22 23:06 ` Jonathan Corbet
2010-02-23 0:56 ` James Morris
2010-02-23 8:58 ` Aneesh Kumar K. V
2010-02-23 19:46 ` Jonathan Corbet
2010-02-24 0:49 ` Dave Chinner
2010-02-25 4:53 ` Serge E. Hallyn
2010-02-25 14:30 ` Jonathan Corbet
2010-02-25 15:19 ` Serge E. Hallyn
2010-02-25 17:55 ` Aneesh Kumar K. V
2010-02-25 18:11 ` Serge E. Hallyn
2010-02-25 18:20 ` Aneesh Kumar K. V
2010-02-25 19:05 ` Serge E. Hallyn
2010-02-26 9:12 ` Andreas Dilger
2010-02-26 19:56 ` Serge E. Hallyn
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=20100226192436.GC23556@fieldses.org \
--to=bfields@fieldses.org \
--cc=adilger@sun.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--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.