Bugzilla – Bug 769
Strange 'nosuid' error message with systemd's PrivateDevices
Last modified: 2017-01-13 10:05:15 MST
Hello, This might not be a bug in sudo, but I'd like to know what's going (to know what sudo needs) in case it turns out to be not a sudo bug, for reporting to the systemd project. The error message: sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? How to reproduce: # cat /etc/systemd/system/test-test.service [Unit] After=network.target [Service] ExecStart=/bin/bash -c "mount ; ls -alh /usr/bin/sudo ; sudo /sbin/ip" TimeoutStopSec=0 User=redis Group=redis Type=oneshot PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ReadOnlyDirectories=/ CapabilityBoundingSet=~CAP_SYS_PTRACE LimitNOFILE=120000 # redis-sentinel writes its own config file so we allow writing there (NB. # ProtectSystem=true over ProtectSystem=full) ProtectSystem=false [Install] WantedBy=multi-user.target #####################################xxx systemctl enable test-test systemctl start test-test And of course commenting out the PrivateDevices line results in sudo working as expected. sudo version: 1.8.19p1 systemd: 232 linux: 4.4.0-21 (ubuntu) Thanks!
This doesn't sound like a sudo bug. Sudo gives this message when it is run with an effective uid that is not 0. It will then check the permissions and owner on the sudo binary if possible. The message you received is what you get when the owner and permissions look OK but sudo is still being run with the wrong uid. I don't know why systemd's PrivateDevices would affect this, I would expect that behavior from NoNewPrivileges instead. I'm also not sure why you would want to use sudo here instead of just setting the User and Group in the service file to what is needed to run the command.
Thank you for the very quick response! This is a reduced version of the Redis Sentinel service file. It doesn't really need anything other than executing a script that manages the HA Virtual IP - so it calls /sbin/ip addr {add,del} ... and arping for gratuitous ARP. Okay, so sudo can't do anything, since it's not euid 0 (that is the +s flag had no effect). Alas the output from mount looks completely unexpected (minus the read only flag on /). Jan 12 01:53:25 gw01 systemd[1]: Starting test-test.service... Jan 12 01:53:25 gw01 bash[10967]: /dev/vda2 on / type ext4 (ro,relatime,errors=remount-ro,data=ordered) Jan 12 01:53:25 gw01 bash[10967]: tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=404680k,mode=755) ... and so on. Thanks again!
Closing since this doesn't appear to be a sudo issue.