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.len...@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.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
