Quoting Eric Paris (eparis@xxxxxxxxxx): > On Wed, 2013-03-20 at 13:36 -0500, Serge Hallyn wrote: > > Quoting Aristeu Rozanski (arozansk@xxxxxxxxxx): > > > This is a bit fuzzy to me, perhaps due I'm not fully understanding > > > userns implementation yet, so bear with me: > > > I thought of changing so userns would not grant CAP_AUDIT_WRITE and > > > CAP_AUDIT_CONTROL unless the process already has it (i.e. it'd require > > > > Seems like CAP_AUDIT_WRITE should be targeted against the > > skb->netns->userns. Then CAP_AUDIT_WRITE can be treated like any other > > capability. Last I knew (long time ago) you had to be in init_user_ns > > to talk audit, but that's ok - this would just do the right thing in > > any case. > > kauditd should be considered as existing in the init user namespace. So > I'd think we'd want to check if the process had CAP_AUDIT_WRITE in the > init user namespace and if so, allow it to send messages. Who care what > *ns the process exists in. If it has it in the init namespace, go > ahead. Thus the process that created the container would need > CAP_AUDIT_WRITE in the init namespace for this to all work, right? Yes. What I was suggesting is intended to work if that situation ever changes. But I have zero complaints about doing it as you say, as I doubt it ever will/ought to change. That basically means CAP_AUDIT_WRITE would be worthless in a non-init userns. That's fine - at least the rules would be consistent. > /me also gets so confused about what caps mean in the userns world. If the resource in question (like a network interface) belongs to a namespace (netns) created by the userns in which the caller has the caps in question, then privilege is granted. Otherwise, not. What you're saying above about CAP_AUDIT_WRITE is exactly right (for how audit works right now). > (/me has larger issues with the ns concept as a whole, but that boat > sailed years and years ago) -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
