Re: -mm -> 2.6.13 merge status (fuse)

[Miklos Szeredi]

> It would be helpful if we could have a brief description of the feature
> which you're discussing here.  We discussed this a couple of months back,
> but I've forgotten most of it and it was off-list I think.
> 
> Doing `grep uid fs/fuse/*.c' gets us to the implementation, yes?
> 
> Which parts are controversial?

The controversial part is fuse_allow_task() called from
fuse_permission() and fuse_revalidate() (fs/fuse/dir.c).

This function (as explained by the header comment) disallows access to
the filesystem for any task, which the filesystem owner (the user who
did the mount) is not allowed to ptrace.

The rationale is that accessing the filesystem gives the filesystem
implementor ptrace like capabilities (detailed in
Documentation/filesystems/fuse.txt)

It is controversial, because obviously root owned tasks are not
ptrace-able by the user, and so these tasks will be denied access to
the user mounted filesystem (-EACCESS is returned on stat() or any
other file operation).

However nobody raised _any_ concrete technical problem associated with
this, and the 4 years of widespread use didn't turn up any either.  So
IMO it's "ugly" only in people's heads and not in reality.

> How _should_ we implement unprivileged mounts, if not this way?

A lot of the earlier discussion centered around making private
namespaces usable, and so segregating user mounts.  However because
suid/sgid programs can still gain elevated privileges in a private
namespace the above check is still necessary.

So private namespaces are alone not a solution.

I also suggested (and implemented a patch) which hides the user
mounts, based on the above check.  This would mean, that root and
other users would simply not see the user's mount instead of getting
an error.  This was also received with very little enthusiasm.

A further suggested alternative was to confine user mounts to a single
directory (e.g. '/mnt/usermounts').  This would solve the problem if
every daemon and suid/sgid program was tought to not enter this
directory.  This is quite impractical.  Besides this is a very
inflexible solution.

I'm still waiting for a practical alternative.  I don't consider
practical the opinion held by quite a few people:

   "let's integrate FUSE now, without unpriv mounts, maybe we'll find
    a better solution later"

I consider it highly unlikely, that any time will be better than now.

Thanks,
Miklos

  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/