Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261901AbVDKTjl (ORCPT ); Mon, 11 Apr 2005 15:39:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261902AbVDKTja (ORCPT ); Mon, 11 Apr 2005 15:39:30 -0400 Received: from rev.193.226.232.28.euroweb.hu ([193.226.232.28]:3547 "EHLO dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP id S261897AbVDKTi6 (ORCPT ); Mon, 11 Apr 2005 15:38:58 -0400 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> <20050325095838.GA9471@infradead.org> <20050331112427.GA15034@infradead.org> <20050331200502.GA24589@infradead.org> <20050411114728.GA13128@infradead.org> <20050411182257.GC32535@mail.shareable.org> Message-Id: From: Miklos Szeredi Date: Mon, 11 Apr 2005 21:38:48 +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@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/