Bug 1182531 - kdesu doesn't accept root PW
Summary: kdesu doesn't accept root PW
Status: IN_PROGRESS
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma) (show other bugs)
Version: Current
Hardware: 64bit openSUSE Tumbleweed
: P5 - None : Normal with 5 votes (vote)
Target Milestone: ---
Assignee: E-Mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-21 10:25 UTC by Edgar Aichinger
Modified: 2022-01-31 12:35 UTC (History)
4 users (show)

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


Attachments
Kdesu error dialog (81.30 KB, image/png)
2021-02-21 10:25 UTC, Edgar Aichinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Edgar Aichinger 2021-02-21 10:25:36 UTC
Created attachment 846348 [details]
Kdesu error dialog

Since upgrading my laptop running KDE Plasma desktop to Tumbleweed snapshot 20210215 I cannot start Yast2 from the application menu or .desktop icon anymore.

Kdesu asks for the root password, but constantly refuses to accept it, see screenshot of error dialog.

Trying and running su from konsole prints four lines of messages, which it didn't before updating to this snapshot:

kwalletd5: Checking for pam module
kwalletd5: Got pam-login param
kwalletd5: Waiting for hash on 4-
kwalletd5: waitingForEnvironment on: 5

After that the root prompt appears and I can run Yast2 just fine from there.

I admit I'm using a lot of community and 3rd party home repos from OBS, but I believe all the packages that seem to be involved in this bug come from the main TW snapshot repo...
Comment 1 Fabian Vogt 2021-02-21 12:03:17 UTC
This is caused by pam_kwallet. It runs also within "su" and "sudo" and starts "kwalletd", which pollutes stdout. It's possible to remove the printf statements from kwalletd, which would make kdesu work again, but in those cases pam_kwalletd shouldn't run anyway.

Previously it worked by accident because of a bug in pam_kwallet: It closes all FDs and after that calls "syslog", which didn't know that the FD it stored was closed meanwhile. syslog is smart enough to reopen the FD if it was closed, but in some cases the FD was reused by pam_kwallet and so syslog actually tried to write to the kwallet socket. That caused pam_kwallet to error out when called from sudo/su earlier. It seems like on recent Tumbleweed the FD allocation is more lucky and this error condition doesn't trigger.

As workaround, remove pam_kwallet.

To fix this properly, the bug in pam_kwallet with its use of syslog has to be fixed (by either dropping syslog or using closelog) and pam_kwallet must not run when called by sudo/su.
Comment 2 Jon Brightwell 2021-05-28 14:40:43 UTC
Hi, I've seen this come up a couple of times just lately with community support and I've spotted it going back several years!
Fabian, is this ticket related to the work you're currently doing on kwallet-pam https://github.com/KDE/kwallet-pam/compare/work/fvogt/only_if ?
Comment 3 Fabian Vogt 2021-06-14 20:44:48 UTC
(In reply to Jon Brightwell from comment #2)
> Hi, I've seen this come up a couple of times just lately with community
> support and I've spotted it going back several years!
> Fabian, is this ticket related to the work you're currently doing on
> kwallet-pam https://github.com/KDE/kwallet-pam/compare/work/fvogt/only_if ?

Yep. By specifying only_if=sddm,xdm,gdm,... in the common-auth config, pam_kwallet won't run outside of the display manager and the polluted output wouldn't break kdesu etc. anymore.

However, meanwhile I think that just avoiding the pollution by using qDebug instead (or even just writing to stderr) is simpler and should be done anyway. It's not quite a complete fix, because kwalletd will also still spawn when unnecessary, but that might not be that bad (might become a zombie though?).

The FD issue has to be fixed in any case.
Comment 4 Fabian Vogt 2021-06-16 20:42:35 UTC
What I forgot to mention: This issue should only happen if pam_kwallet does not work correctly, i.e. didn't unlock the wallet on login. If it does, then the PAM_KWALLET5_LOGIN variable is set and pam_kwallet exits early.

(In reply to Fabian Vogt from comment #3)
> (In reply to Jon Brightwell from comment #2)
> > Hi, I've seen this come up a couple of times just lately with community
> > support and I've spotted it going back several years!
> > Fabian, is this ticket related to the work you're currently doing on
> > kwallet-pam https://github.com/KDE/kwallet-pam/compare/work/fvogt/only_if ?
> 
> Yep. By specifying only_if=sddm,xdm,gdm,... in the common-auth config,
> pam_kwallet won't run outside of the display manager and the polluted output
> wouldn't break kdesu etc. anymore.
>
> However, meanwhile I think that just avoiding the pollution by using qDebug
> instead (or even just writing to stderr) is simpler and should be done
> anyway.

MR: https://invent.kde.org/frameworks/kwallet/-/merge_requests/17

> It's not quite a complete fix, because kwalletd will also still
> spawn when unnecessary, but that might not be that bad (might become a
> zombie though?).

Stale processes, rather, and I do indeed see those.

> The FD issue has to be fixed in any case.

That was actually fixed meanwhile, it sets FD_CLOEXEC instead now (which is IMO also wrong, but shouldn't cause any immediate issues...).

I did some other cleanup: https://invent.kde.org/plasma/kwallet-pam/-/merge_requests/5