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

[Theodore Ts'o]

On Wed, Jun 22, 2005 at 09:16:34AM +0200, Miklos Szeredi wrote:
> 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).

I don't think this should be objectionable, since we already have
times when root-owned tasks can get EACCESS when accessing some
filesystem.  This can happen with any distributed filesystem that
enforces real security --- whether it be nfs-root-squash, or the
Andrew Filesystem, or NFSv4.  Root can get "permission denied" when
some other userid with appropriate credentials would be allowed to
access the file/directory.

On the other hand, sometimes a root process, or some other user's
process, might _want_ to give permission to allow a trusted FUSE
filesystem the potential to monkey with it (return potentially
untrusted information, or stop it entirely), in exchange for access to
the filesystem.  So it would be nice if there was some way that a
process could tell the kernel that it is willing to give permission to
allow certain FUSE filesystems to potentially affect it.  Say, via a
fnctl() call, perhaps.

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