Login with wrong password possible! "Authentication via PAM had errors setting up the authentication session. The error code was 11"
Closed, InvalidPublic


using standard lock screen i get the following error dialog from /src/modules/lokker/lokker.c from _lokker_cb_exit. logging in seems to work fine, however it works with a wrong password. logging in with the correct password works immidiatly, with a random "password" it takes a couple of seconds and then unlocks the screen. i can't find anything related in journalctl.

it states it's PAM error 11, and PAM error 11 is: Cannot access authentication database because credentials supplied are insufficient. <- from that i don't think that it is a configuration issue, but an issue with e.

also: i get that unlocking the screen would in this scenario not possible anymore, but is it really a good idea to just unlock e? without looking at the source, i would have never tried a random "password" and found out it worked. from what i gather, there is also the error 22 which is [PAM_AUTHTOK_LOCK_BUSY] [The authentication token lock is busy. which could mean if i have access to another normal user account on the same machine, i only have to open enough PAM connections for a user to try to get PAM to be currently locked to "authenticate" with e. with occupying enough ram, this might also be possible. see also 3fdcc92ab0

i'm on opensuse, with

Information for package systemd:
Repository     : repo-oss
Name           : systemd
Version        : 234-5.1
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 10.0 MiB
Installed      : Yes
Status         : out-of-date (version 234-3.1 installed)

PAM was also not up-to-date (forgot to paste), but i'll upgrade my system and see if it's still an issue.

564 static Eina_Bool
565 _lokker_cb_exit(void *data EINA_UNUSED, int type EINA_UNUSED, void *event)
566 {
567    Ecore_Exe_Event_Del *ev = event;
569    if (ev->pid != _auth_child_pid) return ECORE_CALLBACK_PASS_ON;
571    _auth_child_pid = -1;
572    /* ok */
573    if (ev->exited && (ev->exit_code == 0))
574      {
575         /* security - null out passwd string once we are done with it */
576         _lokker_null();
577         e_desklock_hide();
578      }
579    /* error */
580    else if ((!ev->exited) || (ev->exit_code < 128))
581      {
582         /* security - null out passwd string once we are done with it */
583         _lokker_null();
584         e_desklock_hide();
585         e_util_dialog_show(_("Authentication System Error"),
586                            _("Authentication via PAM had errors setting up the<ps/>"
587                              "authentication session. The error code was <hilight>%i</hilight>.<ps/>"
588                              "This is bad and should not be happening. Please report this bug.")
589                            , ev->exited ? ev->exit_code : ev->exit_signal);
590      }
591    /* failed auth */
592    else
593      {
594         _lokker_state_set(LOKKER_STATE_INVALID);
595         /* security - null out passwd string once we are done with it */
596         _lokker_null();
597      }
598    E_FREE_FUNC(_auth_child_exit_handler, ecore_event_handler_del);
600 }

logging - i'm sorry, i've got a fever. i meant log in and or authenticate...

zmike added a subscriber: raster.Oct 16 2017, 7:37 AM
raster added a subscriber: simotek.Oct 17 2017, 9:40 PM

I don't see pam errors here. wrong passowrd == no unlock. this is on arch. credentials here may be a security mechanism in suse (selinux?) to stop userspace apps in general from checking on passwords (authing). normally what happens is the pam module executed a setuid root helper that then actually reads the crypted pw from /etc/shadow and then auths. it may be disallowing this (and arch is allowing it). @simotek ? is this the case? this is what it appears to me it might be.

"also: i get that unlocking the screen would in this scenario not possible anymore, but is it really a good idea to just unlock e?" ... also covering pam auth lock being busy... i guess the policy is in the case of system level errors to be lenient and allow you to log in - better than to have a system that is locked down and unable to be logged into at all and stuck. not sure you can just "open pam connections" as it's not a daemon. this error would basically never happen i think UNLESS it cant spawn child processes and then something is deeply wrong with the machine (so many processes it cant run more) ... and in this case things are an emergency... unlocking is the policy atm here. is it better to lock the system down and then you never be able to unlock again to fix the issue? not sure that's any better... the system just should never be able to get to this state at all.

bu5hm4n added a subscriber: bu5hm4n.EditedNov 5 2017, 1:52 AM

@raster - is it possible that we simply miss a 'pam_setcred' before the authenticate ?

<edit> Never mind ... :)

netstar added a subscriber: netstar.Nov 5 2017, 9:14 AM

This is only an issue for me with Arch, not Debian. if that helps at all.

raster added a comment.Nov 5 2017, 3:43 PM

i run arch... and it authenticates correctly (wrong password does not auth). ... what is different?

Any updates here?

i suspect it's a gl driver atexit() failing and segving altering the exit code. this is one of those reasons why i think quicklaunch is a dead end as trying to do things like have your display initted (and thus evas engines initted thus gl drivers possibly set up) is going to result in un-fun corner cases.

the solution here IMHO is to not fork() but to actually ecore_exe the auth helper that only uses pam and nothing else. there is code in e_auth for this already for bsd i think... but it doesn't use pam in this path. just having an auth process to quickly launch etc. would do the job. just needs to be done. but this is based on the above suspicion as i have seen this before.

Does this still happen?

if the forked auth child process somehow segfaults on exit ... yes - it can happen. there is ifdef code for bsd that uses a separate EXECUTED binary (not fork, but for + exe, or ecore_exe) which should solve the problem if that binary also supported pam. it just requires time to sit down and do this.

as such the exit is due to a segv in atexit handlers in drivers from memory of this ticket.. so this is the root case, the result being log-in allowed irrespective of auth creds.

raster closed this task as Resolved.Feb 26 2018, 2:08 AM

Hello, I've upgraded today (on Ubuntu) to 0.22.2-0xenial0 and it appears my password isn't accepted on the lock screen (even if it works just fine when initially starting E session).
I was wondering if this might be related to this Merge Request?

raster changed the task status from Resolved to Invalid.Mar 22 2018, 9:16 AM

See T6779 - dup probably

@raster indeed, this is what I've been looking for. Many thanks!