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

[Miklos Szeredi <miklos@szeredi.hu>]

> But the problem you're addressing here largely revolves around the fact that
> the filesystem implementation is a userspace process which is potentially
> owned by a different user.  So you need to prevent the mount owner from
> peeking at the fs user's activity.  That problem is unique to FUSE and so a
> solution within fuse is appropriate.

It's in fact not so unique to FUSE.  It would equally well apply to
v9fs or even samba, since both want to allow unprvileged mounts, and
synthetic (or at least user-controlled) file serving.

> This security feature doesn't sounds terribly important to me.  So the fuse
> server can find out what files I'm looking at.  But I've already
> deliberately given the fuse server the ability to ptrace my process?

If it's deliberate, than OK. 

However with suid/sgid, this is not a deliberate action of the user
under whose capabilities the process runs.  Neither in the case, when
it's a daemon doing some recursive directory traversal.

And it's not just peeking at the filesystem access patterns.  A much
more dangerous aspect is controlling _when_ an operation returns
(e.g. delaying it forever), and _what_ it returns (e.g. huge
files/directories).

Of course, this is only truly relevant for systems with untrusted
users.  But I do want to make FUSE work securely in those cases too.

For the single user system, the sysadmin can turn this feature off,
and be done with it.

> Can we enhance private namespaces so they can squash setuid/setgid?  If so,
> is that adequate?

We could.  But that would again be overly restrictive.  The goal is to
make the use of FUSE filesystems for users as simple as possible.  If
the user has to manage multiple namespaces, each with it's own
restrictions, it's becoming a very un-user-friendly environment.

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