Quoting Andreas Dilger (adilger@xxxxxxx): > On 2010-02-25, at 12:05, Serge E. Hallyn wrote: > >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! > > It seems to me that there are two different, though related, use > cases. In some cases it would be desirable to allow "short lived" > handles to be passed between processes, and in other cases it is > necessary to have "long lived" handles. Yes, but what do the client and server sides look like? Can this be done using fds instead of file_handles? I.e. is requiring they be sent over a unix sock ok? Probably not, but it seems worth checking. > For "short lived" or "strong" handles they should contain a > capability that prevents arbitrary handles from being guessed, so > such a handle could be used by any process, possibly for at most a > limited duration or use count. For "long lived" handles, either the > capability needs to be stored persistently so that it can be > validated even after a server reboot, or the "weak" handles (without > capabilities) that can be guessed should only be usable with > CAP_DAC_OVERRIDE. > > >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? > > > Something like that. I'm not a security expert, and capability > designs exist and I'd suggest we don't try to invent anything here. All the better :) -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
