From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6448 invoked from network); 23 May 2001 22:29:05 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 23 May 2001 22:29:05 -0000 Received: (qmail 9975 invoked by alias); 23 May 2001 22:28:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14464 Received: (qmail 9963 invoked from network); 23 May 2001 22:28:53 -0000 Subject: Re: prompt expansion and POSIX.1e capabilities In-Reply-To: <20010523120514.A26393@dman.com> from Clint Adams at "May 23, 2001 12:05:14 pm" To: Clint Adams Date: Wed, 23 May 2001 23:28:51 +0100 (BST) CC: zsh-workers@sunsite.dk, 98475-forwarded@bugs.debian.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Clint Adams wrote: >This is not useful behavior, because (at least on my installation), >normal users have all capabilities but cap_setpcap raised inheritable. >This gives me a # prompt, not %, when I log in. Curious. At the time I added the POSIX.1e stuff -- the same time I was working on the Linux kernel POSIX.1e project -- the Inheritable set was constrained to always be a subset of Permitted. Also, normal binaries, having empty file capability sets, would lose all capabilities of their parents on startup. It appears that the capability rules have changed, and Inheritable is no longer required to be a subset of Permitted. Instead, it's a set of latent capabilities, that a binary can acquire for real if it has a non-empty file Inheritable set. As I noted at the time, the rules about the different capability sets are too complicated, and I can't tell, just from the code, what administrative function the Inheritable set fulfills. My best guess is that it's a mechanism for implementing decisions about which users are permitted to invoke which administrative programs, though a rather poor one -- difficult to justify putting into the kernel. It appears that the best logic to implement is, as you suggest, to generate the "#" prompt iff the Effective set is non-empty. Another possibility is to check both the Effective and Permitted sets; the Permitted set is effectively `saved capabilities', with similar semantics to saved UIDs. However, the non-capability logic doesn't look for a saved root UID, so I think we should not be looking for Permitted capabilities. -zefram