>> All that being said, the friendliness factor of this is somewhat
>> undeniable, and so I can see why folk might want it in the kernel
>> anyway. If so, would it possible to move this code into
>> security/capability.c and not in the main kernel per-se - protected with
>> a configuration option?
Chuck Lever <[EMAIL PROTECTED]> wrote:
> >>> +struct nfs_fh_auxdata {
> >>> + struct timespec i_mtime;
> >>> + struct timespec i_ctime;
> >>> + loff_t i_size;
> >>> +};
> >>
> >> It might be useful to explain here why you need to supplement the
> >> mtime, ctime, and size fields that alre
Quoting Andrew G. Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Andrew,
>
> Just to be clear, I'm not sure I agree that I'm hiding anything!
>
> I've tried very hard to limit this functionality to only being enabled
> if the still experimental LSM CONFIG_SECURITY
Quoting Andrew G. Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> - -long cap_prctl_drop(unsigned long cap)
> +static long cap_prctl_drop(unsigned long cap)
> ~ {
> - - if (!capable(CAP_SETPCAP))
> + if (cap_capable(current, CAP_SETPCAP) != 0)
>
> | With this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew,
Just to be clear, I'm not sure I agree that I'm hiding anything!
I've tried very hard to limit this functionality to only being enabled
if the still experimental LSM CONFIG_SECURITY_FILE_CAPABILITIES is yes.
I've also arranged for all of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -long cap_prctl_drop(unsigned long cap)
+static long cap_prctl_drop(unsigned long cap)
~ {
- - if (!capable(CAP_SETPCAP))
+ if (cap_capable(current, CAP_SETPCAP) != 0)
| With this change, you
| a) prevent PF_SUPERPRIV being set, al
Quoting Andrew G. Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Here is the patch adding per-process secure-bits. This patch was
> generated over 2.6.24-rc8-mm1 + my privilege escalation bugfix.
>
> Cheers
>
> Andrew
>
> Ref: 6a63d67f37e50dd2031b3a050ebac1e64eae9
