To: jamie@shareable.org
CC: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
       hch@infradead.org, akpm@osdl.org,
       viro@parcelfarce.linux.theplanet.co.uk
In-reply-to: <20050411182257.GC32535@mail.shareable.org> (message from Jamie
	Lokier on Mon, 11 Apr 2005 19:22:57 +0100)
Subject: Re: [RFC] FUSE permission modell (Was: fuse review bits)
References: <20050323083347.GA1807@infradead.org> <E1DE2D1-0005Ie-00@dorka.pomaz.szeredi.hu> <20050325095838.GA9471@infradead.org> <E1DEmYC-0008Qg-00@dorka.pomaz.szeredi.hu> <20050331112427.GA15034@infradead.org> <E1DH13O-000400-00@dorka.pomaz.szeredi.hu> <20050331200502.GA24589@infradead.org> <E1DJsH6-0004nv-00@dorka.pomaz.szeredi.hu> <20050411114728.GA13128@infradead.org> <E1DL08S-0008UH-00@dorka.pomaz.szeredi.hu> <20050411182257.GC32535@mail.shareable.org>
Message-Id: <E1DL4kC-0000SA-00@dorka.pomaz.szeredi.hu>
From: Miklos Szeredi <miklos@szeredi.hu>
Date: Mon, 11 Apr 2005 21:38:48 +0200
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 6766
Lines: 158

> >   1) User must not be able to modify files or directories in a way
> >      which he otherwise could not do (e.g. mount a filesystem over
> >      /bin)
> > 
> >   2) Suid and device semantics should be disabled within the mount
> > 
> >   3) No other user should have access to files under the mount, not
> >      even root[5]
> 
> Why?  I can see plenty of uses where I want a filesystem generated by
> one user to be accessible by other users.  That policy should not be
> hard-coded into the kernel.  It might be an option.

It is.

> >   4) Access should not be further restricted for the owner of the
> >      mount, even if permission bits, uid or gid would suggest
> >      otherwise
> 
> Why?  Surely you want to prevent writing to files which don't have the
> writable bit set?  A filesystem may also create append-only files -
> and all users including the mount owner should be bound by that.

You are right.  This is indeed possible optionally.  I'm saying that
maybe the filesystem owner _does_ _not_ want any more restrictions
despite the attributes.  Consider a tar file in which there is a file
owned by 'root' and having permissions (-rw-------).  If you have read
access to the tar file, you can obviously actually read the file
inside the tar file despite it's permissions. 

> >   5) As much of the available information should be exported via the
> >      filesystem as possible
> 
> This is the root of the conflict.  You are trying to overload the
> permission bits and uid/gid to mean something different than they
> normally do.

Yes. 

> While it's convenient to see some "remote" information such as the
> uid/gid in a tar file, are you sure it's a good idea to break the unix
> permissions model - which will break some programs?  (For example, try
> editing a file with the broken semantics in an editor which checks the
> uid/gid of the file against the current user).

Why would a program do that?  In fact I've not come accross such a
program yet, so this is pretty theoretical.  On the other hand even if
such a program existed, the filesystem could still have an option to
change uid/gid/mode on all files to something 'standard' (like
uid/gid/umask options for stupid filesystems).

> For most virtual filesystems, the "remote" information does not map to
> uid/gid in a particularly natural way anyway.

Tar archives of local disk?  Sshfs to server with which you have
shared passwd files?  These are not made up examples.

> So it seems odd to want to break the unix permissions model just so
> that a small _subset_ of virtual filesystems can use stat() as a way
> to get a bit of information out, when other virtual filesystems
> (e.g. webdavfs) can't put meaningful information in there, and would
> benefit from normal unix permissions instead.

But where there's no meaningful information, you don't need to make it
up.  What I'm proposing doesn't limit the filesystem in any way.
There's an option to leave permission checking to the kernel, then all
you need to worry about is setting the mode bits.  That is perfectly
OK.

> >   1) Only allow mount over a directory for which the user has write
> >      access (and is not sticky)
> 
> Seems good - but why not sticky?  Mounting a user filesystem in
> /tmp/user-xxx/my-mount-point seems not unreasonable - provided the
> administrator can delete the directory (which is possible with
> detachable mount points).

Yes.  The only thing you're not allowed is to mount on /tmp, for
obvious reasons :)

> >   2) Use nosuid,nodev mount options
> 
> Of course.  Ideally, make sure they appear to be set in /proc/mounts.

They are in fact set by the fusermount userspace utility.  So there's
no extra kernel magic involved.

> (root (or equivalent) should be able to create virtual filesystems
> without these options, but probably they should be set by default even
> for root, and clearable using suid,dev).

That is exactly how it works.

> >   3) In permission method of FUSE kernel module compare fsuid against
> >      mounting user's ID, and return EACCES if they are not equal.
> 
> Bad.  How do I, user A, then create a virtual filesystem which I want
> user B to be able to access?

But together with the option to set arbitary uid/gid on the files
within your mounts this could be abused, I think.  So either this or
that.  If someone really needs this I can implement another option.

> >   4) The filesystem daemon does not run with elevated permissions.
> >      The kernel doesn't check file more in the permission method.
> 
> I like the idea that the fs daemon doesn't need elevated permissions.
> 
> >   5) The filesystem daemon is free to fill in all file attributes to
> >      any (sane) value, and the kernel won't modify these.
> 
> Dangerous, because an administrative program might actually trust the
> attributes to mean what they normally mean in the unix permissions model.

Yes, I agree with you fully.  This is exactly why other users
including root are not allowed access to the mount.

> > The debated part is 3) and 4), namely that normal permission checking
> > based on file mode is bypassed, and the mounting user has full
> > permission to all files, while other users have none.
> > 
> > This feature has been in FUSE from the start and thus has been very
> > well tested in real world scenarios.  Also I have thought a lot about
> > how this could pose any kind of security threat, and as yet found no
> > such possiblity.
> 
> Ok, but why do you prevent the useful behaviour of allowing access to
> other users, when I want that?  For example, I might export my current
> project's database as a filesystem that I _want_ other users to be
> able to read.

Yes, this is a valid point.  I'll see how an option allowing this
would look like.  I think it can be coded up in a few lines.

> > Despite this Christoph feels this behavior is unacceptable for a
> > filesystem, and wants me to remove this feature before merging FUSE
> > into mainline.  I try to be open to ideas, but also feel strongly that
> > this is the Right Way, so I won't give up easily.
> 
> I agree with Christoph.  It is a huge deviation from the unix
> permissions model

It is.  But it's still less confusing to allow something that you'd
think is not allowed, than the opposite.

> -- and it seems to prevent some useful applications of FUSE so it's
> not clear why you want it.

I don't want to prevent any usage that is safe and secure.  What
Christoph wants _would_ prevent some valid applications.

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/