[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4756C436.706@kernel.org>
Date: Wed, 05 Dec 2007 07:31:02 -0800
From: Andrew Morgan <morgan@...nel.org>
To: KaiGai Kohei <kaigai@...jp.nec.com>
CC: "Serge E. Hallyn" <serue@...ibm.com>,
lkml <linux-kernel@...r.kernel.org>,
linux-security-module@...r.kernel.org,
Chris Wright <chrisw@...s-sol.org>,
Stephen Smalley <sds@...ch.ncsc.mil>,
James Morris <jmorris@...ei.org>, Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] capabilities: introduce per-process capability bounding
set (v10)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
KaiGai Kohei wrote:
> Andrew Morgan wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> KaiGai Kohei wrote:
>>>> + if (!!cap_issubset(*inheritable,
>>>> + cap_combine(target->cap_inheritable,
>>>> + current->cap_bset))) {
>>>> + /* no new pI capabilities outside bounding set */
>>>> + return -EPERM;
>>>> + }
>>>>
>> Yes, the !! was a bug. The correct check is a single !.
>
> I was in trouble with getting -EPERM at pam_cap.so :-)
>
>> (Thus, the correct check says no 'new' pI bits can be outside cap_bset.)
>
> If this condition intends to dominate 'new' pI bits by 'old' pI bits masked
> with bounding set, we should not apply cap_combine() here.
> I think applying cap_intersect() is correct for the purpose.
The check is not meant to limit existing pI bits.
The check is meant to limit what new bits can be 'added' to pI (in the
case that pE & CAP_SETPCAP is true).
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHVsQ2mwytjiwfWMwRAs9RAKCUyjsjONVhRXooG5I2b+1zU/HLGwCfQIyh
tjdDI9QxJ1DWLCm2Ee29qYA=
=Gwwt
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists