On Mon, Nov 14, 2005 at 06:54:23AM -0600, 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)
ah, you are the one who is to blame for this mess ... :) > For vserver, loginuid should probably always be reported along with > the vserver id, I guess... patches to virtualize the loginuid are welcome, as well as an explanation why it is require at all (especially from userspace) TIA, Herbert > -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
