Quoting Aneesh Kumar K. V (aneesh.kumar@xxxxxxxxxxxxxxxxxx): > On Thu, 25 Feb 2010 09:19:09 -0600, "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > > 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... > > > 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? > open_by handle() is limited to CAP_SYS_ADMIN (which i am updating to > CAP_DAC_OVERRIDE). -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
