Sudo announcement - upcoming changes
Hi all, I'm happy to inform you about upcoming changes in our openSUSE implementation of sudo. The first change is splitting configuration files between /etc and /usr/etc. More information about why we are introducing this change can be found here [1]. Sudo will read configuration files in the following order: /etc/sudoers, /usr/etc/sudoers. Our distribution file will be installed in /usr/etc/sudoers. If there is no /etc/sudoers file, the command visudo will open /usr/etc/sudoers and save the result as /etc/sudoers. If /etc/sudoers file already exists, there is no change in visudo behavior - it will open and edit /etc/sudoers. Big thanks to sudo upstream and Jason Sikes for this change. The second change relates to the configuration "Defaults targetpw" SUSE traditionally ships sudo with "Defaults targetpw". That allows any user in the system to use sudo without configuration by authenticating as the target user (usually root). An alternative authentication scheme used by some Linux distributions allows users who are members of a specific group to authenticate as root by typing their own password. So far, this model required manual configuration. To make this approach easier, we are now introducing the following optional packages: * sudo-policy-wheel-auth-self * sudo-policy-sudo-auth-self * system-group-sudo If installed, users in the wheel group (first package) or sudo group (second package) will be asked for their password instead of the password of the target account when executing the sudo command. There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users. So updating sudo is safe in any case. The third package (which will be installed as a dependency for the package sudo-policy- sudo-auth-self) creates a configuration file for systemd-sysusers, ensuring that the system group "sudo" will be created. *Please note the meaning of the wheel group is not well defined, so adding users to that group may have effects outside the scope of sudo.* In addition, those packages also install polkit policies so applications using polkit will be also allowed to authenticate in the same way. [1] https://en.opensuse.org/openSUSE:Packaging_UsrEtc Regards, Otto Hollmann
On Mon, 2023-10-30 at 17:15 +0100, Otto Hollmann wrote:
In addition, those packages also install polkit policies so applications using polkit will be also allowed to authenticate in the same way.
Does this mean that users in group "sudo" can open YaST with their own password? Will there be any differentiation between different YaST modules? Martin
On 10/31/23 06:13, Martin Wilck via openSUSE Factory wrote:
On Mon, 2023-10-30 at 17:15 +0100, Otto Hollmann wrote:
In addition, those packages also install polkit policies so applications using polkit will be also allowed to authenticate in the same way.
Does this mean that users in group "sudo" can open YaST with their own password? Will there be any differentiation between different YaST modules?
This might depend on how you launch Yast, currently when launched from a graphical desktop we are using xdg-su which calls gnomesu kde-su or fall back to su -c so I wouldn't expect a change in behavior with these usecases. If you are launching it with sudo from the command line obviously there probably would be a change. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hi, On 30. 10. 23, 17:15, Otto Hollmann wrote:
I'm happy to inform you about upcoming changes in our openSUSE implementation of sudo.
The first change is splitting configuration files between /etc and /usr/etc. More information about why we are introducing this change can be found here [1]. Sudo will read configuration files in the following order: /etc/sudoers, /usr/etc/sudoers. Our distribution file will be installed in /usr/etc/sudoers.
So now I am curious -- if /etc/sudoers exists, the /usr one *is* or *is not* read by sudo? If it is, /etc entries override /usr ones? If not, this would suck a heap as /usr/etc might be updated with new sudo and you won't even know, as no .rpmnew/save will be created (to update the /etc/ one). In fact, I hope {/usr,}/etc/sudoers.d/* is kept working (plus /usr/etc/ added to read list) and that's everyone should be happy with. In most cases noone wants to create full /etc/sudoers anyway. thanks, -- js suse labs
On 31/10/23 08:01, Jiri Slaby wrote:
So now I am curious -- if /etc/sudoers exists, the /usr one *is* or *is not* read by sudo? If it is, /etc entries override /usr ones? If not, this would suck a heap as /usr/etc might be updated with new sudo and you won't even know, as no .rpmnew/save will be created (to update the /etc/ one).
Thanks for asking, I had the same question. Also in the initial message Otto states:
Sudo will read configuration files in the following order: /etc/sudoers, /usr/etc/sudoers.
Does that mean that sudo will stop after the first file is found? Will subsequent files overrule existing configuration? If so we might have a problem, as user configuration should be preferred over system defaults. Best, phoenix
Thank you for questions. Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored. However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations. This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files. Do we still have a problem or is this an acceptable solution? Otto On Tue, 2023-10-31 at 10:27 +0100, Felix Niederwanger wrote:
On 31/10/23 08:01, Jiri Slaby wrote:
So now I am curious -- if /etc/sudoers exists, the /usr one *is* or *is not* read by sudo? If it is, /etc entries override /usr ones? If not, this would suck a heap as /usr/etc might be updated with new sudo and you won't even know, as no .rpmnew/save will be created (to update the /etc/ one).
Thanks for asking, I had the same question.
Also in the initial message Otto states:
> Sudo will read configuration files in the following order: /etc/sudoers, > /usr/etc/sudoers.
Does that mean that sudo will stop after the first file is found? Will subsequent files overrule existing configuration? If so we might have a problem, as user configuration should be preferred over system defaults.
Best, phoenix
On 31/10/23 12:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Thank you for the clarification. Now also the approach of copying the existing /usr/etc/sudoers to /etc/sudoers makes sense.
Otto
On Tue, 2023-10-31 at 10:27 +0100, Felix Niederwanger wrote:
On 31/10/23 08:01, Jiri Slaby wrote:
So now I am curious -- if /etc/sudoers exists, the /usr one *is* or *is not* read by sudo? If it is, /etc entries override /usr ones? If not, this would suck a heap as /usr/etc might be updated with new sudo and you won't even know, as no .rpmnew/save will be created (to update the /etc/ one).
Thanks for asking, I had the same question.
Also in the initial message Otto states:
> Sudo will read configuration files in the following order: /etc/sudoers, > /usr/etc/sudoers.
Does that mean that sudo will stop after the first file is found? Will subsequent files overrule existing configuration? If so we might have a problem, as user configuration should be preferred over system defaults.
Best, phoenix
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto, Will existing TW installs be migrated to this or do we have to do it manually ? For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ? Regards, Joe
On 31.10.2023 18:12, Joe Salmeri wrote:
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto,
Will existing TW installs be migrated to this or do we have to do it manually ?
For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ?
If file is removed from package, that file will be removed after update. I am not sure whether backup will be created for unmodified configuration file, I think not.
On 31. 10. 23, 18:21, Andrei Borzenkov wrote:
On 31.10.2023 18:12, Joe Salmeri wrote:
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto,
Will existing TW installs be migrated to this or do we have to do it manually ?
For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ?
If file is removed from package, that file will be removed after update. I am not sure whether backup will be created for unmodified configuration file, I think not.
Depends if it is marked as %config and with noreplace, right? And /etc/sudoers is both. So edited /etc/sudoers should be kept. Untouched /etc/sudoers should be deleted. -- js suse labs
@includedir /usr/etc/sudoers.d
Existing TW installations will be migrated only for users with unmodified /etc/sudoers. Unmodified /etc/sudoers file will be removed and replaced with /usr/etc/sudoers. However if you have modified /etc/sudoers it will *NOT* be migrated. The new file /usr/etc/sudoers will be installed, but as mentioned earlier, it will have no effect because it is overwritten by your /etc/sudoers. So users who modified /etc/sudoers file need to remove it (if it's safe) or at least add line if they want to use our new packages. Otto On Tue, 2023-10-31 at 11:12 -0400, Joe Salmeri wrote:
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto,
Will existing TW installs be migrated to this or do we have to do it manually ?
For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ?
Regards,
Joe
On Thu, Nov 2, 2023 at 3:02 PM Otto Hollmann <ohollmann@suse.cz> wrote:
Existing TW installations will be migrated only for users with unmodified /etc/sudoers. Unmodified /etc/sudoers file will be removed and replaced with /usr/etc/sudoers.
However if you have modified /etc/sudoers it will *NOT* be migrated. The new file /usr/etc/sudoers will be installed, but as mentioned earlier, it will have no effect because it is overwritten by your /etc/sudoers.
Are you sure? If a configuration file is removed from the package, rpm will rename it with the .rpmsave suffix, so file will not be present anymore. I suppose, %ghost'ing this file may prevent it.
You are right. During upgrade the sudoers file will be renamed to .rpmsave but then we move it back with this simple line: test -f %{_sysconfdir}/sudoers.rpmsave && mv -v %{_sysconfdir}/sudoers.rpmsave %{_sysconfdir}/sudoers ||: https://build.opensuse.org/package/rdiff/Base:System/sudo?opackage=sudo&oproject=openSUSE%3AFactory&rev=245#diff_1_n135 Otto On Thu, 2023-11-02 at 15:20 +0300, Andrei Borzenkov wrote:
On Thu, Nov 2, 2023 at 3:02 PM Otto Hollmann <ohollmann@suse.cz> wrote:
Existing TW installations will be migrated only for users with unmodified /etc/sudoers. Unmodified /etc/sudoers file will be removed and replaced with /usr/etc/sudoers.
However if you have modified /etc/sudoers it will *NOT* be migrated. The new file /usr/etc/sudoers will be installed, but as mentioned earlier, it will have no effect because it is overwritten by your /etc/sudoers.
Are you sure? If a configuration file is removed from the package, rpm will rename it with the .rpmsave suffix, so file will not be present anymore.
I suppose, %ghost'ing this file may prevent it.
On 11/2/23 06:43, Otto Hollmann wrote:
Existing TW installations will be migrated only for users with unmodified /etc/sudoers. Unmodified /etc/sudoers file will be removed and replaced with /usr/etc/sudoers.
However if you have modified /etc/sudoers it will *NOT* be migrated. The new file /usr/etc/sudoers will be installed, but as mentioned earlier, it will have no effect because it is overwritten by your /etc/sudoers.
@includedir /usr/etc/sudoers.d
So users who modified /etc/sudoers file need to remove it (if it's safe) or at least add line if they want to use our new packages.
Otto
On Tue, 2023-10-31 at 11:12 -0400, Joe Salmeri wrote:
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto,
Will existing TW installs be migrated to this or do we have to do it manually ?
For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ?
Regards,
Joe
Hi Otto, In my question, I asked if an /etc/sudoers that was not modified would be removed. When is this change ocurring ? I just updated to 20231031 and I still have my unmomdified /etc/sudoers and there is no /usr/etc/sudoers -- Regards, Joe
Changes are not yet released but there is a request for it: https://build.opensuse.org/request/show/1114990 and these announced changes will be in the next release. Unfortunately, I can't promise when it will be released. Otto On Thu, 2023-11-02 at 11:37 -0400, Joe Salmeri wrote:
On 11/2/23 06:43, Otto Hollmann wrote:
Existing TW installations will be migrated only for users with unmodified /etc/sudoers. Unmodified /etc/sudoers file will be removed and replaced with /usr/etc/sudoers.
However if you have modified /etc/sudoers it will *NOT* be migrated. The new file /usr/etc/sudoers will be installed, but as mentioned earlier, it will have no effect because it is overwritten by your /etc/sudoers.
@includedir /usr/etc/sudoers.d
So users who modified /etc/sudoers file need to remove it (if it's safe) or at least add line if they want to use our new packages.
Otto
On Tue, 2023-10-31 at 11:12 -0400, Joe Salmeri wrote:
On 10/31/23 07:01, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
This also corresponds with our recommendation (guids written by our doc team) to don't modify directly sudoers file but rather create your own file(s) in /etc/sudoers.d. If it's done this way, host-specific configuration files can coexist together with our distribution provided files.
Do we still have a problem or is this an acceptable solution?
Otto
Hi Otto,
Will existing TW installs be migrated to this or do we have to do it manually ?
For example, if a system has not modified /etc/sudoers ( the current location the install creates it ) when TW is updated to the build that includes this change will that file be removed since it was not overridden letting the system use the default in the new default location of /usr/etc/sudoers ?
Regards,
Joe
Hi Otto,
In my question, I asked if an /etc/sudoers that was not modified would be removed.
When is this change ocurring ?
I just updated to 20231031 and I still have my unmomdified /etc/sudoers and there is no /usr/etc/sudoers
On Tue, 2023-10-31 at 12:01 +0100, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
... and if both directories contain a file of the same name, both files will be read, right? This differs from the way e.g. systemd works, where /etc/sudoers.d/X would shadow /usr/etc/sudoers.d/X. Also, I suppose /etc/sudoers.d/01-xyz will be read after /usr/etc/sudoers.d/99-zxy? Can you quickly summarize again how sudo deals with directives that appear multiple times in the configuration? IIUC later directives in sudoers files override earlier ones, so that (for example) Defaults targetpw ALL ALL=(ALL) ALL can be overridden by a later Defaults !targetpw ALL ALL=(ALL) !ALL Correct? (I find it difficult to locate that information in the man page) Regards Martin
Hi Martin, you understand it correctly. If there are two config files with the same name /etc/sudoers.d/X and /usr/etc/sudoers.d/X both of them are read by sudo and both of them will take effect. Firstly, sudo reads and applies config file "sudoers", then all config files from /usr/etc/sudoers.d and at the end it will read and apply /etc/sudoers.d. The order of config files will be the same as it will be listed by command "ls /usr/etc/sudoers.d/ /etc/sudoers.d/" Regarding directives appearing multiple times, you are also right. A later occurrence of the same directive overwrites all it's previous occurrences. If you are not sure, you can always check it using "sudo -l". All relevant configuration directives will be shown and the last one (if there are multiple same directives) will take effect. Otto On Wed, 2023-11-08 at 17:16 +0100, Martin Wilck via openSUSE Factory wrote:
On Tue, 2023-10-31 at 12:01 +0100, Otto Hollmann wrote:
Thank you for questions.
Sudo will use the first file it found. So if /etc/sudoers file exists, /usr/etc/sudoers file will be ignored.
However this does not apply for included files. At the end of sudoers file we have the following lines: @includedir /usr/etc/sudoers.d @includedir /etc/sudoers.d So by default we will read from both locations.
... and if both directories contain a file of the same name, both files will be read, right? This differs from the way e.g. systemd works, where /etc/sudoers.d/X would shadow /usr/etc/sudoers.d/X.
Also, I suppose /etc/sudoers.d/01-xyz will be read after /usr/etc/sudoers.d/99-zxy?
Can you quickly summarize again how sudo deals with directives that appear multiple times in the configuration? IIUC later directives in sudoers files override earlier ones, so that (for example)
Defaults targetpw ALL ALL=(ALL) ALL
can be overridden by a later
Defaults !targetpw ALL ALL=(ALL) !ALL
Correct? (I find it difficult to locate that information in the man page)
Regards Martin
There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password. As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root.
Oct 31, 2023 22:07:55 Alexandre Almeida via openSUSE Factory <factory@lists.opensuse.org>:
There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password.
As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root. and it automatically rejects running sudo as root.
No distro has that as default AFAIK... and for some applications, especially in containers, that would be widely counterproductive (logging in to socket-auth based apps like Postgres for ex.)
As far as I understood and ever since I started my journey as a linux sysadmin, I never had sudo request the root password. if I want to use the root account, I just use the su command, which will request the root account password.
On 01.11.2023 00:19, Nicolas FORMICHELLA wrote:
Oct 31, 2023 22:07:55 Alexandre Almeida via openSUSE Factory <factory@lists.opensuse.org>:
There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password.
As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root. and it automatically rejects running sudo as root.
No distro has that as default AFAIK...
Ubuntu does not have ALL ALL=(ALL) ALL by default and only allows sudo for %admin and %sudo groups.
and for some applications, especially in containers, that would be widely counterproductive (logging in to socket-auth based apps like Postgres for ex.)
Nov 1, 2023 05:16:22 Andrei Borzenkov <arvidjaar@gmail.com>:
On 01.11.2023 00:19, Nicolas FORMICHELLA wrote:
Oct 31, 2023 22:07:55 Alexandre Almeida via openSUSE Factory <factory@lists.opensuse.org>: There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password.
As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root. and it automatically rejects running sudo as root.
No distro has that as default AFAIK...
Ubuntu does not have
ALL ALL=(ALL) ALL
by default and only allows sudo for %admin and %sudo groups.
and for some applications, especially in containers, that would be widely counterproductive (logging in to socket-auth based apps like Postgres for ex.) The original poster was talking about running sudo when logged in as root, not about the targetpw config
Which Ubuntu 22.04, as all distros allows by default
On Wed, Nov 1, 2023 at 7:59 AM Nicolas FORMICHELLA <stigpro@outlook.fr> wrote:
Nov 1, 2023 05:16:22 Andrei Borzenkov <arvidjaar@gmail.com>:
On 01.11.2023 00:19, Nicolas FORMICHELLA wrote:
Oct 31, 2023 22:07:55 Alexandre Almeida via openSUSE Factory <factory@lists.opensuse.org>: There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password.
As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root. and it automatically rejects running sudo as root.
No distro has that as default AFAIK...
Ubuntu does not have
ALL ALL=(ALL) ALL
by default and only allows sudo for %admin and %sudo groups.
and for some applications, especially in containers, that would be widely counterproductive (logging in to socket-auth based apps like Postgres for ex.) The original poster was talking about running sudo when logged in as root, not about the targetpw config
The original poster was talking about restricting sudo to the specific group(s) which Ubuntu does and this change in SUSE does not. Whether OP also wanted to prohibit running sudo when logged in as root is probably better clarified by OP.
Which Ubuntu 22.04, as all distros allows by default
I understand that using targetpw (asking for root password) is uncommon. But please keep in mind that we are not changing it. This configuration was always there. We only introducing optional packages to get closer to other distributions and optionally to get rid of shared root password. Personally I would like to remove it as well and "synchronize" with other distributions but the migration process will be complicated/impossible. Also there will be inconsistency between openSUSE and SLE. Otto
There is no change for users who are not in those special groups. sudo will continue to prompt for the target password for those users.
This is not the same behavior as other distros or common configuration guides for sudo. If I'm not mistaken, they setup sudo in a way that it doesn't ask for the root password.
As it seems, these packages won't do anything else but add this "if user in group X, ask for user password instead of root password" functionality. It would be nice to have the exact same behavior from the other distros, where you can only use sudo if you are a member of the group and it automatically rejects running sudo as root.
participants (9)
-
Alexandre Almeida -
Andrei Borzenkov -
Felix Niederwanger -
Jiri Slaby -
Joe Salmeri -
Martin Wilck -
Nicolas FORMICHELLA -
Otto Hollmann -
Simon Lees