David Chinner wrote:
On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
David Chinner wrote:
On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
On 12/5/06, Rob Ross <rross@xxxxxxxxxxx> wrote:
Hi,
I agree that it is not feasible to add new system calls every time
somebody has a problem, and we don't take adding system calls lightly.
However, in this case we're talking about an entire *community* of people
(high-end computing), not just one or two people. Of course it may still
be the case that that community is not important enough to justify the
addition of system calls; that's obviously not my call to make!
I have the feeling that openg stuff is rushed without looking into all
solutions, that don't require changes to the current interface.
I also get the feeling that interfaces that already do this open-by-handle
stuff haven't been explored either.
Does anyone here know about the XFS libhandle API? This has been around for
years and it does _exactly_ what these proposed syscalls are supposed to do
(and more).
See:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man3/open_by_handle.3.html&srch=open_by_handle
For the libhandle man page. Basically:
openg == path_to_handle sutoc == open_by_handle
And here for the userspace code:
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libhandle/
Cheers,
Dave.
Thanks for pointing these out Dave. These are indeed along the same lines as
the openg()/openfh() approach.
One difference is that they appear to perform permission checking on the
open_by_handle(), which means that the entire path needs to be encoded in
the handle, and makes it difficult to eliminate the path traversal overhead
on N open_by_handle() operations.
open_by_handle() is checking the inode flags for things like
immutibility and whether the inode is writable to determine if the
open mode is valid given these flags. It's not actually checking
permissions. IOWs, open_by_handle() has the same overhead as NFS
filehandle to inode translation; i.e. no path traversal on open.
Permission checks are done on the path_to_handle(), so in reality
only root or CAP_SYS_ADMIN users can currently use the
open_by_handle interface because of this lack of checking. Given
that our current users of this interface need root permissions to do
other things (data migration), this has never been an issue.
This is an implementation detail - it is possible that file handle,
being opaque, could encode a UID/GID of the user that constructed
the handle and then allow any process with the same UID/GID to use
open_by_handle() on that handle. (I think hch has already pointed
this out.)
Cheers,
Dave.
Thanks for the clarification Dave. So I take it that you would be
interested in this type of functionality then?
Regards,
Rob
-
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
