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

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

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

-serge