FUSE hits a snag [LWN.net]

The filesystems in user space (FUSE - covered here in January, 2004) provides a kernel interface and library which makes it easy to implement filesystems with a user-space process. With FUSE, a user can mount a filesystem contained with a tar archive, implemented via an FTP session, or "tunneled" from a remote system via ssh. It is a powerful tool with many users, and its authors have been pushing for inclusion into the mainline kernel for some time now. That merge has been delayed pending a review of the patch by a few interested developers.

That review has happened, and it has turned up a problem; it seems that FUSE, in some situations, implements some rather strange filesystem semantics.

Consider the case of a filesystem hosted in a tar archive. FUSE will present files within the archive with the owners and permission modes specified inside that archive. The owner and permissions of the files, in other words, do not necessarily have anything to do with the owner of the archive or the user who mounted it as a filesystem. To allow that user to actually work with files in the archive, the "tarfs" FUSE module disables ordinary permissions checking. A file may, according to a tool like ls, be owned by another user and inaccessible, but the user who mounted the filesystem has full access anyway. FUSE also ensures that no other user has any access to the mounted filesystem - not even root.

This twisting of filesystem semantics does not sit well with some kernel developers, who tend to think that Linux systems should behave like Linux. The FUSE semantics have the potential to confuse programs which think that the advertised file permissions actually mean something (though, evidently, that tends not to be a problem in real use) and it makes it impossible to mount a filesystem for use by more than one user. So these developers have asked that the FUSE semantics be removed, and that a FUSE filesystem behave more like the VFAT-style systems; the user mounting the filesystem should own the files, and reasonable permissions should be applied.

In fact, FUSE does provide an option ("allow_others") which causes it to behave in this way. But that approach goes against what FUSE is trying to provide, and raises some security issues of its own. FUSE hacker Miklos Szeredi sees the issue this way:

I want the tar filesystem to be analogous to running tar. When I run tar, other users are not notified of the output, it's only for me. If they want to run tar, they can too. The same can be true for tarfs. I mount it for my purpose, others can mount it for theirs. Since the daemon providing the filesystem always runs with the same capabilities as the user who did the mount, I and others will always get the permissions that we have on the actual tar file.

In this view, a FUSE filesystem is very much a single-user thing. In some cases, it really should be that way; consider a remote filesystem implemented via an ssh connection. The user mounting the filesystem presumably has the right to access the remote system, on the remote system's terms. The local FUSE filesystem should not be trying to figure out what the permissions on remote files should be. Other users on the local system - even the root user - may have no right to access the remote system, and should not be able to use the FUSE filesystem to do so.

It's not clear where this discussion will go. There are some clear reasons behind the behavior implemented by FUSE, and it may remain available, though, perhaps, not as a default, and possibly implemented in a different way. The little-used Linux namespace capability has been mentioned as a way of hiding single-user FUSE filesystems, though there may be some practical difficulties in making namespaces actually work with FUSE. Until the core filesystem hackers are happy, however, FUSE is likely to have a rough path into the mainline.

(Log in to post comments)

Is this a kernel issue?

Posted Apr 14, 2005 7:58 UTC (Thu) by mjr (guest, #6979) [Link]

Seems to me that this sort of issues are likely to be on the user space fs implementation side; that is, I doubt the FUSE kernel patch itself controls the permissions found in a tar file. Therefore, IMAO, this shouldn't be an issue against including the FUSE patch into mainline.

Of course, a case could be made that the FUSE kernel patch should prevent that sort of things, but that just gets on a slippery slope on what as-is harmless things it should prevent, as well as reduce the flexibility of the architecture. Which would be bad.

Extended attributes

Posted Apr 14, 2005 21:11 UTC (Thu) by proski (subscriber, #104) [Link]

Wouldn't it be reasonable to present the native permissions as extended attributes rather than as UNIX permissions? For example, if a file over ssh connection belongs to a user that doesn't exist locally, how do you map it to a local user ID? But an extended attribute "owner" could have a string value for the actual owner of the file.

If the permissions on a file don't reflect what file operations are actually allowed, what's the point in presenting them as permissions? An ACL editor would be more suitable for viewing and changing those permissions than chmod and chown.

Extended attributes

Posted Apr 16, 2005 0:40 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

If the permissions on a file don't reflect what file operations are actually allowed, what's the point in presenting them as permissions?

The point is that some people want to use the standard tools, not an arcane ACL editor made just for that job. FUSE is all about making something look like a traditional filesystem so your traditional tools and skills work with it. If not for that, you might as well use a tar file editor instead of mounting your tar file as a filesystem.

The arguments against acknowledge that value, but just point out that the downside -- the cases where the model breaks and the fact that the permissions aren't really permissions shows -- outweighs it.

Extended attributes

Posted Apr 21, 2005 7:49 UTC (Thu) by xoddam (subscriber, #2322) [Link]

It seems to me that the special semantics are no more or less than
a user could trick his/her processes to see with other, purely
userspace tools using LD_PRELOAD, such as fakeroot. The
point of FUSE is merely to facilitate the task.

In other words, it's the users' business what semantics they
present to themselves, and not a kernel hacker's problem.

Looking at the application with full generality, you want to
have the flexibility to map users and permissions about in any
way you wish, just as you might remap uids and usernames over
NFS or SMB, or 'squish' root privileges to nothing. And in this
case, the power do do that remapping belongs to the person
running 'mount'.

User-controlled file permission semantics with FUSE

Posted Apr 21, 2005 15:39 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

It seems to me that the special semantics are no more or less than a user could trick his/her processes to see with other, purely userspace tools using LD_PRELOAD

I think the point is just that users presumably would like in some cases both to have access to files with FUSE and have normal semantics. FUSE should provide users that capability if possible.

Also, in the proposal, mounting a filesystem affects other processes -- all those owned by the same user see the mounted files with unconventional permission semantics.

FUSE hits a snag

Posted Apr 16, 2005 19:45 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link]

I too feel it should be sorta like VFAT, or like rationalized Rockridge on an ISO.

If you want to make your mounted tarball private, do it the same way you'd do anything else: Change the ownership and permissions of the mount point or a directory above it to block access. It really is that simple. It's the UNIX way.

Inside the mounted tarfile, you should see the original permissions of the files, perhaps filtered through a umask, and the files should be owned by you , unless root mounted the tarfile. In other words, it should be awful close to simply untarring a tarfile.

I don't think it's sane for 'ls' to give me the 'tar tv' output while still giving me semantics that try (and fail) to approximate what I'd get if I actually untarred the file.