netdev - Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Apr 2014 08:37:56 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Simo Sorce <ssorce@...hat.com>, Daniel J Walsh <dwalsh@...hat.com>,
	David Miller <davem@...emloft.net>, Tejun Heo <tj@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	lpoetter@...hat.com, cgroups@...r.kernel.org, kay@...hat.com,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing cgroup path

On Wed, Apr 23, 2014 at 8:07 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Mon, Apr 21, 2014 at 08:47:51AM -0700, Andy Lutomirski wrote:
>
> [..]
>> To summarize from my reading of how this crap words:
>>
>> When a unit is created, systemd opens a stream socket pointing at
>> /run/systemd/journal/stdout.  It tells journald the unit, along with
>> lots of other useful information.  journald records this association
>> between the socket and the unit.  Systemd could tell journald the
>> cgroup here, too, if it wanted it.
>
> Ok, that's a fair point. I looked at  connect_logger_as() and I see
> that systemd does connect() on behalf of service being launched and
> sets up fd and passes bunch of information to journald. So cgroup could
> be one of the information and that would act like SO_PEERCGROUP in
> this specific case. Not sure why it is not done though. I will let
> systemd folks comment on that. I don't have enough background here.
>
> But this works in this specific case where there is a mechanism to
> pass meta information to receiver. What about SSSD use case where
> they want to know the cgroup of client and possibly provide differentiated
> service based on client.

Separate sockets sounds like it will work just fine, if not better, here, to me.

>
> Also Dan Walsh mentioned that what if a process directly wants to open
> journal socket and log something to journal.

This is a fair point.  I think that cgroup is a very odd thing to log,
but systemd unit isn't so strange.

As I've said, I won't object strongly to SO_PEERCGROUP.  I think that
applications that rely on it are likely to be annoying to their users,
but I think the API itself is okay.

I'd still rather see a good, general solution for sensibly identifying
yourself to your peer, but that can wait.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html