Closed nerun closed 1 year ago
Thanks for the note. I will try to take a look at the issue this weekend. There may be some update necessary. I faintly remember there being some change in the sudoers syntax which may playing a part in this. For completeness: What version of sudo are you using?
sudo 1.9.9
Took a quick look and the sudoers config from the man-page still works without adjustments with sudo 1.9.13.p3
.
Just to make sure:
sudoers
config file contains a line with @includedir /etc/sudoers.d
?sudo tomb open (...)
instead of tomb open (...)
?Oh my... Yes to both questions. I run just tomb open (...)
and no sudo password was asked.
Resolved.
Sorry, i tried again and it asked for password. I remembered that terminal sessions store sudo password.
# BASED UPON tomb manual pages
# Section "PRIVILEGE ESCALATION"
# Command alias specification
Cmnd_Alias TOMB = /usr/bin/tomb
# Avoid that tomb execution is logged by syslog
Defaults!TOMB !syslog
# Allow all users to execute "tomb" without password
ALL ALL=NOPASSWD: TOMB
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults use_pty
# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"
# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"
# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"
# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"
# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"
# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"
# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "@include" directives:
@includedir /etc/sudoers.d
Config looks good.
Maybe my second question wasn't clear enough, but seeing the picture confirms the pitfall I also fell into :D I notice, that you still run tomb directly (unless you have a shell alias set?).
Instead of $ tomb lock tumba.lock -k tumba.tomb.key
you need to run $ sudo tomb lock tumba.lock -k tumba.tomb.key
.
The sudo calls in tomb itself are calling different tools which don't apply to the Cmnd_alias
and therefore the sudoers rule won't get applied. It isn't aware that it is called from within.
But calling tomb itself with sudo will apply the rule and the tools within.
See my picture
First call to open und close is with sudo and doesn't require the password. The second call to open and close is the default one. There the password is needed for the open and still cached for the close call.
And you can always set an alias in your .$SHELLrc
alias tomb='sudo tomb'
And if that still doesn't work check the output of whereis tomb
. The path reported for the script must match with the Cmnd_alias
path in sudoers.
Now it worked! I have used sudo tomb
, no sudo password was required. Even with sudo dig
the tomb is created with right ownership / group (user:user
not root:root
) it was one of my fears.
I have tested alias tomb=' sudo tomb'
, with space, and worked like a charm too!
THANK YOU VERY MUCH!
This is my
/etc/sudoers.d/tomb
:It works well, but not for
tomb lock
nortomb open
. They still requires sudo password. Any workaround?