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 ([EMAIL PROTECTED]):
On Thu, 14 Jul 2005, Enrico Scholz wrote:
[EMAIL PROTECTED] (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
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
[email protected]
http://list.linux-vserver.org/mailman/listinfo/vserver
