Re: openg and path_to_handle

2006-12-14 Thread Matthew Wilcox 
On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote:
 I don't think that I understand what you're saying here. The openg() 
 call does not perform file open (not that that is necessarily even a 
 first-class FS operation), it simply does the lookup.
 
 When we were naming these calls, from a POSIX consistency perspective it 
 seemed best to keep the open nomenclature. That seems to be confusing 
 to some. Perhaps we should rename the function lookup or something 
 similar, to help keep from giving the wrong idea?
 
 There is a difference between the openg() and path_to_handle() approach 
 in that we do permission checking at openg(), and that does have 
 implications on how the handle might be stored and such. That's being 
 discussed in a separate thread.

I was just thinking about how one might implement this, when it struck
me ... how much more efficient is a kernel implementation compared to:

int openg(const char *path)
{
char *s;
do {
s = tempnam(FSROOT, .sutoc);
link(path, s);
} while (errno == EEXIST);

mpi_broadcast(s);
sleep(10);
unlink(s);
}

and sutoc() becomes simply open().  Now you have a name that's quick to
open (if a client has the filesystem mounted, it has a handle for the
root already), has a defined lifespan, has minimal permission checking,
and doesn't require standardisation.

I suppose some cluster fs' might not support cross-directory links
(AFS is one, I think), but then, no cluster fs's support openg/sutoc.
If a filesystem's willing to add support for these handles, it shouldn't
be too hard for them to treat files starting .sutoc specially, and as
efficiently as adding the openg/sutoc concept.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-14 Thread Rob Ross 

Christoph Hellwig wrote:

On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:

While it could do that, I'd be interested to see how you'd construct
the handle such that it's immune to a malicious user tampering with it,
or saving it across a reboot, or constructing one from scratch.

If the server has to have processed a real open request, say within
the preceding 30s, then it would have a handle for openfh() to match
against.  If the server reboots, or a client tries to construct a new
handle from scratch, or even tries to use the handle after the file is
closed then the handle would be invalid.

It isn't just an encoding for open-by-inum, but rather a handle that
references some just-created open file handle on the server.  That the
handle might contain the UID/GID is mostly irrelevant - either the
process + network is trusted to pass the handle around without snooping,
or a malicious client which intercepts the handle can spoof the UID/GID
just as easily.  Make the handle sufficiently large to avoid guessing
and it is secure enough until the whole filesystem is using kerberos
to avoid any number of other client/user spoofing attacks.


That would be fine as long as the file handle would be a kernel-level
concept.  The issue here is that they intent to make the whole filehandle
userspace visible, for example to pass it around via mpi.  As soon as
an untrused user can tamper with the file descriptor we're in trouble.


I guess it could reference some just-created open file handle on the 
server, if the server tracks that sort of thing. Or it could be a 
capability, as mentioned previously. So it isn't necessary to tie this 
to an open, but I think that would be a reasonable underlying 
implementation for a file system that tracks opens.


If clients can survive a server reboot without a remount, then even this 
implementation should continue to operate if a server were rebooted, 
because the open file context would be reconstructed. If capabilities 
were being employed, we could likewise survive a server reboot.


But this issue of server reboots isn't that critical -- the use case has 
the handle being reused relatively quickly after the initial openg(), 
and clients have a clean fallback in the event that the handle is no 
longer valid -- just use open().


Visibility of the handle to a user does not imply that the user can 
effectively tamper with the handle. A cryptographically secure one-way 
hash of the data, stored in the handle itself, would allow servers to 
verify that the handle wasn't tampered with, or that the client just 
made up a handle from scratch. The server managing the metadata for that 
file would not need to share its nonce with other servers, assuming that 
single servers are responsible for particular files.


Regards,

Rob
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-14 Thread Rob Ross 

Matthew Wilcox wrote:

On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote:
I don't think that I understand what you're saying here. The openg() 
call does not perform file open (not that that is necessarily even a 
first-class FS operation), it simply does the lookup.


When we were naming these calls, from a POSIX consistency perspective it 
seemed best to keep the open nomenclature. That seems to be confusing 
to some. Perhaps we should rename the function lookup or something 
similar, to help keep from giving the wrong idea?


There is a difference between the openg() and path_to_handle() approach 
in that we do permission checking at openg(), and that does have 
implications on how the handle might be stored and such. That's being 
discussed in a separate thread.


I was just thinking about how one might implement this, when it struck
me ... how much more efficient is a kernel implementation compared to:

int openg(const char *path)
{
char *s;
do {
s = tempnam(FSROOT, .sutoc);
link(path, s);
} while (errno == EEXIST);

mpi_broadcast(s);
sleep(10);
unlink(s);
}

and sutoc() becomes simply open().  Now you have a name that's quick to
open (if a client has the filesystem mounted, it has a handle for the
root already), has a defined lifespan, has minimal permission checking,
and doesn't require standardisation.

I suppose some cluster fs' might not support cross-directory links
(AFS is one, I think), but then, no cluster fs's support openg/sutoc.


Well at least one does :).


If a filesystem's willing to add support for these handles, it shouldn't
be too hard for them to treat files starting .sutoc specially, and as
efficiently as adding the openg/sutoc concept.


Adding atomic reference count updating on file metadata so that we can 
have cross-directory links is not necessarily easier than supporting 
openg/openfh, and supporting cross-directory links precludes certain 
metadata organizations, such as the ones being used in Ceph (as I 
understand it).


