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
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.
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 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
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
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
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
=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
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
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
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
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
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
13 matches
Mail list logo
