Avoid segfault in sudo execution
For weeks now I have been struggling with a weird problem on 2 machines (not all of my Arch boxes, only some of them). It started with staging-x86_64-build
not working (while other variants worked) then it spread to be custom makechrootpkg
invocations, then to extra-x86_64-build
, and lastly to another machine. I've tried blowing away the chroots and rebuilting them, reinstalled the tooling, etc. and nothing seems to touch the problem. The manifestation is simple. Right after integrity checks, I get a sefgault as it transitions to running makepkg
in the chroot:
/chrootbuild: line 3: 3 Segmentation fault (core dumped) sudo --preserve-env=SOURCE_DATE_EPOCH -iu builduser bash -c 'cd /startdir; makepkg "$@"' -bash "$@"
Every time. Any package. Any chroot.
I tried messing around with this line with just generic sudo
commands like sudo true
and found either -i
or -u
work fine in isolation, it is the combination of them that causes sudo to segfault (e.g. sudo -iu builduser true
will segfault). Since -u
is required here and I could not figure out why -i
is required, I just removed it and found my builds all work fine.
I don't know if this is needed for some edge cases, hence this might be the wrong fix, but I'm at least opening this Draft for comment to bring attention to the problem.
Merge request reports
Activity
Created by: foutrelis
Good news! This is a bug in sudo that has already been resolved by upstream. I'll push a new package to testing with the fix.
Amazingly specific yes, but at the same time I don't understand why for weeks I've been the only one having this problem with Arch tooling. I've been using normal up to date Arch systems and freshly minted chroots and the default tooling. Why did this just hit me when everyone else was fine?
About this PR, even if the bug is fixed in
sudo
upstream I have to wonder whether the interactive flag should be here. Given the use case inside a chroot inside a scripted built, if the interactive flag makes a difference for some builds that something else might be amiss. Would it be wrong to drop this anyway?added resolutionupstream label