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

[Andrew Morton]

Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> > 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.

That's fairly weird.  Overloading ptraceability is awkward, but also the
*direction* is wrong.  It's saying "if I can ptrace you, you can read my
data".  I'd have expected to see "if you can ptrace me, you can access my
data".

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

hrm.  Makes some sense.

> 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.

It's ugly ;)

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.

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?

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


-
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/