Thanks!
Just for documentation in case anyone gets stuck trying to fix this:
It looks like older FC4 pam will work with ^30, and newer (pam-0.79-9.6)
requires *both* ^29 and ^30. (Doesn't matter, BTW, whether you have
pam_loginuid.so in your config, it looks like it is patched to use audit
regardless).
Grisha
On Mon, 14 Nov 2005, Serge E. Hallyn wrote:
> Quoting Gregory (Grisha) Trubetskoy (grisha@ispol.com):
>>
>> On Thu, 14 Jul 2005, Enrico Scholz wrote:
>>
>>> enrico.scholz@sigma-chemnitz.de (Enrico Scholz) writes:
>>>
>>>> | # auditctl -m 'foo'
>>>> | Error sending user message request (Operation not permitted)
>>>> ...
>>>> This gives problems on Fedora Core 4 as recent pam upgrade is
>>>> using this functionality and most actions (su, cron) will fail
>>>> therefore.
>>>
>>> Quick workaround is to add '^29' to the 'bcapabilities' of the
>>> corresponding vserver. Next util-vserver version will probably
>>> implicate this with the '--secure' option (after I decided how to
>>> deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict).
>>
>> This didn't work for me (just to make "su -" work), it seems that I needed
>> ^30 (CAP_AUDIT_CONTROL).
>>
>> Does anyone here know what the security implication of this is? We don't
>> run auditd.
>
> IIRC I originally added this capability... It's too coarse-grained for
> my liking, but only applicable to audit. It allows your process to change
> its loginuid, which you see reported in the audit msgs, but which is
> not used for any authentication. (same bit allows adding/del'ing/listing
> audit rules, iirc)
>
> For vserver, loginuid should probably always be reported along with the
> vserver id, I guess...
>
> -serge
>
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Mon Nov 14 18:46:31 2005