prompt expansion and POSIX.1e capabilities

prompt expansion and POSIX.1e capabilities

[Clint Adams]

I know nothing about these things.

----- Forwarded message from Galen Hancock <galen@CSUA.Berkeley.EDU> -----

Package: zsh
Version: 4.0.0+4.0.1.pre4-3

The default PS1 is "%m%# ". zsh conforms to the part of its man page,
under PROMPT EXPANSION, which says:

       %#     A  `#'  if  the shell is running with privileges, a
              `%' if not.  Equivalent to `%(!.#.%%)'.  The  defi­
              nition of `privileged', for these purposes, is that
              either the  effective  user  ID  is  zero,  or,  if
              POSIX.1e  capabilities are supported, that at least
              one capability is raised in either the Effective or
              Inheritable capability vectors.

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.

soda% ssh gh.dhs.org
[... normal user logon]
windriver# zsh --version
zsh 4.0.1-pre-4+debian0515 (i686-pc-linux-gnu)
windriver# zmodload zsh/cap
windriver# id
uid=1000(galen) gid=1000(galen) groups=1000(galen),24(cdrom),25(floppy),29(audio),33(www-data),37(operator),40(src),44(video),50(staff),60(games),101(dba),500(wheel),2000(mp3)
windriver# cap
=i cap_setpcap-i
windriver# cap =
windriver% cap
=
windriver% uname -sr
Linux 2.2.15

The format in which capabilites are printed is documented in
cap_from_text(3). = means no capabilites raised, and "=i cap_setpcap-i"
means, first, all capabilities raised in inheritable and, then,
cap_setpcap turned off in inheritable.

I don't know much about capabilites, so I don't know for sure what a more
reasonable setting would be; I think "at least one capability raised in
'effective'" would make sense.

					Galen

Re: prompt expansion and POSIX.1e capabilities

[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

PATCH: Re: prompt expansion and POSIX.1e capabilities

[Clint Adams]

> 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.

Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.29
diff -u -r1.29 utils.c
--- Src/utils.c	2001/05/23 08:53:12	1.29
+++ Src/utils.c	2001/05/29 14:59:00
@@ -3667,11 +3667,7 @@
 	    cap_flag_value_t val;
 	    cap_value_t n;
 	    for(n = 0; !cap_get_flag(caps, n, CAP_EFFECTIVE, &val); n++)
-		if(val ||
-		   (!cap_get_flag(caps, n, CAP_INHERITABLE, &val) && val)) {
-		    cap_free(caps);
-		    return 1;
-		}
+		if(val) return 1;
 	    cap_free(caps);
 	}
     }