Pass request context to more handlers

Issue #59 resolved
Jon Gjengset
created an issue

Some FUSE handlers (like open and opendir) are not passed a RequestContext, and this is apparently for historical reasons. Instead, FUSE provides a fuse_get_context function, which allows retrieving this information. Unfortunately, since such a function is not exposed by llfuse, it is currently not possible to get any information about the user that is executing an open or opendir call. Could such a function be added to llfuse to address this?

Comments (8)

  1. Nikolaus Rath repo owner

    If it was meant to be provided for other handlers in FUSE but isn't because of backwards compatibility, I'll happily add it to llfuse (there'll be a backwards incompatible release pretty soon anyway).

    However, I'd like some reference for that. Has one of the FUSE developers said something about this? Why hasn't this been changed in FUSE 3.0 (which breaks backward compatibility)?

  2. Jon Gjengset reporter

    I don't know what'll happen in FUSE 3.0, but at least for now, fuse_get_context seems to be the only way to get context from, say, the handler for open(). Nearest I can find to a confirmation that this low-level API function is needed is this thread from the FUSE mailing list, and the section on "Getting FUSE context" from these notes.

    Re the upcoming backwards-incompatible changes to llfuse you mention, has a changelog been posted anywhere?

  3. Nikolaus Rath repo owner

    For some reason I was assuming that all permissions checking is done via the access method. But looking at the FUSE documentation, this doesn't seem to be the case. Adding an API function to retrieve the credentials is technically complicated because there is no way to tell the function which request you are interested in. I could introduce something that identifies the request, but that would break backwards compatibility - but in that case I can just as well pass the request context to all handlers where it makes sense. So I think this is what I'll do.

  4. Jon Gjengset reporter

    Yeah, that's probably the best solution. Certainly, getting ctx directly to open and opendir (there might be others too) would solve this problem in a clean way. Arguably, it's what FUSE should have been doing anyway.

  5. Jon Gjengset reporter

    I suppose the concern that arises from this is what the overhead of getting the context for every method call is. With the FUSE solution of having to call get_context, you can also not call the function if you don't need it, thus improving performance...

  6. Nikolaus Rath repo owner

    I was thinking about that as well, but I don't think it is a concern. Any other solution would incur at least the same performance overhead (we'd need to create a Python wrapper object for fuse_req), and the cost is likely to be negligible compared to the other operations that have to be carried out when calling into Python (we're instantiating a C extension that uses freelists).

    If you manage to measure a slow-down, please let me know!

  7. Log in to comment