Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 16 Apr 2014 11:40:44 -0700 | Subject | Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path |
| |
On Wed, Apr 16, 2014 at 11:36 AM, Vivek Goyal <vgoyal@redhat.com> wrote: > On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote: > > [..] >> >> Admittedly cgroups aren't currently as important as uid, but if this >> >> changes, then SO_PASSCGROUP, as currently written, will have *exactly* >> >> the same problem. >> > >> > Which is easy to foil by using SO_PEERCGROUP and find out who originally >> > opened the socket, which is why that is also available! >> >> Then please remove SO_PASSCGROUP. > > SO_PASSCGROUP is important because SO_PEERCGROUP does not work with unix > datagram sockets.
Right. I forgot about that.
> > Again going back to logging example, if some clients are logging to unix > datagram sockets, SO_PASSCGROUP is the only option to figure out cgroup > of client.
Hmm. I think that, in your patch, the cgroup that is sent is the cgroup of the caller of write/send/sendmsg. What if you changed it to use the same cgroup that SO_PEERCRED would use? Would that still work?
>> >> I still haven't seen any explanation for what's wrong with requiring >> senders to ask the kernel to transmit their cgroup. > > If nothing else, additional complexity and ovhead. Extra pair of messages > need to be exchanged to request and then provide the information. > > How would it work in logging example? Every time logger receives a > message, is it supposed to send another message to client to send > SCM_CGROUP? That does not sound right.
No -- just have the logger send the cgroup with every message. Yes, it seems silly, but it's probably barely more expensive than with the code in your patch.
--Andy
| |