Re: [RFC PATCH] Generic name to handle and open by handle syscalls

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> On Thu, 25 Feb 2010 12:11:13 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > Quoting Aneesh Kumar K. V (aneesh.kumar@linux.vnet.ibm.com):
> > > On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > Quoting Jonathan Corbet (corbet@lwn.net):
> > > > > On Wed, 24 Feb 2010 22:53:23 -0600
> > > > > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > > > > 
> > > > > > I'd be curious to see the reasons for requiring it in the xfs version.
> > > > > > Do you have any docs about it?  You're still doing a dentry_open, and
> > > > > > you got the filename fd somehow so the name shouldn't be a secret...
> > > > > > An LSM hook - specifically to make sure that selinux still allows you
> > > > > > to read the path (access to file->f_security) - might belong here,
> > > > > 
> > > > > I had assumed it was the path that was the issue; a file handle is
> > > > > divorced from that path, so there's no way to know if a process can
> > > > > search its way down to the file or not.  That would leave the system
> > > > > open to the same "open the file after path permissions have changed"
> > > > > problem that people have complained about in other contexts.  It seems
> > > > > like you could also fish for files by opening random file handles; I
> > > > > don't know how large the search space is, so it's hard for me to say
> > > > > how practical that would be.
> > > > 
> > > > Right, and so I think what is really needed is some DAC checks at the
> > > > newly-introduced sys_name_to_handle(), which near as I could tell are
> > > > not there at all.
> > > > 
> > > > Then, if process X is going to sys_open_by_handle() using pathname
> > > > fd 4, then fd 4 had to be created using sys_name_to_handle() either
> > > > by X or by some process Y which handed fd 4 over to X.  In either
> > > > case, it's basically no different from a open_at() where the
> > > > directory fd was handed to X by Y at that point, right?
> > > > 
> > > > So, if do_sys_name_to_handle() actually does DAC checks (somewhere
> > > > in the depths of the exportfs code?) then all should be fine now.
> > > > But I don't see any...
> > > 
> > > 
> > > user_lpath(..) used to convert name to path does path look using normal
> > 
> > Ah, there it is, thanks.
> > 
> > In that case I don't see where there is any reason for special
> > privilege on the part of a process who receives that fd.
> > 
> > Let me put it another way:  if task Y does sys_name_to_handle() to
> > create an fd, then we should not absolve Y of the responsibility of
> > not passing that fd around willy nilly by papering over
> > sys_open_by_handle() with a requirement for superuser privileges.
> > 
> > And if Y were intentionally misbehaving, then it could just share
> > the pathname in countless already-existing ways, and then just for
> > the heck of it open the file itself and pass that fd to the client.
> > So not allowing the pathname fd to be transferred seems worthless.
> > 
> > > permission check. So we do check for permissions when converting a path
> > > to handle. But the problem still remain with respect to somebody being
> > > able to guess the file handle and use that in open_by_handle. Currently
> > 
> > But why is that a problem?  I don't see how it can be abused by a user,
> > unless it is the specific intent for some server Y to create a pathname
> > fd FD and pass that to a client X, where X should be able to see the file
> > contents but not the pathname?  And if that were the case then you
> > wouldn't require CAP_SYS_ADMIN for the client.
> > 
> > I'm obviously missing something - can you give a specific example?
> 
> Currently whether a user is allowed to open a file is also determined by
> the permission of the directory components of the path. That's denying
> execute bits on the directory prevent the lookup and so user can't open
> the file. (Whether we can depend on this behaviour is debated before).
> With file handle being valid for the life of the file, if a user is able
> to guess handle for file /a/b/c then he will be able to open 'c' without

Jipes!  I was misunderstanding what you were doing with the struct
file_handle.  Your use of the phrase 'guess handle for file' set me
straight.  I thought you were encoding a file_handle into an fd using
sys_name_to_handle(), and passing that fd along over a unix sock - so a
client would have to receive a validly opened fd to use it.  If it can
just guess at a string, then yeah, please do hide that behind as much
privilege as you can!

I take it then that the file_handles must be communicated over something
other than unix socks (else you could just pass an fd and let the client
either use the fd, or re-open /proc/self/fd/<fd>)?  Would you be able to
at least add a touch of randomness and hashing to make this sa[fn]er and
turn this into a single-use capability?  Or does that not fit your usage
model?  So the server would come up with some random bytes B, calculate
H = hash(F|B) (hash of filename concatenated with random bytes), pass F
and H along to client while storing F and B, so client can pass F and H
to sys_open_by_handle() which confirms that that was a valid file
handle?

thanks,
-serge