#Entered with no password

1 messages · Page 1 of 1 (latest)

hidden barn
#

I downloaded the new Secure blue with Fed 43 but my laptop reboot continuously so I selected the old system image from the boot.

I think SSDM restored /var/lib/sddm/state/state.conf from 9th October for my user and brought me directly to the desktop without asking for password. PAM records show normal Pam_Unix authentication success, but kscreenlocker produced no logs and the display manager reused cached greeter/session state.
This allowed the desktop to appear unlocked immediately after the reboot.

From what I see, session state or greeter caches surviving a failed rollback, may allow session restoration without presenting the normal login to the user(I just selected my username and I was directly prompted to the desktop). Although PAM shows authentication, the greeter/session restoration bypassed the expected visible password prompt.

hidden barn
#

SSDM restored stale session after rollback, with passwordless login

hidden barn
#

In this second one you find a more extensive journalctl -b --no-pager, -1 and -2 plus ssdm.conf ssdm.conf.d

📎 log-2.txt
hidden barn
#

Here you can clearly see from the stat -c command that state.conf has been changed for the last time on the 9th of October.

I think it has been re used to restore my session without asking my password.

📎 log3.txt
#

So /var/lib/sddm/state/state.conf persist across rollbacks and SDDM used it to auto start last session of plasma.desktop with no password.

And auto login in not enabled.

hidden barn
#

Entered with no password

lament swan
#

are you able to consistently reproduce?

#

and does this only reproduce on kde?

hidden barn
#

I didn't try it again because I installed new updates (but I didn't reboot my laptop yet)

#

So basically I'm still in the session where I entered with no password but I downloaded new updates. If there is a way to run again the broken installation/delete the last updates I made, I can try to reproduce it because the situation should be the same of before.

lament swan
#

I still don't know what you mean by "still in the session"

#

rebooting kills existing sessions

hidden barn
#

Yes right, but re used a previous saved one from state.conf

#

I guess

lament swan
#

what is state.conf?

#

is this an sddm-specific concept?

hidden barn
#

Is a SSDM specific runtime state file where it is recorded the last successful logged in user, they session type.

lament swan
#

and you're sure this is relevant to the issue?

hidden barn
#

I think SSDM re used an outdated session info after the crashes I had

lament swan
#

how is it logging in?

#

your password is hashed

#

how is sddm logging in without pam?

#

this doesn't make much sense

hidden barn
#

SSDM went through PAM for the login but didn't wait me to write the password.

From the logs you see my greeter loaded and immediately the session started (and my password is long).

#

And the PAM was used to login

#

State.Conf is from 9 October proving it wasn't rewritten at login time so SDDM didn't do what it should normally do (write new session info).

In some ways the login logic was broken so not following greeter, password, PAM, session, write new state.

It took a short path assuming last session was already known and ready.

lament swan
hidden barn
#

The greeter/ssdm-helper supplied cached credential for example from kwallet or greeter cache. Or a PAM helper module supplied credentials like Pam_kwallet5.

In the logs is visible activity of Pam_kwallet5. I read that some PAM modules / wallet integrations can supply credentials back to the authentication floe if a previous session left an unlocking token or socket.

If keallet had a chaced/unlocked credential or an unlocked socket was present at startup this module maybe gave credentials to pam_unix to start the session resulting in lam_unix success.

#

What makes me feel there is something strongly wrong with Pam_kwallet5 is that it was activated before the login and not after as it should. So I think it interacted in the authentication phase.

#

And withing greeter start and authentication success there is just 0.2 sec. I can show you

lament swan
#

if you're able to consistently reproduce, can you check an upstream?

#

like fedora's kinoite?

hidden barn
#

Yes but I need your help @lament swan. To do this I was trying to boot a broken Secureblue version. I just updated my system so my question is very easy... How can I boot that version? And the actual one I'm using (still with fed 42?)

lament swan
#

To do this I was trying to boot a broken Secureblue version

what?

#

im confused

hidden barn
#

I think all this chaos with the logging is trigged by a broken installation as mentioned in the description of this problem.

lament swan
#

broken how?

hidden barn
#

If I want to reproduce exactly what I did I need to boot on that broken installation

