Part 2! Request for help / ideas to debug issue

[John Lenton]

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