On Mon, Nov 14, 2005 at 06:54:23AM -0600, 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)
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
> 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 14:53:59 2005