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
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
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
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 don't want to cache
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
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 me. I
, 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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
