Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261660AbVDKSXj (ORCPT ); Mon, 11 Apr 2005 14:23:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261871AbVDKSXi (ORCPT ); Mon, 11 Apr 2005 14:23:38 -0400 Received: from mail.shareable.org ([81.29.64.88]:44959 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S261660AbVDKSXS (ORCPT ); Mon, 11 Apr 2005 14:23:18 -0400 Date: Mon, 11 Apr 2005 19:22:57 +0100 From: Jamie Lokier To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, hch@infradead.org, akpm@osdl.org, viro@parcelfarce.linux.theplanet.co.uk Subject: Re: [RFC] FUSE permission modell (Was: fuse review bits) Message-ID: <20050411182257.GC32535@mail.shareable.org> References: <20050323083347.GA1807@infradead.org> <20050325095838.GA9471@infradead.org> <20050331112427.GA15034@infradead.org> <20050331200502.GA24589@infradead.org> <20050411114728.GA13128@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4584 Lines: 105 Miklos Szeredi wrote: > 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. > 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. > 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. 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). For most virtual filesystems, the "remote" information does not map to uid/gid in a particularly natural way anyway. 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. > 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). > 2) Use nosuid,nodev mount options Of course. Ideally, make sure they appear to be set in /proc/mounts. (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). > 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? > 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. > 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. > 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 -- and it seems to prevent some useful applications of FUSE so it's not clear why you want it. -- Jamie - 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/