Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262748AbVENLtj (ORCPT ); Sat, 14 May 2005 07:49:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262746AbVENLtj (ORCPT ); Sat, 14 May 2005 07:49:39 -0400 Received: from mail.shareable.org ([81.29.64.88]:15830 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S262744AbVENLtf (ORCPT ); Sat, 14 May 2005 07:49:35 -0400 Date: Sat, 14 May 2005 12:49:15 +0100 From: Jamie Lokier To: Bryan Henderson Cc: Miklos Szeredi , bulb@ucw.cz, ericvh@gmail.com, hch@infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, smfrench@austin.rr.com Subject: Re: [RCF] [PATCH] unprivileged mount/umount Message-ID: <20050514114915.GA19703@mail.shareable.org> References: 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: 1455 Lines: 33 Bryan Henderson wrote: > 2) after the private mount, don't let a program that has gained privileges > via set-uid see the user-made names. > > My point is still that (2) can't be done because you can't know that a > program has gained privileged via set-uid. > > If it's really not about set-uid, but about ptrace-like privilege > borrowing, please enlighten me. Note that not all setuid programs gain *capabilities*. You appear to be talking about setuid-root, but there is also setuid-some-other-user, where the capabilities don't change but the priveleges switch to those of another uid. The right thing to do in that case is tricky. For example, suppose you have a program that's setuid to the "printer" user, which can copy the caller's file to the printer queue directories in /var/spool/printer. Ideally, that program should be able to read the calling user's file, looking up the path in the calling user's namespace (that's important, because the path is provided by the calling user), and then write to /var/spool/printer. (*Really* ideally /var/spool/printer wouldn't be visible in the calling user's namespace, but that sort of design is straying far indeed from a unix model). -- 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/