Am 04.11.22 um 19:49 schrieb Scott Bradnick:

These lines in /etc/sudoers should make that happen, do you have them?

They have been removed intentionally: https://bugzilla.opensuse.org/show_bug.cgi?id=1203978

Scott Bradnick wrote:

Maybe so, but I'm on 20221103 and with those lines there it works as I'd been accustomed to it working since I first started using openSUSE/SUSE. I'm not so sure it's a "bug" in the classic sense and more of a shift in [initial] setup paradigms; basically an awareness thing and tempering expectations. That being said, I don't actually use this mechanism of sudo, so it didn't "bite" me, but this post caught my eye since I generally disable this functionality anyway.

Whoever edits the sudoers file wont't have it being replaced by new versions of the file that the distributions releases. Instead, they'll have a /etc/sudoers.rpmnew extra file with the new content. Only those who never edited the file will get bit by this change that shouldn't have happened on Tumbleweed without discussing it. That bug is targeted for ALP, and in the future SLE 6+. And even if this change was discussed/approved, someone should've tested them manually to make sure sudo won't end up broken.

Patrick Shanahan wrote:

my sudo.conf has been edited, and exists in /etc but there is no rpmnew copy, on six boxes.

You're misunderstanding something Patrick. We're talking about the /etc/sudoers file exactly, which is provided by the distro. Now, sudo.conf, under /etc, will only be there if the user/admin creates it, OK? If you go to the sudo spec file (as well as any other package that's still placing config file under /etc), you can see something similar to:

%config(noreplace) %{_sysconfdir}/foo

that gets expanded to:

/etc/foo

And if the user edits /etc/foo, that "noreplace" will shield the file so that new versions (which changes the content of the file) don't replace whatever the user edited. A /etc/foo.rpmnew will be created with the new content of /etc/foo instead.

Andrei Borzenkov wrote:

On 05.11.2022 00:41, Luciano Santos wrote:

...

Patrick Shanahan wrote: my sudo.conf has been edited, and exists in /etc but there is no rpmnew copy, on six boxes. You're misunderstanding something Patrick. We're talking about the /etc/sudoers file exactly, which is provided by the distro. Now, sudo.conf, under /etc, will only be there if the user/admin creates it, OK? /etvc/sudo.conf is part of and installed by sudo package. If you go to the sudo spec file (as well as any other package that's still placing config file under /etc), you can see something similar to: %config(noreplace) %{_sysconfdir}/foo You may consider following your own advice :) bor@tw:~> rpm -q --qf '[%{filenames} %{fileflags:fflags}\n]' sudo /etc/sudo.conf cn

Indeed, that's my bad. Sorry for the misinformation Patrick S..

On Fri, 2022-11-04 at 19:17 +0000, Luciano Santos wrote:

Scott Bradnick wrote:

...

Maybe so, but I'm on 20221103 and with those lines there it works as I'd been accustomed to it working since I first started using openSUSE/SUSE. I'm not so sure it's a "bug" in the classic sense and more of a shift in [initial] setup paradigms; basically an awareness thing and tempering expectations. That being said, I don't actually use this mechanism of sudo, so it didn't "bite" me, but this post caught my eye since I generally disable this functionality anyway.

Whoever edits the sudoers file wont't have it being replaced by new versions of the file that the distributions releases. Instead, they'll have a /etc/sudoers.rpmnew extra file with the new content.

Only those who never edited the file will get bit by this change that shouldn't have happened on Tumbleweed without discussing it. That bug is targeted for ALP, and in the future SLE 6+.

And even if this change was discussed/approved, someone should've tested them manually to make sure sudo won't end up broken.

I agree with you; I threw my 2¢ in because I figured those lines being present/active in /etc/sudoers would solve the issue in this specific case. My /etc/sudoers (where it was already commented out) wasn't touched; I do have an /etc/sudoers.rpmnew w/ those lines commented out. -- ~ Scott Bradnick |- Windows Subsystem for Linux (WSL) Developer |-- Tumbleweed: |--- Dell Precision 5540 [NVIDIA Quadro T1000] (x86_64) |--- O-DROID H2+ [UHD Graphics 600] (x86_64) |--- IceWhale ZimaBoard 832 [Intel HD Graphics 500] (x86_64) |--- 2x Raspberry Pi 4 Model B Rev 1.2 (aarch64) |--- 1x Raspberry Pi 3 Model B Rev 1.2 (aarch64) |--- WinBook TW100 (x86_64) https://keys.openpgp.org/ :: DBC5AA9A2D2BAEBC

Il 04/11/22 18:46, Luciano Santos ha scritto:

Scott Bradnick wrote:

...

I agree with you; I threw my 2¢ in because I figured those lines being present/active in /etc/sudoers would solve the issue in this specific case. My /etc/sudoers (where it was already commented out) wasn't touched; I do have an /etc/sudoers.rpmnew w/ those lines commented out. But you're right about throwing those lines back.

And for the record, if anyone end up in this situation post DUP with sudo broken and do want to rollback the system (there's really no need to, in this case). Just go to YaST and revert the last changes to /etc/sudoers, as was pointed out in the openSUSE support IRC/Matrix room.

Cheers,

Luciano I had to apply the following step to resolve the issue:

For now there is a way to go back without reverting: # visudo -f /etc/sudoers.d/user Defaults targetpw # Ask for the password of the target user ALL ALL=(ALL:ALL) ALL # WARNING: only use this together with 'Defaults targetpw' ----------- Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20221103 Kernel: 6.0.6-1-default - XFCE: (4.16.0)

This may be slightly off topic, but why is /etc/sudoers being modified in an update at all? I thought that several months ago there was a big announcement that all distribution configuration files would be put in /usr/etc and only admin modified files would be placed in /etc. On 11/4/22 14:46, Luciano Santos wrote:

Scott Bradnick wrote:

...

I agree with you; I threw my 2¢ in because I figured those lines being present/active in /etc/sudoers would solve the issue in this specific case. My /etc/sudoers (where it was already commented out) wasn't touched; I do have an /etc/sudoers.rpmnew w/ those lines commented out. But you're right about throwing those lines back.

And for the record, if anyone end up in this situation post DUP with sudo broken and do want to rollback the system (there's really no need to, in this case). Just go to YaST and revert the last changes to /etc/sudoers, as was pointed out in the openSUSE support IRC/Matrix room.

Cheers,

Luciano

Am 06.11.22 um 20:01 schrieb Luciano Santos:

Bruce Anderson wrote:

...

This may be slightly off topic, but why is /etc/sudoers being modified in an update at all? I thought that several months ago there was a big announcement that all distribution configuration files would be put in /usr/etc and only admin modified files would be placed in /etc.

AFAICT, this still is an ongoing effort.

Maybe you should add a comment here: https://bugzilla.opensuse.org/show_bug.cgi?id=1152770 Regards, Frank

Bruce Anderson wrote:

This may be slightly off topic, but why is /etc/sudoers being modified in an update at all? I thought that several months ago there was a big announcement that all distribution configuration files would be put in /usr/etc and only admin modified files would be placed in /etc.

Actually it's not off topic. Let me summarize it for you. A bug [1] was filed for the ALP product -yes ALP, not Tumbleweed- pointing out the current practice of using "targetpw" for sudo, and possibly change this behavior. That makes sense as ALP seems to be the next stable openSUSE release, after Leap [2]. And, if there's any security enhancements to be done, this is a good time for them, so that changes can be tested as early/much as possible. Currently, a default openSUSE Leap/Tumbleweed installation offers to use the same password for both the normal user being created and the super user root (this seems to be more of a convenience for the majority of users that won't share their systems with someone else, you only have to remember one password, not two). And the sudo command, before that change, would ask for the root password (the "Defaults targetpw" line that got removed) instead of the user's. Now, I don't know why on earth that change ended up in openSUSE:Factory and in Tumbleweed/MicroOS eventually, since there's already a SUSE:ALP project [3] (that even have some prototype images for people to test it, already [4]). From my perspective, it was a careless move made by one of the SUDO package's maintainers, a change that I don't think was manually tested by someone. And let's suppose that that change (make the sudo command ask for the user's password instead of the root super user, by default) was really suppose to happen in openSUSE:Factory, and in Tumbleweed/MicroOS eventually. I'm sure there are ways of making that happens _without_ breaking sudo. [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1203978 [2] https://news.opensuse.org/tag/adaptable-linux-platform [3] https://build.opensuse.org/project/show/SUSE:ALP [4] https://download.opensuse.org/repositories/SUSE:/ALP/images/

On 05.11.2022 12:42, Stefan Seyfried wrote:

On 04.11.22 20:17, Luciano Santos wrote:

...

Whoever edits the sudoers file wont't have it being replaced by new versions of the file that the distributions releases. Instead, they'll have a /etc/sudoers.rpmnew extra file with the new content.

Only those who never edited the file will get bit by this change that shouldn't have happened on Tumbleweed without discussing it. That bug is targeted for ALP, and in the future SLE 6+.

I don't think many people nowadays edit /etc/sudoers, since ages you can just drop a file in /etc/sudoers.d/ if you need something changed.

Of course that default of "Defaults targetpw" should have been in such a drop-in file and not in the main config, so that it would be easy to override, but that just never has been done.

How exactly would it change anything? Next update removing drop-in with "Default targetpw" would have exactly the same effect. And overriding it is just as simple now, just add whatever rules you need to to your own drop-in. Of course this requires that users actually try to learn tools they are using and read documentation and manual pages. Which again cannot be fixed by shuffling files around.

On 07.11.22 02:49, Luciano Santos wrote:

Hi Andrei, I think Stefan is just pointing out that the distro should've used a drop-in config file, under /etc/sudoers.d, for the "targetpw" as a good practice, more than anything.

But Stefan, here I'm afraid I disagree with you. In my point of view, the distro should offer a "canonical" sudoers file (under /usr/etc, preferably, so sysadmins can override it with their own /etc/sudoers) with whatever diversions from upstream they deem necessary. And atomic changes to the default behavior should be done using drop-in config files.

My idea with the drop-in (not completely speled out in the previous mail) was, that the "targetpw" could e.g. be part of an add-on package that would have been installed automatically on system updates, but not on new installations or something like that. And yes, managing config updates one way or the other is always hard. Sometimes you really want the updated config for almost everyone and sometimes you don't. I somehow like the debian approach of listing up the changed files, allowing to show the difference and then having the user decide "new, old, edit", at least as an option. But I also have not used it in practice to automatically update thousands of servers at once ;-) In this particular case, an advance warning on this list would certainly have helped. I personally read most of the "new tw snapshot mails" but often not as thorough to find such hidden gems in the changelogs.

Fedora, for example, has its own sudoers file [1] that makes use of the WHEEL group and any command can be ran as root, as long as they are in the WHEEL group (and the user is by default, at least the first created user is).

Debian/Ubuntu, too, has their own sudoers file [2]. Similar mechanism as Fedora, but they make use of the SUDO group instead.

This would probably be a nice area for inter-distribution cooperation. Or let's just wait until systemd absorbs sudo and everyone has to use that then ;-) Have fun, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On 2022-11-07 07:36, Stefan Seyfried wrote:

On 07.11.22 02:49, Luciano Santos wrote:

...

Hi Andrei, I think Stefan is just pointing out that the distro should've used a drop-in config file, under /etc/sudoers.d, for the "targetpw" as a good practice, more than anything.

But Stefan, here I'm afraid I disagree with you. In my point of view, the distro should offer a "canonical" sudoers file (under /usr/etc, preferably, so sysadmins can override it with their own /etc/sudoers) with whatever diversions from upstream they deem necessary. And atomic changes to the default behavior should be done using drop-in config files.

My idea with the drop-in (not completely speled out in the previous mail) was, that the "targetpw" could e.g. be part of an add-on package that would have been installed automatically on system updates, but not on new installations or something like that.

I think SLES does that. An add on package enables the wheel thing.

And yes, managing config updates one way or the other is always hard. Sometimes you really want the updated config for almost everyone and sometimes you don't. I somehow like the debian approach of listing up the changed files, allowing to show the difference and then having the user decide "new, old, edit", at least as an option. But I also have not used it in practice to automatically update thousands of servers at once ;-)

In this particular case, an advance warning on this list would certainly have helped. I personally read most of the "new tw snapshot mails" but often not as thorough to find such hidden gems in the changelogs.

Yes. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On Sat, 5 Nov 2022 12:38:51 +0100 Liam Proven wrote:

On Fri, 4 Nov 2022 at 19:16, Bob Williams wrote:

...

I have just done a zypper dup to snapshot 20221103, and now sudo asks for my user password rather than root's password:

Um. I don't use openSUSE much any more since I left SUSE but that is normal, intentional and desired behaviour for `sudo`.

The idea of SUDo (Super User Do) is that you can "do" things as the Superuser without being the superuser, knowing the superuser account password, or there even being a superuser or a password.

It should not accept the root password. It is asking for _yours_.

But mine doesn't work... bob@antikythera:~> sudo zypper dup [sudo] password for bob: bob is not in the sudoers file. This incident has been reported to the administrator. ...since upgrading to snapshot 20221103 -- Bob Williams No HTML please. Plain text preferred. https://useplaintext.email/