Part 2! Request for help / ideas to debug issue

[John Lenton]

I've filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819
and https://github.com/golang/go/issues/19546

(the latter more of an FYI than a bug)

On 14 March 2017 at 10:56, John Lenton <john.lenton at canonical.com> wrote:
> As a followup, I added a mutex around pthread_create, and around the
> exec syscall, and the problem went away. This all in go's runtime; not
> a huge diff but they probably don't want the overhead (and that seems
> reasonable to me).
> Next I'm going to try to find a kernel person to take a look at this.
>
> On 13 March 2017 at 23:33, Michael Hudson-Doyle
> <michael.hudson at canonical.com> wrote:
>> On 14 March 2017 at 12:21, John Lenton <john.lenton at canonical.com> wrote:
>>
>>> On 13 March 2017 at 21:05, Michael Hudson-Doyle
>>> <michael.hudson at canonical.com> wrote:
>>> > If I add a
>>> > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit
>>> > is respected every time.
>>>
>>> on my way to bed, I'll give your response a proper read in the
>>> morning, but note that my reproducer causes the issue a lot more
>>> frequently than in "the real world" (snap run calling snap-confine
>>> calling snap-exec), where delays are happening naturally (because the
>>> programs aren't just calling exec, they actually have work to do :-p).
>>> I don't have numbers for how often it happens in snappy; it's a lot
>>> less frequent, but often enough to be annoying when working
>>> interactively (and there are bug reports with these warnings/errors in
>>> lp already).
>>
>>
>> Oh yes, the sleep was just to allow the other threads to settle in the test
>> case program. It's not a solution for the real world at all.
>>
>> Cheers,
>> mwh
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft