Quoting Jonathan Corbet (corbet@xxxxxxx): > On Wed, 24 Feb 2010 22:53:23 -0600 > "Serge E. Hallyn" <serue@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
