On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce <ssorce@xxxxxxxxxx> wrote: > On Wed, 2014-03-12 at 14:12 -0700, Andy Lutomirski wrote: >> On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> > On 03/12/2014 01:46 PM, Vivek Goyal wrote: >> >> Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the >> >> cgroup of first mounted hierarchy of the task. For the case of client, >> >> it represents the cgroup of client at the time of opening the connection. >> >> After that client cgroup might change. >> > >> > Even if people decide that sending cgroups over a unix socket is a good >> > idea, this API has my NAK in the strongest possible sense, for whatever >> > my NAK is worth. >> > >> > IMO SO_PEERCRED is a disaster. Calling send(2) or write(2) should >> > *never* imply the use of a credential. A program should always have to >> > *explicitly* request use of a credential. What you want is SCM_CGROUP. >> > >> > (I've found privilege escalations before based on this observation, and >> > I suspect I'll find them again.) >> > >> > >> > Note that I think that you really want SCM_SOMETHING_ELSE and not >> > SCM_CGROUP, but I don't know what the use case is yet. >> >> This might not be quite as awful as I thought. At least you're >> looking up the cgroup at connection time instead of at send time. >> >> OTOH, this is still racy -- the socket could easily outlive the cgroup >> that created it. > > I think you do not understand how this whole problem space works. > > The problem is exactly the same as with SO_PEERCRED, so we are taking > the same proven solution. You mean the same proven crappy solution? > > Connection time is all we do and can care about. You have not answered why. > > Simo. > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
