lkml.org 
[lkml]   [2014]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/2] net: Implement SO_PEERCGROUP and SO_PASSCGROUP socket options
From
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 22 Apr 2014 13:31:13 -0700

> On Tue, Apr 22, 2014 at 1:29 PM, David Miller <davem@davemloft.net> wrote:
>> From: Andy Lutomirski <luto@amacapital.net>
>> Date: Tue, 22 Apr 2014 13:08:59 -0700
>>
>>> On Tue, Apr 22, 2014 at 1:05 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Vivek Goyal <vgoyal@redhat.com>
>>>> Date: Tue, 15 Apr 2014 17:15:44 -0400
>>>>
>>>>> This is another version of patchset to add support passing cgroup
>>>>> information of client over unix socket API.
>>>>
>>>> I'm marking this patch series as "changes requested" in patchwork
>>>> because if we still end up adding this feature SO_PASSCGROUP needs to
>>>> be changed to behave like SO_PASSCRED.
>>>>
>>>> Specifically, like SO_PASSCRED, it should pass the "real" cgroup, ie.
>>>> the cgroup at socket open() time.
>>>>
>>>
>>> I suspect that making this change will render it useless,
>>> unfortunately. I really want to understand the use case.
>>
>> There was no use case, it is simply the fact that when I discussed this
>> feature with Vivek and Simo I told them that it should be implemented
>> the same as the existing credential facilities.
>>
>> For datagram situations there is no "peer" to consider in between
>> sendmsg() calls, as the binding is only active during the sendmsg()
>> call.
>>
>> That's why SO_PASSCRED exists in the first place.
>>
>> Otherwise, without SO_PASSCGROUP, there is no way for datagram sockets
>> to find out the peer's open() time cgroup.
>
> Right.
>
> I'd still like to know what userspace applications want this feature.
> The canonical example seems to be journald, but journald doesn't use
> unix datagram sockets AFAICS, nor is the process that opened the
> socket interesting (that process is always systemd).

It's about rounding out the interface properly, now, rather than having
to have a specific use case.

I really don't consider a specific use case as a requirement in this
case.


\
 
 \ /
  Last update: 2014-04-26 23:01    [W:0.209 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site