y proposal. honestly that didn't
occur to me as even remotely possible, especially given that in most
cases the server will be verifying the exact same handle lots of times,
rather than needing to verify a large number of different handles
simultaneously (in which case there's no
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 w
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 op
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 w
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
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
On Wed, Dec 06, 2006 at 09:42:47AM -0600, Rob Ross wrote:
> The fh_t is indeed a type of capability. fh_t, properly protected, could
> be passed into user space and validated by the file system when
> presented back to the file system.
Well, there's quite a lot of papers on how to implement prop
y 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 cu
, 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
andle 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
On Dec 06, 2006 13:50 -0700, Matthew Wilcox wrote:
> On Thu, Dec 07, 2006 at 07:40:05AM +1100, David Chinner wrote:
> > 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 proces
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 t
gt; >>>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.
> >&
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
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 appea
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 n
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
>
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
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
er, 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 t
Christoph Hellwig wrote:
On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
The openg() really just does the lookup and permission checking). The
openfh() creates the file descriptor and starts that context if the
particular FS tracks that sort of thing.
...
Well you've caught
On Wed, 2006-12-06 at 11:01 +, Christoph Hellwig wrote:
> Say you want to lookup a path /foo/bar/baz, then the access permission
> is based on the following things:
>
> - the credentials of the user. let's only take traditional uid/gid
>for this example although credentials are much more
On Tue, Dec 05, 2006 at 03:44:31PM -0600, Rob Ross wrote:
> The openg() really just does the lookup and permission checking). The
> openfh() creates the file descriptor and starts that context if the
> particular FS tracks that sort of thing.
...
> Well you've caught me. I do
23 matches
Mail list logo
