I’m noticing that when running sudo in 16.0, it asks for my user password instead of the root password. I also notice when using the “groups” command, I am in the “wheel” group, one I had not been aware of before. I’ve read where some in the past objected to openSUSE asking for the root password. Has the policy changed now to ask for the user password?
Yes, the new installs follow what has been the standard for other distributions for some time…
Tumbleweed upgrades of systems with the prior openSUSE standard maintain the old behaviour and I think that Leap 15.6 systems upgraded to 16.0 do the same (but didnt check myself).
It is possible to change by editing the sudoers file, if you need it I may search for the details (or more knowledgeable members might chime in…)
1 Like
No, I don’t think I need to change. I’m just surprised my user was executing privileged commands. Guess that’s what the “wheel” group is for. I had seen arguments for it being different than other distributions. Any idea why those arguments no longer apply?
This is done with the sudo-policy-wheel-auth-self package. You can simply uninstall it if you don’t like the behavior.
% rpm -ql sudo-policy-wheel-auth-self
/usr/etc/sudoers.d/50-wheel-auth-self
/usr/share/polkit-1
/usr/share/polkit-1/rules.d
/usr/share/polkit-1/rules.d/51-wheel.rules
% sudo cat /usr/etc/sudoers.d/50-wheel-auth-self
Defaults:%wheel !targetpw
%wheel ALL = (root) ALL
The rationale is that Debian and Ubuntu have been doing this since forever, and that you can grant a user root privileges without giving them the root password.
This is also a blueprint how to give a user or a group of users limited privileges like printer administration.
1 Like
1 Like
Oh, I see now. That could be an issue on a multi-user system!
In the old Yast, there was Users which allowed one to be added to the printer group. Did adding a user to groups not meet that need?
Thanks. That sheds light on it. I was afraid I had changed something so it was asking for my user password instead of root and I was worried it was something I messed up. Seems reasonable thing.
CUPS uses the lp user group (package system-user-lp).
I also recall a user group lpadmin, but I am not sure if that one still exists; I don’t have it on my systems anymore, and there is also no corresponding system-user-lpadmin package. Maybe the lpadmin group is a thing of the past.
Maybe printer administration wasn’t the best possible example, but you get the idea.
BTW I like that so many of those things are now consistently handled by packages that you can install or not, and each one contains a configuration snippet for a file somewhere in /usr/etc/somesubsystem.d/ that you can also override with a counterpart in /etc/somesubsystem.d/. The usrmerge begins to make a lot of sense.
1 Like
Actually CUPS administration is configured to use root group by default (cups-files.conf)…
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User lp
#Group lp
# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup root
1 Like
11 posts were split to a new topic: Leap 16 sudo / wheel security model discussion
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.