linux-kernel - 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]

Message-ID: <20140424210429.GD19091@redhat.com>
Date:	Thu, 24 Apr 2014 17:04:29 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	luto@...capital.net, tj@...nel.org, dwalsh@...hat.com,
	linux-kernel@...r.kernel.org, lpoetter@...hat.com,
	ssorce@...hat.com, cgroups@...r.kernel.org, kay@...hat.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] net: Implement SO_PASSCGROUP to enable passing
 cgroup path

On Thu, Apr 24, 2014 at 04:48:20PM -0400, David Miller wrote:
> From: Vivek Goyal <vgoyal@...hat.com>
> Date: Thu, 24 Apr 2014 16:34:27 -0400
> 
> > By open() time you mean at socket() time or at connect() time?
> 
> I mean at all of the places at which init_peercred() occurs.

init_peercred() is only used for stream sockets and not for datagram
sockets. Hence the confusion that what are cgroup semantics for datagram
sockets.

> 
> > You also mentioned that you want SO_PEERCGROUP and SO_PASSCGROUP as
> > pairs like SO_PEERCRED and SO_PASSCRED.  But to me, SO_PEERCRED and
> > SO_PASSCRED are not *exact* pairs and are little different in their
> > semantics.  SO_PEERCRED gives us client creds at connect() time
> > while SO_PASSCRED client's real creds at sendmsg() time. SO_PASSCRED
> > does not store client's credential's at connect() time for datagram
> > sockets.
> 
> Then you haven't been following the discussion.
> 
> The client's credentials at sendmsg()/write() time are "DO NOT CARE".
> 
> You cannot even guarentee the semantics in the logging example if
> you ask for these "client identity at sendmsg() time" semantics.
> 
> What if the event occured when the client was in cgroup1, and the
> log message goes out after it has been moved into cgroup2?

Does it really matter. If a task is changing cgroup while it is doing
other operations, I don't think one can guarantee which cgroup kernel
will effectively uses for a particular operation. It will depend on
what was cgroup when kernel actually made task_cgroup() call. 

> 
> That is just proof that this whole idea is fundamentally flawed.

I don't think anybody is looking for such strong semantics. For example,
same issue will exist if receiver gets the message and looks up
/proc/pid/cgroup to associate message with a cgroup. By then task might
have changed cgroup.

So I really don't think changing cgroup is a problem w.r.t API.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/