From: Frank v Waveren <fvw@var.cx>
To: linux-kernel@vger.kernel.org
Subject: linux capabilities oddity
Date: Sun, 23 Jul 2006 16:36:46 +0200 [thread overview]
Message-ID: <20060723143646.GA2840@var.cx> (raw)
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
I sent this to linux-privs-discuss, but that list appears to be dead.
Perhaps someone here can help me?
While debugging an odd problem where /proc/sys/kernel/cap-bound wasn't
working, I came across the following code at
linux-2.6.x/security/commoncap.c:140:
void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
{
/* Derived from fs/exec.c:compute_creds. */
kernel_cap_t new_permitted, working;
new_permitted = cap_intersect (bprm->cap_permitted, cap_bset);
working = cap_intersect (bprm->cap_inheritable,
current->cap_inheritable);
new_permitted = cap_combine (new_permitted, working);
...
Here the new permitted set gets limited to the bits in cap_bset, which
is as it should be, but then the intersection of the of the current
and exec inheritable masks get added to that set, whereas as I
understand it, cap_bset should always be the bounding set.
This triggered a problem where the /sbin/init on a gentoo install disk
(which I was using as an quick&dirty UML root disk for testing) for
some reason did something to set its inheritable mask to ~0, which
then propagated to all the processes that ran as root, which meant
that the cap bound didn't apply to them.
I took out the cap_combine and didn't notice any ill effects on some
quick tests, though I don't know POSIX capabilities well enough to say
all the behaviour was per the standard. If someone could tell me what
those lines are for, and if its foiling of cap-bound limits is on
purpose, I'd be most grateful.
--
Frank v Waveren Key fingerprint: BDD7 D61E
fvw@var.cx 5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8 FA00 7D51 468D 62C8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2006-07-23 14:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-23 14:36 Frank v Waveren [this message]
2006-07-25 18:47 ` linux capabilities oddity Serge E. Hallyn
2006-07-27 14:19 ` Frank v Waveren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060723143646.GA2840@var.cx \
--to=fvw@var.cx \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.