Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 2 Nov 2002 21:15:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 2 Nov 2002 21:15:12 -0500 Received: from leibniz.math.psu.edu ([146.186.130.2]:57853 "EHLO math.psu.edu") by vger.kernel.org with ESMTP id ; Sat, 2 Nov 2002 21:15:11 -0500 Date: Sat, 2 Nov 2002 21:21:40 -0500 (EST) From: Alexander Viro To: Linus Torvalds cc: Olaf Dietsche , "Theodore Ts'o" , Dax Kelson , Rusty Russell , linux-kernel@vger.kernel.org, davej@suse.de Subject: Re: Filesystem Capabilities in 2.6? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1287 Lines: 29 On Sat, 2 Nov 2002, Linus Torvalds wrote: > The reason I like directory entries as opposed to inodes is that if you > work this way, you can actually give different people _different_ > capabilities for the same program. You don't need to have two different > installs, you can have one install and two different links to it. that can be done without doing anything to filesystem. Namely, turn current "nosuid" of vfsmount into a mask of capabilities. Then use bindings instead of links. *Note* - binary _is_ marked suid, mask tells which capabilities _not_ to gain. It's OK - attempt to link(2) to the thing using binding will see that oldname and newname are within different vfsmounts, so instead of link to suid-root binary you get -EXDEV. And that works on any fs, can be made per-user and can be _seen_ by admin - bindings are visible in /proc/mounts (yes, I remember that we need to fix the crap with pathnames). I can do that thing in a weekend - it's trivial to implement. No need to bugger filesystems for that. - 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/