but, at the command line, you are attempting to execute:
/usr/bin/systemctl stop vdr
A solution: Add both variations to your sudoers file:
martin ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop vdr
martin ALL=(ALL) NOPASSWD: /usr/bin/systemctl stop vdr.service
BTW, a good practice it to place custom sudoders rules into files created in /etc/sudoers.d directory. Such a file can be created with one of the following commands:
That means it works fine. If you execute it without sudo, you are getting prompted by polkit to elevate privileges and i am nut sure but apparently, it doesn’t read /etc/sudoers file.
created the custom sudoers rule as mentioned in /etc/sudoers.d directory, but it still asks for the password.
the following sudoers rules are read from the /etc/sudoers file:
[martin@fc36 ~]$ sudo -l -U martin
Matching Defaults entries for martin on fc36:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/var/lib/snapd/snap/bin
User martin may run the following commands on fc36:
(ALL) ALL
(ALL) NOPASSWD: /usr/bin/systemctl stop vdr
(ALL) NOPASSWD: /usr/bin/systemctl stop vdr.service
password request as user martin:
[martin@fc36 ~]$ /usr/bin/systemctl stop vdr
Failed to stop vdr.service: Access denied
See system logs and 'systemctl status vdr.service' for details.
Now, systemctl {start|stop|restart} vdr (even without sudo) shouldn’t ask for a password anymore.
Yes, polkit is way more complicated than sudo, but it is where the world is going today. However, as you could imagine, it allows to assign more fine grained authorizations in the modern world.
the polkit rules sounds reasonable.
The reason for my request is that I want to wake up my Video Disk Recorder (VDR) from sleep (suspend mode) via a desktop script.
For this I made the desktop icons visible again under Fedora 36 and created 2 desktop scripts (Start\ VDR.desktop + Stop\ VDR.desktop) and another script (vdr_start_stop). If I now want to control the call via polkit then it will probably be very long or what do you think ?
This should do a good and secure policy change, only wheel is allowed. I think this should be standard behavior, as well as with other things like mounting LUKS drives. It is very annoying how it currently is.
Is martin a member of the wheel group? That line above seems to indicate the possibility.
If so then any command that does not ‘exactly’ match the specialized command for that user will fall over to the next available option and since a wheel member is required to enter the password now the password is required.
This one shows what I suspect to be the ‘wheel’ entry before the custom entries, so it would always require the password. The permission is granted at the first entry to match.
I always allow wheel members to use the entry in the sudoers file and put specialized entries for other users in /etc/sudoers.d/ This avoids conflicts between the config for the wheel group and for individual users. The individual users should not be a member of the wheel group. As you can see, privileges may conflict.
Yes the group is created, but the user has to be added to it. It had no effect on the password prompt for me though. So I wonder if just allowing the commands for all wheel users would be enough to avoid them.
