3

Instead of logging me in, PAM greets me with the message "Cannot make/remove an entry for the specified session" after I enter the password. What entry is it talking about (and what session)?

The string with the error message is found in libpam.so.0(.83.1).

My system is based on binaries from Fedora release 20 (Heisenburg).

How can I troubleshoot PAM to figure out what is needed to successfully login? I have no syslog (and no persistent disk, only an initramfs).

Updates:

SELinux is Disabled.

I am more than willing to replace the entire PAM config with something simple that allows login (normal user and root) on the virtual consoles only.

Source code from Linux-PAM-1.1.8, libpam/pam_strerror.c reveals that the message comes from the error code PAM_SESSION_ERR, which can be caused by all sorts of internal problems, such as memory allocation error or failure to locate the users home directory. So much for trying to interpret the error message. :-(


Below are my config files based on the comment indicating /etc/pam.d/login as a starting point:

(I have also tried removing all lines containing pam_loginuid.so without any noticeable difference)


/etc/pam.d/login:

 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth substack system-auth auth include postlogin account required pam_nologin.so account include system-auth password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session required pam_namespace.so session optional pam_keyinit.so force revoke session include system-auth session include postlogin -session optional pam_ck_connector.so 

/etc/pam.d/postlogin:

 session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed 

/etc/pam.d/system-auth:

 auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so 

I have these shared PAM-related libraries:

 libpam_misc.so.0 libpam.so.0 pam_access.so pam_console.so pam_deny.so pam_env.so pam_fprintd.so pam_gnome_keyring.so pam_keyinit.so pam_lastlog.so pam_limits.so pam_localuser.so pam_loginuid.so pam_namespace.so pam_nologin.so pam_permit.so pam_pkcs11.so pam_pwquality.so pam_rootok.so pam_securetty.so pam_selinux_permit.so pam_selinux.so pam_sepermit.so pam_succeed_if.so pam_systemd.so pam_timestamp.so pam_unix_acct.so pam_unix_auth.so pam_unix.so pam_xauth.so 

as well as these that are referenced by the above shared libraries (according to ldd):

 libattr.so.1 libaudit.so.1 libcap.so.2 libcrack.so.2 libcrypt.so.1 libc.so.6 libdbus-1.so.3 libdbus-glib-1.so.2 libdl.so.2 libffi.so.6 libfreebl3.so libgcc_s.so.1 libgio-2.0.so.0 libglib-2.0.so.0 libgmodule-2.0.so.0 libgobject-2.0.so.0 liblzma.so.5 libnsl.so.1 libnspr4.so libnss3.so libnssutil3.so libpcre.so.1 libpcre.so.3 libplc4.so libplds4.so libpthread.so.0 libpwquality.so.1 libresolv.so.2 librt.so.1 libselinux.so.1 libsmime3.so libssl3.so libutil.so.1 libz.so.1 
4
  • if you can't login as root you probably are in trouble. Where did you get the files in /etc/pam.d from? Commented Aug 25, 2014 at 15:52
  • 1
    @MattBianco seems similar to a bug reported a, long, while back. From the link, you should be able to use recovery disk and login as root. Once that's done, would you mind posting the content of /etc/pam.d/login? I can post mine, but it'll be better formatted in an answer box rather then comment; either way you prefer though. Commented Aug 25, 2014 at 15:54
  • The session it is talking about is the login session. The entry is some data it is trying to write to disk (or tmpfs) to help it keep track of this session. Look like the volume is mounted readonly, another permissions error, or missing directory, etc. Commented Aug 25, 2014 at 16:43
  • do you found solution? Commented Oct 16, 2015 at 8:48

3 Answers 3

2

In my case, I'm on Centos 6, and found this in /var/log/secure:

Mar 13 10:13:02 server sudo(pam_google_authenticator)[24911]: Unrecognized option "user=root" Mar 13 10:13:02 server sudo: ralph : pam_authenticate: Cannot make/remove an entry for the specified session ; TTY=pts/2 ; PWD=/home/ralph ; USER=root ; COMMAND=/usr/local/bin/become root 

Ultimately, it was the GA PAM module barfing which PAM then doesn't know what to do with, so errors out. I'm sure numerous other problems with different PAM modules can cause the same behaviour (not just Google Authenticator). Some sort of log is probably the only way to find out what's going on though.

2

It probably means an issue with a pam.d file - or with something that needs to be accessed by pam.

One debugging technique is to sprinkle pam_echo statements throughout your pam files:

e.g.

auth [default=ignore] pam_echo.so "sshd: calling faillock" auth requisite pam_faillock.so preauth even_deny_root auth [default=ignore] pam_echo.so "sshd: faillock did not fail" auth [default=ignore] pam_echo.so "calling password-auth substack" auth substack password-auth auth [default=ignore] pam_echo.so "back from password-auth substack" auth [default=ignore] pam_echo.so "calling postlogin" auth include postlogin auth [default=ignore] pam_echo.so "back from postlogin" 

Be careful when adding pam_echo - do not to put it after lines that can 'skip' following lines, or if you must, update the number of lines to be skipped.

Reminder: always stay logged in as root while making changes to pam files - changes take effect immediately, and any mistake can leave you unable to login or sudo...

1

I resolved this issue on my own system by using the tool audit2allow. Check my post.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.