#

It arrived to the login screen and then rebooted continuously

#

Automatically. As you can see from the logs it rebooted my system 4 times. At the fifth I decided to enter in my old version, here the password hasn't been typed and I got direct access to my desktop

lament swan
#

so you want to boot that version? it should still be there

#

you could pin your current version to be safe

hidden barn
#

Now I'm still in the same session but I ran a rpm ostree update. So if I reboot I will find a new version (maybe not broken anymore) and I can't reproduce the problem.

lament swan
#

that would mean it's been fixed

hidden barn
lament swan
#

i thought the broken one was on f43

#

im so confused

hidden barn
#

Broken f43

lament swan
hidden barn
#

Login skip 42

lament swan
#

i thought the skipped login was the broken part

#

there are two broken parts?

hidden barn
#

Where few hours ago I ran a ostree update

hidden barn
#

On the broken fed43 I never logged in, the system arrived to load everything until the login to then reboot continuously. So I started my old stable f42 where I arrived to the desktop without typing a password.

lament swan
#

i see...

hidden barn
#

So I would love to reboot my sys and reproduce this but I ran a rpm ostree update so idk how to start the broken f43 and then log in this fed 42.

#

Because grub will show me the updated f43 and the broken f43 and will not show the f42 where I skipped the login.

#

@lament swan If you help me to solve this I can reproduce the same behaviour.

lament swan
#

ngl i don't understand what's going on well enough here

hidden barn
#

1)I ran the broken f43. It didn't work so:
2) from grub I selected the old image f42
3) in my f42 session where I entered with no password I ran rpm-ostree update.

This means that if I reboot my sys on grub I'll see the last 2 images

  1. new f43
  2. broken f43

But to reproduce the problem I should run the broken f43 and then log in my f42.

The problem? No idea how to log in my f42 because not present on grub.

lament swan
#

if you want to rebase back to a specific f42 version, you can use the date tags

hidden barn
#

Well I would like to see if it happens again trying exactly the same (running broken f43 to then log in f42)

Maybe this doesn't happen with the new f43 because I think it won't be broken anymore.

lament swan
#

like 20251010

hidden barn
#

Doesn't happen anymore and also the new fed43 image is broken with a kernel panic fatal exception.

#

But from the log I attached here is clear that something bad happened and the login was skipped. I can't type my password in 0.2 sec

lament swan
#

these are unrelated issues i suspect

hidden barn
#

Yes fixed. Thsnks to the supportive community.

I posted all the logs of this conversation on the silverblue github.
It's so evident that something very bad happened during my login.

#

Also worried of reading messages as this

"I don't know if this is related but I'll mention it: When I wake up my device from the automatic suspended state and login with the password, sometimes it will suspend again after a couple of seconds after login. When I wake it again, it logs in directly without a password or even choosing a user. This started happening with F43."

lament swan
#

what was the issue

#

from silverblue's github

hidden barn
lament swan
#

i guess you meant here?

#

but then what was the fix?

hidden barn
#

Thank to the community I fixed the broken image removing the instable kargs.

But the skipped access is still not resolved. There are my logs and some ideas I had but I'm not expert enough to understand why the password to write manually was skipped and what triggered this behaviour.

hidden barn
lament swan
hidden barn
#

@lament swan

Screenshot_20251113-190240.png
lament swan
hidden barn
#

Will someone take a look of this to see if there is something interesting that can be found?

I tried to post some findings and ideas + as many logs as possible

It's not normal at all to skip the password to login...

pastel radish
#

No one will be able to investigate this issue if it cannot be reproduced

hidden barn
#

Maybe logs show what happened.

I'm just a person with no tech knowledge.

Is like thieves that steal in your house and I have some cameras but I don't know how to use them really well + maybe they don't record the thieves directly in their faces.

But even if it doesn't happen again.. At least there is something (and from the logs you will see there are more things that are not normal)

pastel radish
#

Logs are not enough, in any project (closed- or open-source), maintainers will ask for steps to reproduce the issue at the opening of the ticket

#

There is already so much work, it would be too time-consuming if maintainers had to check every single issues based solely on users assumptions