5

While trying to mitigate some spammy PAM messages in /var/log/auth.log, following this post, I tried various combinations in /etc/pam.d/sudo. Unfortunately, the last line I tried, completely locked me out of any sudo/su operations.

session [success=1 default=ignore] pam_succeed_if.so quiet_success user = root uid = 0 ruser = pi

The error I get on CLI is:

$ sudo nano sudo
sudo: pam_open_session: Permission denied
sudo: policy plugin failed session initialization

with the corresponding /var/log/auth.log message:

May 11 14:56:29 sudo:       pi : TTY=pts/0 ; PWD=/etc/pam.d ; USER=root ; COMMAND=/bin/nano sudo
May 11 14:56:29 sudo: pam_unix(sudo:session): session opened for user root by pi(uid=0)
May 11 14:56:29 sudo: PAM bad jump in stack
May 11 14:56:29 sudo:       pi : pam_open_session: Permission denied ; TTY=pts/0 ; PWD=/etc/pam.d ; USER=root ; COMMAND=/bin/nano sudo

Obviously I cannot edit the file back, by using sudo to edit the file.

How can I edit back the file and get out of this horrible situation?

(This is on the latest Debian Stretch on a Raspberry Pi 3B.)

not2qubit
  • 2,651
  • 4
  • 34
  • 45

3 Answers3

4

Thanks to Linux systems, this was exceptionally easy.

Just fire up any linux distro, in my case a Kali VM. Pop the SD card into a USB reader and plug it in. The 2 Rasbian SD partitions: boot and rootfs are automatically recognized. Then cd into /media/<blahblah>/rootfs/etc/pam.d/ and sudo edit the file. Unmount and put it back in your Pi.

And if this didn't teach you to be careful when messing around with PAM, at least it thought you to backup your SD card or partitions, because on an encrypted FS, this probably wouldn't have worked!

not2qubit
  • 2,651
  • 4
  • 34
  • 45
1

If you can login as a user with permission to edit the /etc/pam.d/sudo (maybe an admin or root account) then just do that.

Otherwise, you might have to edit the file using another OS/system. Raspberry Pi's still have their system partition's on SD cards right? So you could shutdown the Raspberry and use another computer to read the SD card and edit the file. Or if your Raspberry will boot another OS from a live USB.

There might be a recovery boot option (like single) that could give you a root login...

Xen2050
  • 14,391
1

I ran into this under different circumstances, but I hope this might be helpful. I think this may explain why your PAM config broke in the first place.

The setting success=1 (or any number to the right side of the equals) indicates how many lines to skip if the authentication with that module is successful. If it skips X number of lines and hits something invalid on the first unskipped line it processes thereafter or has no further lines to process, it will throw that bad jump in stack error message.

I had an unusual/unexplained instance of a line that had been erroneously added at the end of my PAM common-password config file in Ubuntu 20.04 LTS where it read:

password      [success=1 default=ignore]   pam_unix.so   obscure   sha512  shadow remember=5 

It was actually redundant in my case with another pam_unix.so line further up. The line by itself was not malformed (and the authentication was successfully being met), but it was rather misplaced (and redundant).

Given that it occurred immediately before the end of the file and it said "success=1", when it was successful with a good password it tried to then (further) skip a line that was not there since it was already at the EOF. Hence it threw the "bad jump in stack" message. You can't jump ahead (skip) one line if you are at the end of file.

In your case you (unfortunately) introduced the error into the /etc/pam.d/sudo file which of course created an impossible to resolve situation when you invoked sudo to edit the /etc/pam.d/sudo file (with sudo nano sudo), because the sudo command itself was failing to authenticate because of the issue in that very file.

In my own case, deleting the offending line resolved the issue.

Bottom line: Look at the ordering of the entries in your PAM config files to make sure you aren't placing any 'success' statements on a final line or (if close enough to the bottom, but not the final line) making success=X skip X number of lines ahead where it would encounter the EOF.