8

Please consider a Linux system with a standard installation and configuration of sudo; that is, root can execute all commands, taking the identity of other users, and please consider the following command:

sudo -u user1 -g group1 some_program

Of course, I would expect that some_program gets executed with EUID user1 and with EGID group1. However, I have learned the very hard way that this works only if user1 is actually a member of group1; I really should have studied man sudo more thoroughly. From the explanation of the -g command line option:

[...] The sudoers policy permits any of the target user's groups to be specified via the -g option as long as the -P option is not in use.

This is very inconvenient. I often use sudo for testing purposes, especially when a service or program runs under arbitrary UIDs and GIDs, the respective user not being a member of the respective group. In such cases, before I can test with sudo, I have to make the respective user a member of the respective group and must not forget to revert that action when the tests are finished.

Hence the question: Is there a setting or configuration which allows root to sudo-execute programs using arbitrary UIDs and GIDs which do not match? I am only interested in solutions which provide a general mechanism for all programs, UIDs and GIDs. That is, putting lists of specific programs, UIDs or GIDs into /etc/sudoers is not an option.

One possible solution could be an alternative policy provider for sudo which would allow for that. However, learning how to install and configure it would probably be very hard, and I'm unsure about whether I'd take that route, even if there was no other solution. Furthermore, I haven't found such a thing so far.

UPDATE 1 (2022-01-27)

The system in question runs Debian buster, updated with all available patches at the time of writing this. SELinux is not installed. This is my /etc/sudoers file (leaving out only comments and empty lines):

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
ipupdate ALL = (root) NOPASSWD: /root/scripts/asterisk-external-ip

I currently believe that the last line does not have anything to do with the problem and that I probably should have removed it to minimize distraction. On the other hand, I have learned that sometimes it's just the seemingly unimportant "removed for clarity" parts which actually cause the respective error.

4
  • 1
    Provided your starting account is in the sudo group, then you should be able to pick any account name from /etc/passwd and/or any group name from /etc/group and have it work. (Except for ipupdate, of course.) For example on my system, sudo -u bind -g incron id gives me uid=111(bind) gid=123(incron) groups=123(incron),116(bind) Jan 27, 2022 at 19:15
  • Indeed, it's not the ipupdate command I'm testing :-) I have a program which runs under a certain UID and GID (started by a systemd unit) and which can't read read a certain file although it should, according to file and directory permissions. Now I am trying to debug the problem by executing sudo -u <user> -g <group> <program>, but then the program can't read the file either. The respective group has read and write permissions for the file, so either sudo doesn't execute the program as expected, or something else goes wrong; perhaps that program drops rights somehow (yet to investigate).
    – Binarus
    Jan 27, 2022 at 20:29
  • 1
    Remember you can also go interactive on this, sudo -u bind -g incron bash (or whatever). You can then dig around to try and identify why your program can't access the file Jan 27, 2022 at 22:13
  • Thank you! That's a very good idea which will make life easier. I'll for sure try that.
    – Binarus
    Jan 28, 2022 at 16:06

1 Answer 1

10

Executing a program in a different target group is the whole point of the -g option. And there's no restriction on combining -u with -g.

The sudoers policy permits any of the target user's groups to be specified via the -g option as long as the -P option is not in use.

It's not explained clearly, but what this sentence is referring to is what sudo lets you do out of the box, which is not the point of using sudo. Sudo is useful with additional policies in the sudoers file, and these can allow arbitrary sets of users and groups.

Root doesn't get any special permissions. If you can run sudo -u user1 as root or as a “sudoer” user, it's because there's a rule in the sudoers file that allows it. For some reason (maybe because the maintainer just never thought of updating it), in the sample sudoers file, this rule is

root        ALL = (ALL) ALL
%wheel      ALL = (ALL) ALL

This only allows the use of sudo -u, not of sudo -g, except the limited use of -g to specify the primary group among the groups that the user already one. To allow elevating group privileges as well as user privileges, change these rules (or whatever the equivalent on your system is, e.g. with %admin or %sudo or binarus etc.) to

root        ALL = (ALL:ALL) ALL
%wheel      ALL = (ALL:ALL) ALL

This is the default on some distributions, for example Debian.

5
  • Please excuse the late reply. Thank you very much for the answer, much appreciated and +1. But unfortunately, I already had the correct entries in /etc/sudoers (that is, the entries with (ALL:ALL)); this is a Debian buster system where I didn't touch the sudoers file yet. I'll add that file to my question in a few minutes.
    – Binarus
    Jan 27, 2022 at 18:54
  • OK, thanks again. Your answer is correct and accepted. I don't know what's going on with that specific program I was testing, though. Regardless of whether I'm starting it with sudo with the correct credentials or not, it can't read that specific file. But this should be made a matter of a separate question ...
    – Binarus
    Feb 5, 2022 at 16:23
  • @Binarus Is the program a bash script, or are you invoking it via a bash wrapper, by any chance? Bash drops privileges by default. Most other shells (e.g. dash) don't. Feb 5, 2022 at 21:26
  • The program in question is procmail. I am executing it directly (without a wrapper). The situation is complicated because procmail is installed SETUID root and SETGID mail, but seems to drop those privileges at some point when executing, returning back to the privileges of the user / group invoking it, which should be the user and group which I gave sudo at the command line by -u and -g. It's the -g part which gives me (understanding) problems. I'll have to investigate this later due to time constraints, but knowing at least that sudo -g works as expected is a good basis.
    – Binarus
    Feb 7, 2022 at 10:57
  • Oh, well, if the program is doing its own group management, that's a completely different problem. Sudo gives it the extra group you want, but then the program voluntarily removes it. Running sudo -g group1 sg group1 procmail … might work. Or maybe you need to drop all the other groups. Feb 7, 2022 at 13:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .