Bug 1221686

Summary: Default installation of Tumbleweed with Plasma has been asking for root password instead of user password when doing sudo
Product: [openSUSE] openSUSE Tumbleweed Reporter: arctic summer <tofldr+bd58ze2mrgtss>
Component: SecurityAssignee: Otto Hollmann <otto.hollmann>
Status: RESOLVED FIXED QA Contact: Otto Hollmann <otto.hollmann>
Severity: Normal    
Priority: P5 - None CC: meissner
Version: Current   
Target Milestone: ---   
Hardware: 64bit   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description arctic summer 2024-03-19 11:26:52 UTC
Default installation of Tumbleweed with Plasma has been asking for root password instead of user password when doing sudo.

$ sudo -i
[sudo] password for root: 

It still accepts the user password. The root password is not set during installation (presumably).

Although this behavior can easily be changed by using visudo, it is not an ideal default.

Also, kdesu asks for root password instead of user password.


These lines are in the sudoers file by default:

Defaults targetpw
ALL    ALL=(ALL) ALL

So, what is going on?
Comment 1 Stefan Hundhammer 2024-03-19 11:54:55 UTC
Why would this be a problem of THE INSTALLER (YaST) when you already know that it's a problem of that package?
Comment 2 Stefan Hundhammer 2024-03-19 12:01:22 UTC
Traditionally, SUSE Linux has *always* asked for the root password, not of the password of the current user. It has been like that since at least 1999 (probably earlier). This is what SUSE users are used to.

I know that Debian and Ubuntu handle this the exact other way round: They ask for the user's password. IMHO that makes sense since it enables the admin to grant specific permissions to individual users via /etc/sudoers.

In the SUSE configuration, you have to give such a user the root password which leads the whole idea of granting individual users finer-grained permissions ad absurdum; when a user knows the root password, he gets all root privileges anyway if he only logs in as "root" or uses "su".

I know that has been under discussion for a long time, but I don't know the current status; if there was a decision to migrate to the default "sudo" behaviour, i.e. what Debian / Ubuntu are doing. IMHO it would make sense, but it would also be a drastic change of behaviour for long-time SUSE users, probably locking many of them out from "sudo" because they might not get the news.
Comment 3 Stefan Hundhammer 2024-03-19 12:03:37 UTC
> % osc maintainer -e sudo
>.
> Defined in package: Base:System/sudo 
>   bugowner of sudo : 
>    otto.hollmann@suse.com
>. 
>   maintainer of sudo : 
>    otto.hollmann@suse.com
>. 
> Defined in project:  Base:System
>   bugowner of sudo : 
>    -
>. 
>   maintainer of sudo : 
>    dmueller@suse.com, meissner@suse.com, ro@suse.com, aj@suse.com, seife@novell.slipkontur.de, trenn@suse.com, werner@suse.com, daniel@molkentin.de, -
>. 
> Defined in project:  Base
>   bugowner of sudo : 
>    -
>. 
>   maintainer of sudo : 
>    adrian.schroeter@suse.com, jblunck@novell.com, rguenther@suse.com
Comment 4 Stefan Hundhammer 2024-03-19 12:06:48 UTC
And BTW 'kdesu' is completely independent of this.

> % osc maintainer -e kdesu
>.
>   bugowner of kdesu : 
>    fabian@ritter-vogt.de
>. 
>   maintainer of kdesu : 
>    lbeltrame@kde.org, wbauer1@a1.net, fabian@ritter-vogt.de, alarrosa@suse.com, christophe@krop.fr, -
> 
> Defined in project:  KDE
>   bugowner of kdesu : 
>    -
>. 
>   maintainer of kdesu : 
>    lbeltrame@kde.org, fabian@ritter-vogt.de, wbauer1@a1.net, christophe@krop.fr
Comment 5 Stefan Hundhammer 2024-03-19 12:18:06 UTC
(In reply to arctic summer from comment #0)
> These lines are in the sudoers file by default:
> 
> Defaults targetpw
> ALL    ALL=(ALL) ALL

You omitted the comments which would have explained it:

> 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'!
Comment 6 arctic summer 2024-03-20 10:38:13 UTC
Thanks for explaining. I did not expect this to be a default behaviour, so I filed it as a bug. Apologies. I recommend asking for sudo password by default. A message could be included within the installer, thus notifying longtime users of the change.
Comment 7 Stefan Hundhammer 2024-03-20 10:55:57 UTC
Over the years (or more likely decades) we learned the hard way that nobody bothers to read documentation anymore these days. That would be something for the release notes that you can view on every workflow step in the installer, but people just don't read that.

And in the case of a major change for something as fundamental as 'sudo', that would be a critical problem, and a lot of users would be furious.
Comment 8 Otto Hollmann 2024-03-20 14:15:51 UTC
It's still under discussion if there will be any changes (additional options) in installer. There is an idea to display a dialog during installation and ask user if he would like to use root password or sudo group and user password. But at the moment it's only idea.

If you would like to be asked for user password, you have to add your user to "sudo" group and install package "sudo-policy-sudo-auth-self". It will create config file /usr/etc/sudoers.d/50-sudo-auth-self
> Defaults:%sudo !targetpw
> %sudo ALL = (root) ALL

So users that are in group "sudo" will no longer be asked for root password but for their own password.

Also appropriate config files for polkit will be installed with this package.


Do you have any further question or can this bug be closed?
Comment 9 Stefan Hundhammer 2024-03-21 09:03:04 UTC
Forget that "during installation" part: The whole system must be deployable via an image, i.e. with zero user interaction. That rules out any crude hacks in the installer, regardless of YaST or Agama; there might not even be one.

IMHO this can be closed. I just wanted to hear your point of view.
Comment 10 arctic summer 2024-03-22 15:53:01 UTC
I think the Fedora installer has option to enable both root and sudo, mentioning that not setting up root will disable it. This is a good approach in my opinion. Not sure if they still have it in their installer though.
Anyways, I think you guys have made it clear, so yes, this "bug" can be considered resolved.
Comment 11 Otto Hollmann 2024-05-06 15:03:31 UTC
Thank you for confirmation, closing this bug.