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.
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.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
