[SOLVED] OpenRC: /bin/sh: bad interpreter: Permission denied

[autofyrsto]

I was messing around with the authentications on a hobby server, and I removed PAM after viewing this thread on the topic. [Edited to add hyperlink.] I did this by adding "-pam" to make.conf and running an @world update. Upon reboot, I could not log in at the prompt , but I was able to chroot into the system. I tried some things that I neglected in the thread, like running revdep-rebuild and re-emerging sys-apps/shadow and sys-process/audit. Still no luck at the log-in prompt. I then replaced the "pam" use flag and updated @world to re-install PAM and dependencies. Still no luck logging in. After all of my experiments, the situation is that OpenRC runs into a permission problem early in the boot process.

The error message is as follows:

Code: Select all

 OpenRC 0.42.1 is starting up Gentoo Linux (i686)

* /proc is already mounted
* /run/openrc: creating directory
* /run/lock: creating directory
* /run/lock: correcting owner
* Caching service dependencies ...
sh: /lib/rc/sh/gendepends.sh: /bin/sh: bad interpreter: Permission denied [ok]
INIT: Entering runlevel: 3

The machine then moves quickly to a non-functional log-in screen. Before I wipe the system and start over, I would like to know if there is a way to restore the boot process so I can log in again, with or without PAM. Thanks in advance for any advice.

[eccerr0r]

I have to go facepalm whenever I hear someone building for a desktop machine that removes pam. *sigh*

For the gendepends problem, usually bad interpreter means the script had a problem with the interpreter. What does

Code: Select all

$ ls -ld /bin/sh /bin/bash

return?

The for your login problem I don't know if you ran into the pam upgrade issue people have been having lately...

[autofyrsto]

Thanks, eccerr0r. I appreciate your expertise. I'll read through the PAM upgrade issue tonight. In the meantime, here is the return of the ls command:

Code: Select all

# ls -ld /bin/sh /bin/bash
-rwxr-xr-x. 1 root root 880604 Aug 29 17:12 /bin/bash
lrwxrwxrwx. 1 root root      4 Aug 29 17:12 /bin/sh -> bash

[Hu]

That looks reasonable. What about ls -ld / /bin /lib*?

[Buffoon]

CRLF line terminators can cause this kind of error, what does 'file /lib/rc/sh/gendepends.sh' tell? Just my 2¢.

[eccerr0r]

Bad file EOL delimiters tend to give the even more perplexing "file not found" error instead of a permission error.

Currently I also wonder about extended attributes on your filesystem as well as whether a hardened or grsec kernel versus plain/gentoo-sources kernel is being used but I have no experience in any of those.

[GDH-gentoo]

Code: Select all

# ls -ld /bin/sh /bin/bash
-rwxr-xr-x. 1 root root 880604 Aug 29 17:12 /bin/bash
lrwxrwxrwx. 1 root root      4 Aug 29 17:12 /bin/sh -> bash

Easy to miss, but there is a period after the file mode bits:

Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. [...]
GNU ‘ls’ uses a ‘.’ character to indicate a file with a security context, but no other alternate access method.

Are you using a hardened profile or something like that?

[autofyrsto]

Here are the outputs:

Code: Select all

# ls -ld / /bin /lib*
drwxr-xr-x. 20 root root 4096 Jul 14 20:14 /
drwxr-xr-x.  2 root root 4096 Jan  1 22:32 /bin
drwxr-xr-x. 13 root root 4096 Jan  1 20:49 /lib

Code: Select all

# file /lib/rc/sh/gendepends.sh
/lib/rc/sh/gendepends.sh: POSIX shell script, ASCII text executable

The kernel is sys-kernel/gentoo-sources-5.4.80-r1.
The profile is [4] default/linux/x86/17.0/hardened/selinux (stable).
I was running SELinux on the machine.

I don't have knowledge about extended attributes on the filesystem, other than to report that the packages libarchive, rsync, shadow, and patch all have the "xattr" use flag enabled.

[Hu]

If you are using SELinux, and you encounter a permission problem that cannot be explained by file modes, you should suspect SELinux. Also, you should mention in the opening post that SELinux is in use. If you temporarily switch SELinux to permissive mode, does the problem go away? If yes, you need to find why your SELinux configuration is blocking this access.

[autofyrsto]

Hi all. Thanks for suggesting SELinux. I didn't consider that because I didn't mess with it specifically before the breakage occurred, but re-installing PAM and re-labeling the system got me the result I was after:

Code: Select all

# rlpkg -a -r

I am now logged back in and hopefully a little wiser. I can mark as solved. Best regards!