On Thu, 2014-04-24 at 17:11 -0400, David Miller wrote:
> From: Vivek Goyal
> Date: Thu, 24 Apr 2014 17:04:29 -0400
>
> > Does it really matter.
>
> Good question, if it doesn't matter, you might as well log garbage.
>
> There are a lot of logical holes in this discussion.
>
> Real UIDs are alw
From: Vivek Goyal
Date: Thu, 24 Apr 2014 17:04:29 -0400
> Does it really matter.
Good question, if it doesn't matter, you might as well log garbage.
There are a lot of logical holes in this discussion.
Real UIDs are always reported at sendmsg() time, not effective ones
(the UID "at sendmsg() t
On Thu, Apr 24, 2014 at 04:48:20PM -0400, David Miller wrote:
> From: Vivek Goyal
> 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
From: Vivek Goyal
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.
> You also mentioned that you want SO_PEERCGROUP and SO_PASSCGROUP as
> pairs like SO_PEERCRED and SO_PASSCRED.
On Wed, Apr 23, 2014 at 01:29:55PM -0400, David Miller wrote:
> From: Vivek Goyal
> Date: Wed, 23 Apr 2014 12:45:37 -0400
>
> > On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
> >
> > [..]
> >> Here's an attack against SO_PASSCGROUP, as you implemented it: connect
> >> a socket
From: Vivek Goyal
Date: Wed, 23 Apr 2014 12:45:37 -0400
> On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
>
> [..]
>> Here's an attack against SO_PASSCGROUP, as you implemented it: connect
>> a socket and get someone else to write(2) to it. This isn't very
>> hard. Now you've
On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
[..]
> Here's an attack against SO_PASSCGROUP, as you implemented it: connect
> a socket and get someone else to write(2) to it. This isn't very
> hard. Now you've impersonated.
If this is a problem then I think kernel requires fi
On Wed, Apr 23, 2014 at 08:37:56AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 23, 2014 at 8:07 AM, Vivek Goyal 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, syste
On Wed, Apr 23, 2014 at 8:07 AM, Vivek Goyal 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
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 informat
On Mon, Apr 21, 2014 at 8:03 AM, Vivek Goyal wrote:
> So what happened to logger use case where logger accepts stream
> connections and logs the cgroup of client too.
>
> W.r.t systemd, looks like journald is accepting connections at
> /run/systemd/journal/stdout. (stdout_stream_new() and
> server
On Thu, Apr 17, 2014 at 12:46:22PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 12:16 PM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 03:10:17PM -0400, Simo Sorce wrote:
> >
> > [..]
> >> At this point I think journald people need to give a little bit more
> >> details on how they pl
On Thu, Apr 17, 2014 at 12:16 PM, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 03:10:17PM -0400, Simo Sorce wrote:
>
> [..]
>> At this point I think journald people need to give a little bit more
>> details on how they plan to use SO_PASSCGROUP.
>>
>> For my use cases I care only about streams and
On Thu, 2014-04-17 at 14:50 -0400, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> > > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > > > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wro
On Thu, Apr 17, 2014 at 11:50 AM, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
>> Perhaps this could be done with a sendmsg() header flag or simplified
>> ancillary data even, rather than forcing the sender process to retrieve
>> and construct the whole informat
On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> > >>
> > >> Not really. write(2) can't send SCM_CGROUP.
On Thu, Apr 17, 2014 at 12:15 PM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 12:06 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 11:57 AM, Vivek Goyal wrote:
>> > On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
>> >> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrot
On Thu, Apr 17, 2014 at 03:10:17PM -0400, Simo Sorce wrote:
[..]
> At this point I think journald people need to give a little bit more
> details on how they plan to use SO_PASSCGROUP.
>
> For my use cases I care only about streams and SO_PEERCGROUP that does
> not have any of the (perceived) iss
On Thu, 2014-04-17 at 12:06 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 11:57 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
> >> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirs
On Thu, Apr 17, 2014 at 11:57 AM, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
>> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
>> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
>> > > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wro
On Thu, Apr 17, 2014 at 02:50:23PM -0400, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 02:23:33PM -0400, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> > > On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > > > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomir
On Thu, Apr 17, 2014 at 11:23 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
>> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
>> >>
>> >> Not really. write(2) can't send SCM_CGROUP. Callers o
On Thu, 2014-04-17 at 11:04 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:52 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> >> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >> who supply SCM_CGROUP are explicitly indi
On Thu, Apr 17, 2014 at 10:47 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
>> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
>> >>
>> >> Not really. write(2) can't send SCM_CGROUP. Callers o
On Thu, Apr 17, 2014 at 10:52 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
>> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
>> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
>
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski w
On Thu, 2014-04-17 at 10:35 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> >>
> >> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
> >> who supply SCM_CGROUP are explicitly indi
On Thu, Apr 17, 2014 at 10:33 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
>>
>> Not really. write(2) can't send SCM_CGROUP. Callers of sendmsg(2)
>> who supply SCM_CGROUP are explicitly indicating that they want their
>> cgroup associated with that message.
On Thu, 2014-04-17 at 10:26 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> > On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski w
On Thu, Apr 17, 2014 at 10:12 AM, Vivek Goyal wrote:
> On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
>> > On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
>> >> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
>>
On Thu, Apr 17, 2014 at 09:55:08AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
> >> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
> >> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wro
On Thu, Apr 17, 2014 at 9:48 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
>> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
>> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
>> >>
>> >> No. The logging daemon thinks it wants to know who the w
On Thu, 2014-04-17 at 09:37 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> >>
> >> No. The logging daemon thinks it wants to know who the writer is, but
> >> the logging daemon is wrong. It actual
On Thu, Apr 17, 2014 at 09:11:11AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:04 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> >> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> >> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
On Thu, Apr 17, 2014 at 9:24 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
>>
>> No. The logging daemon thinks it wants to know who the writer is, but
>> the logging daemon is wrong. It actually wants to know who composed a
>> log message destined to it. The
On Thu, 2014-04-17 at 09:11 -0700, Andy Lutomirski wrote:
> On Thu, Apr 17, 2014 at 9:04 AM, Simo Sorce wrote:
> > On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> >> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> >> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> >> >
On Thu, Apr 17, 2014 at 08:41:15AM -0700, Daniel J Walsh wrote:
[..]
> The two use cases for this patch are:
>
> 1 Logging, to make sure the cgroup information gets correctly attributed
> to the caller.
>
> 2 Potentially reveal different information to the caller based on the
> cgroup informati
On Thu, Apr 17, 2014 at 9:04 AM, Simo Sorce wrote:
> On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
>> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
>> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
>> >> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
>> >>> On We
On Thu, Apr 17, 2014 at 8:41 AM, Daniel J Walsh wrote:
>
> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> The two use cases for this patch are:
>
> 1 Logging, to make sure the cgroup information gets correctly attributed
> to the caller.
>
I think that the cgroup information of the opener of the so
On Thu, 2014-04-17 at 08:41 -0700, Daniel J Walsh wrote:
> On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
> >>> On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote
On 04/16/2014 11:59 AM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
>>> On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
>>> I am not sure how same issue with happen with cgroups. In
On Wed, Apr 16, 2014 at 01:24:32PM -0700, Andy Lutomirski wrote:
[..]
> I'm not talking about the risk that someone learns someone's cgroup.
> I'm talking about the risk that a malicious program can get a lot
> entry like: "whatever planted text"
> _SYSTEMD_UNIT=non-malicious.service. That is, th
On Wed, Apr 16, 2014 at 12:39 PM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 12:13:21PM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 12:06 PM, Vivek Goyal wrote:
>> > On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote:
>> >> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal
On Wed, Apr 16, 2014 at 12:13:21PM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 12:06 PM, Vivek Goyal wrote:
> > On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal wrote:
> >> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, A
On Wed, Apr 16, 2014 at 12:06 PM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal wrote:
>> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
>> >
>> > [..]
>> >> > Ok, so passing cgroup inform
On Wed, Apr 16, 2014 at 11:35:13AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal wrote:
> > On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> >
> > [..]
> >> > Ok, so passing cgroup information is not necessarily a problem as long
> >> > as it is no
On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
> > On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
> > I am not sure how same issue with happen with cgroups. In the case of
> > socket example, you are forcing
On Wed, Apr 16, 2014 at 11:51 AM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 11:40:44AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 11:36 AM, Vivek Goyal wrote:
>> > On Wed, Apr 16, 2014 at 10:29:08AM -0700, Andy Lutomirski wrote:
>> >
>> > [..]
>> >> >> Admittedly cgroups aren't c
On Wed, Apr 16, 2014 at 11:40:44AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 11:36 AM, Vivek Goyal 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, th
On Wed, Apr 16, 2014 at 11:36 AM, Vivek Goyal 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 pr
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 an
On Wed, Apr 16, 2014 at 11:25 AM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
>
> [..]
>> > Ok, so passing cgroup information is not necessarily a problem as long
>> > as it is not used for authentication. So say somebody is just logging
>> > all the clien
On Wed, Apr 16, 2014 at 11:13:31AM -0700, Andy Lutomirski wrote:
[..]
> > Ok, so passing cgroup information is not necessarily a problem as long
> > as it is not used for authentication. So say somebody is just logging
> > all the client request and which cgroup client was in, that should not
> >
On Wed, Apr 16, 2014 at 11:06 AM, Vivek Goyal wrote:
> On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
> I am not sure how same issue with happen with cgroups. In the case of
> socket example, you are forcing a setuid program to write to standard
> output and that setuid program w
On Wed, Apr 16, 2014 at 09:31:25AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >> >
> >> > Please, just stop.
> >>
> >> No.
> >>
> >> Th
On Wed, Apr 16, 2014 at 10:34 AM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 10:29 -0700, Andy Lutomirski wrote:
>> Then please remove SO_PASSCGROUP.
>
> Can you stop demanding changes while demonstrating you haven't well
> understood the needs, let alone the consequences ?
>
> Take a day or 2, put
On Wed, 2014-04-16 at 10:29 -0700, Andy Lutomirski wrote:
> Then please remove SO_PASSCGROUP.
Can you stop demanding changes while demonstrating you haven't well
understood the needs, let alone the consequences ?
Take a day or 2, put your thoughts together and come back with a clear
description o
On Wed, Apr 16, 2014 at 10:02 AM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 09:31 -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
>> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
>> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
>> >> >
On Wed, 2014-04-16 at 09:31 -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
> > On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >> >
> >> > Please, just stop.
> >>
> >> No.
> >>
> >> This thre
On Wed, 2014-04-16 at 12:21 -0400, Tejun Heo wrote:
> Hello,
>
> On Wed, Apr 16, 2014 at 12:13:57PM -0400, Simo Sorce wrote:
> > The only one that *may* be reasonable is the "secret" cgroup name one,
> > however nobody seem to come up with a reason why it is legitimate to
> > allow to keep cgroup
On Wed, Apr 16, 2014 at 9:13 AM, Simo Sorce wrote:
> On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
>> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
>> >
>> > Please, just stop.
>>
>> No.
>>
>> This thread is proposing an ABI. This means that, if the ABI ends up
>> in Linus's k
Hello,
On Wed, Apr 16, 2014 at 12:13:57PM -0400, Simo Sorce wrote:
> The only one that *may* be reasonable is the "secret" cgroup name one,
> however nobody seem to come up with a reason why it is legitimate to
> allow to keep cgroup names secret.
Ugh, please don't play security games with cgroup
On Wed, 2014-04-16 at 07:37 -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
> >
> > Please, just stop.
>
> No.
>
> This thread is proposing an ABI. This means that, if the ABI ends up
> in Linus's kernel, then it has to be supported forever. Now is the
> ti
On Wed, Apr 16, 2014 at 07:34:41AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 16, 2014 at 3:17 AM, Vivek Goyal wrote:
> > On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
> >> On Apr 15, 2014 5:20 PM, "Vivek Goyal" wrote:
> >> >
> >> > On Tue, Apr 15, 2014 at 02:53:13PM -0700, An
On Wed, Apr 16, 2014 at 3:17 AM, Vivek Goyal wrote:
> On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
>> On Apr 15, 2014 5:20 PM, "Vivek Goyal" wrote:
>> >
>> > On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote:
>> > > On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal w
On Wed, Apr 16, 2014 at 5:57 AM, David Miller wrote:
>
> Please, just stop.
No.
This thread is proposing an ABI. This means that, if the ABI ends up
in Linus's kernel, then it has to be supported forever. Now is the
time to find and fix any issues with it before they become much harder
to fix.
Please, just stop.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Apr 15, 2014 at 08:47:54PM -0700, Andy Lutomirski wrote:
> On Apr 15, 2014 5:20 PM, "Vivek Goyal" wrote:
> >
> > On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote:
> > > On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> > > > This patch implements socket option SO_PASSCG
On Apr 15, 2014 5:20 PM, "Vivek Goyal" wrote:
>
> On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote:
> > On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> > > This patch implements socket option SO_PASSCGROUP along the lines of
> > > SO_PASSCRED.
> > >
> > > If SO_PASSCGROUP is
From: Vivek Goyal
Date: Tue, 15 Apr 2014 20:20:10 -0400
> On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote:
>> On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
>> > This patch implements socket option SO_PASSCGROUP along the lines of
>> > SO_PASSCRED.
>> >
>> > If SO_PASSCGROUP
On Tue, Apr 15, 2014 at 02:53:13PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> > This patch implements socket option SO_PASSCGROUP along the lines of
> > SO_PASSCRED.
> >
> > If SO_PASSCGROUP is set, then recvmsg() will get a control message
> > SCM_CGROUP
On Tue, 2014-04-15 at 14:53 -0700, Andy Lutomirski wrote:
> On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> > This patch implements socket option SO_PASSCGROUP along the lines of
> > SO_PASSCRED.
> >
> > If SO_PASSCGROUP is set, then recvmsg() will get a control message
> > SCM_CGROUP which
On Tue, Apr 15, 2014 at 2:15 PM, Vivek Goyal wrote:
> This patch implements socket option SO_PASSCGROUP along the lines of
> SO_PASSCRED.
>
> If SO_PASSCGROUP is set, then recvmsg() will get a control message
> SCM_CGROUP which will contain the cgroup path of sender. This cgroup
> belongs to first
74 matches
Mail list logo
