We add an exemptions file to /etc/sudoers.d on Linux platforms to enable elevated permissions for users in the sudoers or wheel groups. However, it appears that the sudo package, as configured by default in LEAP, does not follow these added exemptions even if the user is added to the wheel group. :\
If I select the sudo settings in YaST, my exemptions file entries are not present in the information presented in the GUI.
I have verified that the last entry in the /etc/sudoers file is the #includedir /etc/sudoers.d directive.
What do we need to modify so that the system properly recognizes the entries added into /etc/sudoers.d?
The openSUSE way of running things that should be run by root is different. It e.g. does not use the wheel group.
AFAIK the sudo configuration is by default that “running as root” always asks for he root password. (This is the same as what su does, thus I never use sudo, but that is of course a personal way of living).
So, when you want to change the security philosofy of an openSUSE system to that as used by several other distributions, I assume the best thing to do is to mimic what they do, like copying there suduers config, etc.
Or, when you realy think their way is better, use one of those instead of openSUSE
Not helpful, but okay, I understand defensive responses. We run all principle distros in the lab and have since Linus’ 0.99pl12 in 1993, so we already understand this. What I’m looking for is the user experience and what we as developers need to do to provide a similar user experience on all distros.
Since openSuSE uses the standard sudo package and the sudoers file is normal with the exception of the default changes to secure_path, targetpw, and env_keep, this should all just work as expected. Unfortunately, the sudo settings in YaST do not expose these changed settings and I believe that it should.
I understand my post was not realy helpful in that it offered you no direct solution to what your goal is.
What I tried is to explain that the “user experience” of most openSUSE users is the deafult as installed.
While it may be possible that someone with enough experience in both worlds turns up to help you, I tried to explain that not many here ever looked in what you want.
Although I absolutely do not support use of the wheel group by interactive Users,
It’s been my experience that you don’t really need to “sudo” to gain access to the wheel group because in openSUSE we aren’t forbidden from using root directly (su or su-) which is the case in may other distros…
So, why deal with sudo at all?
If you’re going to grant root permissions to Users, just make them members of the wheel group directly… both cross-distro command lines and YaST supports this.
And, of course I have to remind all others that this practice is highly, highly discouraged. Although a standard documented configuration in some other distros, this opens an enormous security vulnerability you can drive a MAC truck through…
Compare our common procedure in openSUSE which is to support elevated permissions in a console or application session for only as long as that console or app is open…
To making a User a member of the wheel group which makes any activity by that User using elevated permissions, not restricted by running only within a console or specific app.
My user experience, is that I almost never use “sudo” on openSUSE. I use “su” or “su -”, or I use
ssh root@localhost
with public key authentication. I never much cared for “sudo”.
If I’m stuck on Ubuntu, then I may use “sudo bash” to get a root shell. That Ubuntu forces one to use “sudo” is one of the reasons that I use openSUSE rather than Ubuntu.
I just stumbled upon this thread because I had a similar issue … Reading the OPs problem, you may have made the same mistake as myself: files in sudoers.d may not contain dots.
From sudoers(5):
For example, given: “@includedir /etc/sudoers.d”, sudo will …] read each file in /etc/sudoers.d, skipping file names that end in ‘~’ or contain a ‘.’ character …].
This causes files named according to the commonly used “NN-something.conf” convention to be skipped with @includedir.
Once I had figured this out, it worked for me.
For example, create /etc/sudoers.d/10-policy (without .conf!) as follows:
# Override the SUSE default policy - unset targetpw, and disallow all by default except for root
# This works because in sudoers files later statements overwrite previous ones.
Defaults !targetpw
# The following line is crucial with targetpw == false!
ALL ALL=(ALL) !ALL
# re-allow all for root
root ALL=(ALL) ALL
# This can be customized to whatever users or groups should be able to run all admin commands
User_Alias ADMIN_USERS = %wheel
ADMIN_USERS ALL=(ALL) ALL
Wrt the off-topic dicussion about the policy wrt “targetpw” and “%wheel”, I doubt that it has a large impact security-wise. The main advantage is that admins don’t have to remember (and know) the root password. This makes the attack surface slightly larger, because attackers “only” need to crack a password of any user in the “wheel” group. As long as the group has few users and a reasonable password strengh policy is in place, I don’t see this as a large threat. I use it for convenience (with myself as only member of “wheel”). I agree that it would make more sense if the set of commands allowed for the “wheel” group was somewhat limited, e.g. to installation of packages and basic network administration tasks.
Almost, but not quite – the “@includedir” directive is the current supported syntax – the other syntaxes are only supported for compatibility –
## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d
The man page –
Including other files from within sudoers
It is possible to include other sudoers files from within the sudoers file currently being parsed using the @include and
@includedir directives. For compatibility with sudo versions prior to 1.9.1, #include and #includedir are also accepted.
