Quoting Herbert Poetzl ([EMAIL PROTECTED]): > 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