Quoting Herbert Poetzl (herbert@13thfloor.at):
> ah, you are the one who is to blame for this mess ... :)
Well, I wanted to use lsm hooks, not capabilities...
> > For vserver, loginuid should probably always be reported along with
> > the vserver id, I guess...
>
> patches to virtualize the loginuid are welcome, as well
I assume the final consumer of the audit logs is the owner of the physical
machine, not each vserver owner? I'm wondering whether just adding the
vserver id to each audit message, and adding a capability to distinguish
setting loginuid from the other actions currently controlled by
CAP_AUDIT_CONTROL would be sufficient... Then only the real owner can
add and delete rules, each vserver can set loginuids, but the real owner
will always see at least the vserver id responsible for an event.
> as an explanation why it is require at all (especially
> from userspace)
Well, only the latter right now:
The loginuid is supposed to be the first uid you log in as. Further
setuids should not change the loginuid, in order to ensure that audit
messages are accounted to the original login account. So you need to
change the loginuid through PAM (so that admin can decide which programs
are allowed to determine loginuid), and need the capability to make sure
only privileged users can do so.
Or, short answer: CAPP and LSPP.
-serge
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Mon Nov 14 15:14:05 2005