Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 2 Nov 2002 20:56:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 2 Nov 2002 20:56:56 -0500 Received: from neon-gw-l3.transmeta.com ([63.209.4.196]:16391 "EHLO neon-gw.transmeta.com") by vger.kernel.org with ESMTP id ; Sat, 2 Nov 2002 20:56:56 -0500 Date: Sat, 2 Nov 2002 18:03:12 -0800 (PST) From: Linus Torvalds To: Olaf Dietsche cc: "Theodore Ts'o" , Dax Kelson , Rusty Russell , , Subject: Re: Filesystem Capabilities in 2.6? In-Reply-To: <87y98bxygd.fsf@goat.bogus.local> 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: 1752 Lines: 39 On Sun, 3 Nov 2002, Olaf Dietsche wrote: > Linus Torvalds writes: > > > - Make a new file type, and put just that information in the directory > > (so that it shows up in d_type on a readdir()). Put the real data in > > the file, ie make it largely look like an "extended symlink". > > How would you go from a regular file to the new extended symlink? I don't understand the question. Let's say that you have a binary like /usr/bin/sendmail, and you want to give it a certain set of capabilities (ie you want to _avoid_ making it suid root - you only want to give it the specific capability of being able to chown files to others and whatever else it is sendmail really wants to do). So I'd suggest _not_ attaching that capability to the sendmail binary itself, or to any inode number of that binary. A binary is a binary is a binary - it's just the data. Instead, I'd attach the information to the directory entry, either directly (ie the directory entry really has an extra field that lists the capabilities) or indirectly (ie the directory entry is really just an "extended symlink" that contains not just the path to the binary, but also the capabilities associated with it). 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. Linus - 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/