Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261820AbVDKP4f (ORCPT ); Mon, 11 Apr 2005 11:56:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261816AbVDKP4e (ORCPT ); Mon, 11 Apr 2005 11:56:34 -0400 Received: from rev.193.226.232.28.euroweb.hu ([193.226.232.28]:11482 "EHLO dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP id S261755AbVDKP4Z (ORCPT ); Mon, 11 Apr 2005 11:56:25 -0400 To: dan@debian.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: <20050411153619.GA25987@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 11 Apr 2005 11:36:19 -0400) 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> <20050411153619.GA25987@nevyn.them.org> Message-Id: From: Miklos Szeredi Date: Mon, 11 Apr 2005 17:56:09 +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2460 Lines: 58 > > 3) No other user should have access to files under the mount, not > > even root[5] > > > [5] Obviously root cannot be restricted, but accidental access to > > private data is still a good idea. E.g. root squashing by NFS servers > > has a similar affect. > > Could you explain a little more? I don't see the point in denying > access to root, but I also can't tell from your explanation whether you > do or not. Fuse by default does. This can be disabled by one of two mount options: "allow_other" and "allow_root". The former implies the later. These mount options are only allowed for mounting by root, but this can be relaxed with a configuration option. > If I mount a filesystem using ssh, I want to be able to "sudo cp > foo.txt /etc" and not get an inexplicable permissions error. If you can do that sudo, you can also modify the configuration and use one of the mount options. > I don't really see the point of this restriction, anyway. Could you > explain why this shouldn't be a matter of policy, and kept out of the > kernel? Have the userspace file servers default to putting restrictive > permissions on mounts unless requested otherwise. That's an option. However you can't restrict root that way, and you need an extra directory, since permissions on the mountpoint are ignored after the mount. Restricting root is needed, so that a sysadmin won't accidently go into a user's private mount (e.g. sshfs to some machine to which the sysadmin otherwise has no access). Root can still gain access by doing 'su me', but at least he will have a bad conscience. This is not such a stupid idea as it first sounds IMO, and by default all NFS servers exhibit a similar behavior (root squashing). > > 4) Access should not be further restricted for the owner of the > > mount, even if permission bits, uid or gid would suggest > > otherwise > > Similar questions. This behavior can be disabled by the "default_permissions" mount option (wich is not privileged, since it adds restrictions). A FUSE filesystem mounted by root (and not for private purposes) would normally be done with "allow_other,default_permissions". Does this answer your questions? 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/