Your idea would be easily doable by means of a small "set-userID-root" program which would only perform a setgroups(2)
with all the current groups (as per getgroups(2)
) except the sudo
one, effectively dropping it. The set-userID-root is required because setgroups(2)
is a privileged operation.
On Linux it could even be simpler as you could leverage the capabilities(7)
hence make the executable program setcap(8)
-ed to be CAP_SETGID
rather than set-userID-root. At that point such dedicated program would only need to capset(2)
itself to that capability before performing setgroups(2)
.
On the other hand, though, beware of dropping/changing group memberships inadvertently, because being member of a group is also used to reduce access rights e.g. to files & directories via ACLs purposefully placed.
That said, by leveraging the (Linux specific) setpriv(1)
command (if available on your system) you can harness a proof-of-concept made as a shell function, like the below in which I'm using sudo
itself (given that you are NOPASSWD
) as the "set-userID-root enabler":
# NOTE: this one uses Bash facilities
dropgrp() {
local groups grp="${1:?Specify group to drop}" IFS=; shift
IFS=: read -ra grent < <(getent group "$grp")
groups=(${GROUPS[@]/${grent[2]}})
IFS=,; sudo setpriv --reuid "$EUID" --regid "$GROUPS" --groups "${groups[*]}" "$@"
}
You would then run $ dropgrp sudo bundle
(the sudo
in there refers to the group name, not the command), and when that bundle
program invokes sudo
(the command) it will ask for your password to proceed.
sudo
group which I configured to sudo without password) – usretc Apr 28 '21 at 18:15