DRAFT because I didn't test the Containerfile changes yet.
Also, the way it's currently implemented, I guess there's nothing stopping the user from abusing this script to run pretty much any command.... We're gonna have to think of a way to lock it down so the parameters constructed by the pre-sudo phase are not artificially constructed by the user in such a way that would allow them to execute more than we want them to. Maybe the sudo rule could restrict the first few arguments to be podman run ... instead of *.... No matter which approach I consider, I find very obvious holes...
Background
df8885777d2257a6271ca1a6461673d1d96e99d6
Issue
Running the script requires the user to be a full sudoer, which is not a great requirement to have.
Solution
Create a new group, ilab, and add a sudoers rule that allows users in the ilab group to run the wrapper-script as sudo without a password prompt.
Users will not actually run the script as sudo directly, but the script will re-run itself as sudo.
DRAFT because I didn't test the
Containerfile
changes yet.Also, the way it's currently implemented, I guess there's nothing stopping the user from abusing this script to run pretty much any command.... We're gonna have to think of a way to lock it down so the parameters constructed by the pre-sudo phase are not artificially constructed by the user in such a way that would allow them to execute more than we want them to. Maybe the
sudo
rule could restrict the first few arguments to bepodman run ...
instead of*
.... No matter which approach I consider, I find very obvious holes...Background
df8885777d2257a6271ca1a6461673d1d96e99d6
Issue
Running the script requires the user to be a full sudoer, which is not a great requirement to have.
Solution
Create a new group,
ilab
, and add a sudoers rule that allows users in theilab
group to run the wrapper-script as sudo without a password prompt.Users will not actually run the script as sudo directly, but the script will re-run itself as sudo.