This also still forces all clients to read a directory and for N 
permission checking operations to be performed. I don't see what the FS 
could do to eliminate those operations given what you've described. Am I 
missing something?


Also this looks too much like sillyrename, and that's hard to swallow...

Regards,

Rob
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread David Chinner 
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 [EMAIL PROTECTED] 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=linuxdb=manfname=/usr/share/catman/man3/open_by_handle.3.htmlsrch=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.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread Matthew Wilcox 
On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
 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.)

While it could do that, I'd be interested to see how you'd construct
the handle such that it's immune to a malicious user tampering with it,
or saving it across a reboot, or constructing one from scratch.

I suspect any real answer to this would have to involve cryptographical
techniques (say, creating a secure hash of the information plus a
boot-time generated nonce).  Now you're starting to use a lot of bits,
and compute time, and you'll need to be sure to keep the nonce secret.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread David Chinner 
On Wed, Dec 06, 2006 at 10:20:23AM -0600, Rob Ross wrote:
 Matthew Wilcox wrote:
 On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
 David Chinner wrote:
 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).
 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.
 
 Another (and highly important) difference is that usage is restricted to
 root:
 
 xfs_open_by_handle(...)
 ...
 if (!capable(CAP_SYS_ADMIN))
  return -XFS_ERROR(EPERM);
 
 I assume that this is because the implementation chose not to do the 
 path encoding in the handle? Because if they did, they could do full 
 path permission checking as part of the open_by_handle.

The original use of this interface (if I understand the Irix history
correctly - this is way before my time at SGI) was a userspace NFS
server and so permission checks were done after the filehandle was
opened and a stat could be done on the fd and mode/uid/gid could be
compared to what was in the NFS request. Paths were never needed for
this because everything needed could be obtained directly from
the inode.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread Rob Ross 

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 [EMAIL PROTECTED] 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=linuxdb=manfname=/usr/share/catman/man3/open_by_handle.3.htmlsrch=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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread David Chinner 
On Wed, Dec 06, 2006 at 02:50:49PM -0600, Rob Ross wrote:
 David Chinner wrote:
 On Wed, Dec 06, 2006 at 09:53:39AM -0600, Rob Ross wrote:
 David Chinner wrote:
 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).
 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.)
 
 Thanks for the clarification Dave. So I take it that you would be 
 interested in this type of functionality then?

Not really - just trying to help by pointing out something no-one
seemed to know about

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread David Chinner 
On Wed, Dec 06, 2006 at 01:50:24PM -0700, Matthew Wilcox wrote:
 On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
  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.)
 
 While it could do that, I'd be interested to see how you'd construct
 the handle such that it's immune to a malicious user tampering with it,
 or saving it across a reboot, or constructing one from scratch.
 
 I suspect any real answer to this would have to involve cryptographical
 techniques (say, creating a secure hash of the information plus a
 boot-time generated nonce).  Now you're starting to use a lot of bits,
 and compute time, and you'll need to be sure to keep the nonce secret.

An auth header and GSS-API integration would probably be the way
to go here if you really care.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread Matthew Wilcox 
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
 Considering that filesystems like GFS and OCFS allow clients DIRECT
 ACCESS to the block device itself (which no amount of authentication
 will fix, unless it is in the disks themselves), the risk of passing a
 file handle around is pretty minimal.

That's either disingenuous, or missing the point.  OCFS/GFS allow the
kernel direct access to the block device.  openg()sutoc() are about
passing around file handles to untrusted users.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread Latchesar Ionkov 

On 12/6/06, Rob Ross [EMAIL PROTECTED] wrote:

David Chinner wrote:
 On Tue, Dec 05, 2006 at 05:47:16PM +0100, Latchesar Ionkov wrote:
 On 12/5/06, Rob Ross [EMAIL PROTECTED] 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=linuxdb=manfname=/usr/share/catman/man3/open_by_handle.3.htmlsrch=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.


The open-by-handle makes a little more sense, because the handle is
not opened, it only points to a resolved file. As I mentioned before,
it doesn't make much sense to bundle in openg name resolution and file
open.

Still I am not convinced that we need two ways of finding files.

Thanks,
   Lucho
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: openg and path_to_handle

2006-12-06 Thread Christoph Hellwig 
On Wed, Dec 06, 2006 at 03:09:10PM -0700, Andreas Dilger wrote:
  While it could do that, I'd be interested to see how you'd construct
  the handle such that it's immune to a malicious user tampering with it,
  or saving it across a reboot, or constructing one from scratch.
 
 If the server has to have processed a real open request, say within
 the preceding 30s, then it would have a handle for openfh() to match
 against.  If the server reboots, or a client tries to construct a new
 handle from scratch, or even tries to use the handle after the file is
 closed then the handle would be invalid.
 
 It isn't just an encoding for open-by-inum, but rather a handle that
 references some just-created open file handle on the server.  That the
 handle might contain the UID/GID is mostly irrelevant - either the
 process + network is trusted to pass the handle around without snooping,
 or a malicious client which intercepts the handle can spoof the UID/GID
 just as easily.  Make the handle sufficiently large to avoid guessing
 and it is secure enough until the whole filesystem is using kerberos
 to avoid any number of other client/user spoofing attacks.

That would be fine as long as the file handle would be a kernel-level
concept.  The issue here is that they intent to make the whole filehandle
userspace visible, for example to pass it around via mpi.  As soon as
an untrused user can tamper with the file descriptor we're in trouble.

-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html