Bug 1205094 - Base:System/sudo: user is not in the sudoers file - after Update
Base:System/sudo: user is not in the sudoers file - after Update
Status: RESOLVED FIXED
: 1205106 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
x86-64 openSUSE Tumbleweed
: P2 - High : Major (vote)
: ---
Assigned To: Jason Sikes
E-mail List
:
Depends on:
Blocks: 1203978
  Show dependency treegraph
 
Reported: 2022-11-04 23:39 UTC by B
Modified: 2022-11-07 23:31 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
zypper update log (75.25 KB, text/x-log)
2022-11-06 00:37 UTC, ted chang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description B 2022-11-04 23:39:00 UTC
So, after updating tumbleweed, I was no longer able to use the sudo command and got the above error message.

NAME="openSUSE Tumbleweed"
# VERSION="20221103"

It seems the error stems from the revised patch (?):
https://build.opensuse.org/request/show/1032755


I was able to get the desired result: = entering the user password instead of root password after adding the apparently previous default settings from my system in yast after the update:
https://i.ibb.co/M9JZgpz/Bildschirmfoto-vom-2022-11-04-22-51-13.png
https://i.ibb.co/q92JdsP/Bildschirmfoto-vom-2022-11-04-22-51-26.png

works as expected, asks for user password now instead of root....



So if that's the intention, the patch needs to be revised again.
Comment 1 Andreas Stieger 2022-11-05 09:11:43 UTC
See bug 1203978 background, similar to bug 1205097
Comment 2 B 2022-11-05 12:04:57 UTC
sudo version
1.9.12-2.1

changelog

