* prompt expansion and POSIX.1e capabilities
@ 2001-05-23 16:05 Clint Adams
2001-05-23 22:28 ` Zefram
0 siblings, 1 reply; 3+ messages in thread
From: Clint Adams @ 2001-05-23 16:05 UTC (permalink / raw)
To: zsh-workers; +Cc: 98475-forwarded
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: prompt expansion and POSIX.1e capabilities
2001-05-23 16:05 prompt expansion and POSIX.1e capabilities Clint Adams
@ 2001-05-23 22:28 ` Zefram
2001-05-29 15:04 ` PATCH: " Clint Adams
0 siblings, 1 reply; 3+ messages in thread
From: Zefram @ 2001-05-23 22:28 UTC (permalink / raw)
To: Clint Adams; +Cc: zsh-workers, 98475-forwarded
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* PATCH: Re: prompt expansion and POSIX.1e capabilities
2001-05-23 22:28 ` Zefram
@ 2001-05-29 15:04 ` Clint Adams
0 siblings, 0 replies; 3+ messages in thread
From: Clint Adams @ 2001-05-29 15:04 UTC (permalink / raw)
To: Zefram; +Cc: zsh-workers, 98475-forwarded
> 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);
}
}
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-05-29 15:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-23 16:05 prompt expansion and POSIX.1e capabilities Clint Adams
2001-05-23 22:28 ` Zefram
2001-05-29 15:04 ` PATCH: " Clint Adams
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).