Thread (4 messages) 4 messages, 2 authors, 2019-12-16

Re: Anomalous output from getpcaps(1) for process with all capabilities

From: Michael Kerrisk (man-pages) <hidden>
Date: 2019-12-15 19:17:23

Hello Andrew,

On Sun, 15 Dec 2019 at 19:30, Andrew G. Morgan [off-list ref] wrote:
This changed with this commit I think:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/libcap/cap_text.c?id=3fa808f5886d08c45866217cfe6e6e9def7de04e

Prior to that, we had "=ep" mean the cap set was ~0 for
all the bitmasks in e and p. When we started to clip the
bounding set to only defined capabilities, it meant that the
text output started to look like
"=ep 33,34,35,36,37,38,39,40,41,42.....63-ep" which
was quite terrible.
Was that really the change that caused this? That's a 2008 commit.
Certainly, I recall in 2014 or 2015 still being able to see =ep, and I
presume (but do not recall for sure) that I was using a system with a
libcap more recent than v2.11 (of which that commit was a part).
So, this was seen as the least worst option.
But surely this is fixable? Or, to put it another was, I presume
there's something that makes this difficult to fix in getpcaps, but
what is that something?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help