* Di Nov 01 2022 Jason Sikes <jsikes@suse.com>
- Modified sudo-sudoers.patch
  * [bsc#1203978 jsc#PED-260]
  * Remove uncommented "Defaults targetpw" portion of /etc/sudo-sudoers file.
  * Sudo now asks for the password of the user calling sudo instead of the
    target (i.e. root) user.
Comment 3 Milachew 2022-11-05 12:50:24 UTC
William, the change that you made affected TW users. Now all those who didn't touch the default settings have a broken sudo. These users are forced to enter here (or on build.opensuse.org) and read what happened in order to then fix the usual work of standard distribution commands in default configuration. Because they didn't receive any notifications or anything else.

I think it is necessary to undo the changes and make them only for new installations, since the current default installations are completely tied to the administrator password from the root user.
Comment 4 B 2022-11-05 12:52:05 UTC
(In reply to Milachew from comment #3)
> William, the change that you made affected TW users. Now all those who
> didn't touch the default settings have a broken sudo. These users are forced
> to enter here (or on build.opensuse.org) and read what happened in order to
> then fix the usual work of standard distribution commands in default
> configuration. Because they didn't receive any notifications or anything
> else.
> 
> I think it is necessary to undo the changes and make them only for new
> installations, since the current default installations are completely tied
> to the administrator password from the root user.

a not working sudo command won't give any good first impressions on new installations either.
Comment 5 Milachew 2022-11-05 13:10:16 UTC
(In reply to B from comment #4)
> a not working sudo command won't give any good first impressions on new
> installations either.
Did you try new installation?
Comment 6 B 2022-11-05 13:13:20 UTC
(In reply to Milachew from comment #5)
> (In reply to B from comment #4)
> > a not working sudo command won't give any good first impressions on new
> > installations either.
> Did you try new installation?

Yup, I did and the error is the same.
Comment 7 hui 2022-11-05 23:22:31 UTC
*** Bug 1205106 has been marked as a duplicate of this bug. ***
Comment 8 ted chang 2022-11-06 00:37:25 UTC
Created attachment 862672 [details]
zypper update log

--- /.snapshots/422/snapshot/etc/sudoers	2022-10-28 11:39:29.000000000 -0700
+++ /.snapshots/423/snapshot/etc/sudoers	2022-11-03 11:27:59.000000000 -0700
@@ -62,13 +62,6 @@
 # Defaults!REBOOT !log_output
 # Defaults maxseq = 1000
 
-## In the default (unconfigured) configuration, sudo asks for the root password.
-## This allows use of an ordinary user account for administration of a freshly
-## installed system. When configuring sudo, delete the two
-## following lines:
-Defaults targetpw   # ask for the password of the target user i.e. root
-ALL   ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
-
 ##
 ## Runas alias specification
 ##
@@ -84,5 +77,10 @@
 ## Same thing without a password
 # %wheel ALL=(ALL:ALL) NOPASSWD: ALL
 
+## Uncomment to allow any user to run sudo if they know the password
+## of the user they are running the command as (root by default).
+# Defaults targetpw  # Ask for the password of the target user
+# ALL ALL=(ALL:ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'
+
 ## Read drop-in files from /etc/sudoers.d
 @includedir /etc/sudoers.d

/etc/sudoers

I took a look in my btrfs snapper snapshot and one package modifies the sudoers file.

I attached an update log for today.
Comment 9 ted chang 2022-11-06 00:40:30 UTC
Nevermind B, seems to have it covered. I didn't need to attach anything since he always pinpoint the package etc.
Comment 10 B 2022-11-06 00:58:40 UTC
(In reply to ted chang from comment #8)
> Created attachment 862672 [details]
> zypper update log
> 
(...)

What I did in my first posts seems to be wrong in hindsight, as it just allows every user to access sudo with the user password (?) as I haven't uncommented the line - Defaults targetpw

What should be the default config now that apparently the user password should be used? 
Wheel group? back to targetpw? Personally I'm confused, why was there even a need to change this?
Comment 11 William Brown 2022-11-06 01:02:57 UTC
Hi there,

> "William, the change that you made affected TW users. Now all those who didn't touch the default settings have a broken sudo."

I did not make the change. I opened the original issue here: https://bugzilla.opensuse.org/show_bug.cgi?id=1203978 with internal references inside of SUSE, which states:

"""
The suggestion I would like to make to improve this is:

* Yast2 should request if the first-user account is an administrative role rather than requesting that the first-user account password is duplicated for root.
* If the first-user account is an administrative role, setting the root password is optional and locked by default.
* If the first-user account is not created as an administrative role, then the root password is a requirement.
* Sudo should be installed by default on JeOS/minimal installs.
* sshd_config should set "PermitRootLogin no" by default.
* sudoers by default should NOT contain the "defaults targetpw" line
"""

Additionally I involved both the sudo and yast maintainers for the feature development, as well as product management so they could coordinate and work with qe/qa, so that they could make the needed changes in coordination as well as testing it. 

I did not make the change. I highlighted that the default targetpw mode in SUSE and OpenSUSE in insecure and involved the needed parties.

Please be careful when you make accusations like this, especially when they are incorrect.

Mistakes happen. AutoQA is meant to catch and prevent this. This is clearly highlighting a failure in our tumbleweed testing.


As a result, my input to Jason would be that:

* We revert the change.
* We attempt to understand why this error was missed in AutoQA and how that impacted the a new install.
* That the Yast2 team is involved in the next time we attempt this update.
Comment 12 William Brown 2022-11-06 01:03:25 UTC
> What should be the default config now that apparently the user password
> should be used? 
> Wheel group? back to targetpw? Personally I'm confused, why was there even a
> need to change this?

The former targetpw is insecure.
Comment 13 Milachew 2022-11-06 07:51:45 UTC
(In reply to William Brown from comment #11)
> I did not make the change. I highlighted that the default targetpw mode in
> SUSE and OpenSUSE in insecure and involved the needed parties.
> 
> Please be careful when you make accusations like this, especially when they
> are incorrect.
 
Yes, you're right. I took a closer look at the changes on build.opensuse.org and I realized that I was wrong.
You are not directly involved in what happened to the sudo package in TW.

I apologize for finding you to blame for this.
 
> As a result, my input to Jason would be that:
> 
> * We revert the change.
> * We attempt to understand why this error was missed in AutoQA and how that
> impacted the a new install.
> * That the Yast2 team is involved in the next time we attempt this update.

I am glad that this particular change is really recognized as a mistake.
I hope that the necessary changes will be made in openQA to prevent such things as soon as possible.

By the way, rolling back the changes has already been proposed : https://build.opensuse.org/request/show/1033735

I will share your answer to dispel the opinion that such changes are normal in this way.
Also, I will mark this bug report "IN_PROGRESS" mark and close it as soon as the sudo behavior is fixed to working. If you think this is a duplicate of the original bug report, let me know or mark it.

Thank you for your reply!
Comment 14 Frank Krüger 2022-11-06 09:51:47 UTC
(In reply to Milachew from comment #13)
> (In reply to William Brown from comment #11)
> > I did not make the change. I highlighted that the default targetpw mode in
> > SUSE and OpenSUSE in insecure and involved the needed parties.
> > 
> > Please be careful when you make accusations like this, especially when they
> > are incorrect.
>  
> Yes, you're right. I took a closer look at the changes on build.opensuse.org
> and I realized that I was wrong.
> You are not directly involved in what happened to the sudo package in TW.
> 
> I apologize for finding you to blame for this.
>  
> > As a result, my input to Jason would be that:
> > 
> > * We revert the change.
> > * We attempt to understand why this error was missed in AutoQA and how that
> > impacted the a new install.
> > * That the Yast2 team is involved in the next time we attempt this update.
> 
> I am glad that this particular change is really recognized as a mistake.
> I hope that the necessary changes will be made in openQA to prevent such
> things as soon as possible.
> 
> By the way, rolling back the changes has already been proposed :
> https://build.opensuse.org/request/show/1033735

But what about TW users, who have been hit by this? Is there any solution in sight? Thx.
Comment 15 Milachew 2022-11-06 10:14:15 UTC
(In reply to Frank Krüger from comment #14)
> But what about TW users, who have been hit by this? Is there any solution in
> sight? Thx.

Since it is planned to revert the change, the fix will be available as soon as it is ready.
You can monitor this there : https://build.opensuse.org/request/show/1033735.
Or on the sudo page of Factory branch : https://build.opensuse.org/package/requests/openSUSE:Factory/sudo

But if you have already fixed the sudoers file yourself, the upcoming fixes will not affect you.
If not, just do a rollback via snapper and expect fixes.
Comment 16 Dominique Leuenberger 2022-11-07 08:27:02 UTC
I have reverted sudo back to the rev from before this change was introduced (and branched it into the Update channel to get a quicker update out to users)

https://build.opensuse.org/package/revisions/openSUSE:Factory/sudo (CVE patch that came in later was re-applied)

As for openQA: openQA DOES test sudo - but it seems it does not test the default config at all. The test actually adds explicit config entries for users (with and without password checks, via user name and via group membership)
Comment 17 Milachew 2022-11-07 11:02:34 UTC
(In reply to Dominique Leuenberger from comment #16)
> I have reverted sudo back to the rev from before this change was introduced
> (and branched it into the Update channel to get a quicker update out to
> users)

Good, thanks!

> As for openQA: openQA DOES test sudo - but it seems it does not test the
> default config at all. The test actually adds explicit config entries for
> users (with and without password checks, via user name and via group
> membership)

I think it would be great to add a default configuration check to exclude such cases. 
The fact that the default configuration with the update broke sudo brought several unpleasant impressions from users.

In any case, users have already reported that the corrected sudo has been shiped, so I close this bugreport.
Comment 18 William Brown 2022-11-07 23:31:12 UTC
> 
> I think it would be great to add a default configuration check to exclude
> such cases. 

Yes, there should be checks here, and if we attempt this again, we should be updating openQA in coordination. 

> The fact that the default configuration with the update broke sudo brought
> several unpleasant impressions from users.
> 
> In any case, users have already reported that the corrected sudo has been
> shiped, so I close this bugreport.

The sudo config we ship with targetpw mode is a degenerate su anyway, so they can just use su to work around.