Unexpected failure in realpath: 13 (Permission denied)

[jas4711]

Hi

I'm trying to set up gssproxy for Apache and it works fine in a normal environment, but when I run it in a podman container I get an error. It is not yet clear to me if this is the real source of my problems, or just a random error message, but it seemed worth reporting anyway.

gssproxy[5215]: Unexpected failure in realpath: 13 (Permission denied)

Indeed there is a permission issue:

root@3e205a109ea6:~# ps auxww|grep apac
root        5088  0.0  0.1  12668  6720 ?        Ss   10:23   0:00 /usr/sbin/apache2 -k start
www-data    5154  0.0  0.1 1938280 6664 ?        Sl   10:23   0:00 /usr/sbin/apache2 -k start
www-data    5155  0.0  0.1 2003816 10268 ?       Sl   10:23   0:00 /usr/sbin/apache2 -k start
root        5246  0.0  0.0   3180   712 pts/0    S+   10:28   0:00 grep apac
root@3e205a109ea6:~# ls -la /proc/5088/exe
lrwxrwxrwx 1 root root 0 Sep 14 10:28 /proc/5088/exe -> /usr/sbin/apache2
root@3e205a109ea6:~# ls -la /proc/5154/exe
ls: cannot read symbolic link '/proc/5154/exe': Permission denied
lrwxrwxrwx 1 root root 0 Sep 14 10:28 /proc/5154/exe
root@3e205a109ea6:~# 

[jas4711]

I found a solution that silence the error. Isn't there a way to get the process name of a process without these permissions?

podman run --cap-add=SYS_PTRACE

Still not exactly clear why I don't get a final success in a container... I'm debugging more.

[simo5]

Note that generally the idea is to run the gssproxy in the host, and bind mount its socket in a container. This way container processes do not have direct access to keytabs/credentials, gssproxy does it for them.

I am also not sure this is an actual gssproxy issue, unless it is an RFE to make disableable the feature that reads the calling process name.

[jas4711]

I managed to track the problem down a bit more. Apache talks to gssproxy once as root and then as www-data in a container, but only as www-data on real systems. Thus I need two stanzas 'euid=root' and 'euid=www-data'. The script is below, run it in a container and remove one of the stanzas to see error messages about non-matching euid. Any ideas what is happening?

podman run --cap-add=SYS_PTRACE --rm -it debian:bullseye bash

https://salsa.debian.org/jas/gssproxy/-/blob/master/debian/tests/gssproxy-apache

Anyway, I'm closing this since I don't think it is a gssproxy issue. Sorry for the noise.

[simo5]

Sorry not having used debian for many years now I do not know if that distribution makes any assumption on how to run apache. At a glance I see nothing out of the ordinary.