Re: prctl(0x8) -> EINVAL [Was: 2.6.25-rc3-mm1]

[Serge E. Hallyn]

Quoting Jiri Slaby (jirislaby@xxxxxxxxx):
> On 03/04/2008 10:19 AM, Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc3/2.6.25-rc3-mm1/
>> +capabilities-implement-per-process-securebits.patch
>
> This probably causes userspace damage:
>
> dbus:
> prctl(0x8, 0x1, 0, 0, 0)                = -1 EINVAL (Invalid argument)
>
> named:
> named: -u with Linux threads not supported: requires kernel support for 
> prctl(PR_SET_KEEPCAPS)
> prctl(0x8, 0x1, 0, 0, 0)          = -1 EINVAL (Invalid argument)
>
> ntpd:
> prctl(0x8, 0x1, 0xffffffffffffffa8, 0x1, 0) = -1 EINVAL (Invalid argument)
> prctl(0x8, 0x1, 0, 0, 0)          = -1 EINVAL (Invalid argument)
>
> $ grep CONFIG_SECURITY .config
> # CONFIG_SECURITY is not set
> # CONFIG_SECURITY_FILE_CAPABILITIES is not set

Thanks, Jiri.  Does the following patch work for you?

This patch address the !CONFIG_SECURITY case, but not the case of
using the dummy LSM.  The default these days is to have capabilities
compiled in no matter what, but it is still possible to have
CONFIG_SECURITY=y and CONFIG_SECURITY_CAPABILITIES=n, in which
case prctl(0x8) will return -EINVAL.  Do we want dummy to call
cap_prctl() as well, or are we ok with userspace getting -EINVAL
given that there are in fact no capabilities at that point and
the userspace code is clearly expecting them?

thanks,
-serge