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.hud...@canonical.com> wrote: > On 14 March 2017 at 12:21, John Lenton <john.len...@canonical.com> wrote: > >> On 13 March 2017 at 21:05, Michael Hudson-Doyle >> <michael.hud...@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@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
