Through plugins or features of sudo it's possible to allow/deny running specific commands (I know, obvious :).
It can be difficult for a sudo user to understand why a command execution is denied. sudo will indicate which, and how, but not why - this is fine for a simple configuration, but may be confusing for more complex configurations.
The proposal is to support an extended message which allows the administrator of the system to include additional information or/and link to their own guidance (usually good when some specific commands are allowed, but most are denied).
Typical workflow and message:
$ sudo /bin/test
Password:
Sorry, user test is not allowed to execute `/bin/test` as root on machine-hostname-here.
Proposed change in this PR:
$ sudo /bin/test
Password:
Sorry, user test is not allowed to execute `/bin/test` as root on machine-hostname-here.
Executing commands as a different user is forbidden on this host, see https://docs.here or `less /usr/share/docs/sudo.txt` for more information on which commands are allowed.
Where the additional sentence is customizable, as per PR below.
Note: I considered customizing the initial message ("Sorry, user xxx is not allowed ... ") however, this requires more significant changes to sudo with perhaps little value (e.g. using an argument list for messages and having the option to add these in configuration with special syntax). I saw that the auth failure message handler does this, however, it is only for one argument, and thus seemed reasonable. The command denial on the other hand would be several arguments and did not seem as reasonable.
Through plugins or features of sudo it's possible to allow/deny running specific commands (I know, obvious :).
It can be difficult for a sudo user to understand why a command execution is denied. sudo will indicate which, and how, but not why - this is fine for a simple configuration, but may be confusing for more complex configurations.
The proposal is to support an extended message which allows the administrator of the system to include additional information or/and link to their own guidance (usually good when some specific commands are allowed, but most are denied).
Typical workflow and message:
Proposed change in this PR:
Where the additional sentence is customizable, as per PR below.
Note: I considered customizing the initial message ("Sorry, user xxx is not allowed ... ") however, this requires more significant changes to sudo with perhaps little value (e.g. using an argument list for messages and having the option to add these in configuration with special syntax). I saw that the auth failure message handler does this, however, it is only for one argument, and thus seemed reasonable. The command denial on the other hand would be several arguments and did not seem as reasonable.