Very odd; a test executable chmod 4755 and chown root:root behaves as I would expect (start it as carl and ps aux shows it running as root). Same thing with dcpomatic2_disk_writer and ps aux shows it running as carl.

Built DoM in the Debian 10 VM and the built copy of dcpomatic2_disk_writer seems to behave as you'd expect.

So /usr/bin/dcpomatic2_disk_writer does not work but /usr/local/bin/dcpomatic2_disk_writer does.

Same thing seems to happen on Mageia 7.

Making a test program which drops privileges gives the same result in the output of ps aux i.e. maybe the setuid is working but something is dropping privileges. Doesn't really explain why it can't get them back again...

Building a test package on debug-uid to give some more debug output.

ruid, euid, suid are all 1000 at the top of main() in the suid-ed dcpomatic2_disk_writer

Looks like we need to do /sbin/setcap cap_setuid+ep /usr/bin/dcpomatic2_disk_writer

debug-uid branch has an attempt at this.

Doesn't explain why the self-built version works correctly with setuid...

That fix works so needs applying to Mageia also.

Tried it for RPM; Mageia 8 build needs testing, then see if that breaks any other RPM builds.

Maybe can use finer-grained capability?

• CAP_DAC_OVERRIDE
• CAP_FOWNER
• CAP_SYS_ADMIN
• CAP_SYS_RAWIO

i.e. don't setuid to root unless we're actually setuid, otherwise just do the operation.

CAP_DAC_OVERRIDE works.

CAP_FOWNER does not.

CAP_SYS_ADMIN does not

CAP_SYS_RAWIO does not.

12b8695cac964fb57adceb751126c199f8d0fe0f and nearby.