Quoting Aneesh Kumar K. V (aneesh.kumar@xxxxxxxxxxxxxxxxxx): > On Thu, 25 Feb 2010 12:11:13 -0600, "Serge E. Hallyn" <serue@xxxxxxxxxx> wrote: > > 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? > > 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 -- 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
