xrdp-sesman ignores changes to pam configuration until full restart

[dhoffend]

Version: xrdp 0.9.8-2~bpo9+1 (debian backports)

When you install xrdp with localusers only and later install/configure/integrate sssd (for example) for remote users or make any other change to the pam configuration xrdp-sesman completely ignores it. If xrdp-sesman would rediscover it's active sessions (like proposed in #819), it would be an issue and you could simple restart it, but now we've to restart xrdp-sesman (or better reboot the server) to make aware of the pam changes.

Is it possible to reread the pam configuration on HUP signal?

[matt335672]

I've just had a look at this, and I'm unable to reproduce the problem as described on Ubuntu 22.04 LTS with xrdp v0.9.8.

I started xrdp-sesman and looked at the files it's reading from the PAM directory:-

sudo strace -p 35567 -e trace=openat 2>&1 | grep pam.d

I get this on an initial login:-

openat(AT_FDCWD, "/etc/pam.d/xrdp-sesman", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/other", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10

On a reconnect, I get very similar:-

openat(AT_FDCWD, "/etc/pam.d/xrdp-sesman", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/other", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10

And after logging out and in again, I get this:-

openat(AT_FDCWD, "/etc/pam.d/xrdp-sesman", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/other", O_RDONLY) = 9
openat(AT_FDCWD, "/etc/pam.d/common-auth", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-account", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-password", O_RDONLY) = 10
openat(AT_FDCWD, "/etc/pam.d/common-session", O_RDONLY) = 10

So it looks to me like the PAM stack is being scanned with this software version whenever a user is logged in. This is what I'd expect looking at the code, as we call pam_start() for each login attempt.

SIGHUP reloading is now supported, as @danielperna84 points out above.

I'm closing this as "can't reproduce". @dhoffend - please feel free to re-open this if it's still an issue for you.

[danielperna84]

The reason why I have stumbled upon this in the first place:

I'm using a custom PAM made with pam-python. Here the problem is, that pam_python.so does not get reloaded, thus retaining cached data that is only loaded once during the first load. Or at least it appears to me like that's the problem.

Of course during runtime it makes sense to not reload the PAM itself for efficiency. But it might be reasonable to do on a sesman-reload when considering dynamic modules like the Python implementation mentioned above.

[matt335672]

I don't think that particular use-case won't be possible for a while.

pam_end() will call dlclose() for the modules loaded by pam_start(). If nothing else has loaded them, they will be unloaded. The current sesman design however may have multiple pam sessions active for multiple users simultaneously, so this will only happen when the last user logs out. The current implementation won't even do this as pam_start() and pam_end() are called by two different processes.

A full implementation of #1961, which is some way away, will move all PAM invocations into forked processes, so this won't happen.

As regards your own issue, what cached data is causing a problem exactly? Can the loading of this data be made dependent on the session being started and finished for example?

[danielperna84]

Thanks for the explanation. Makes sense.

As for my issue: we have xrdp running on a proprietary Linux Flavor, which has proper Multi-Level Security support within X-Windows. For this to work, policies map Compartments to LDAP groups. Depending on which compartments a user has assigned he will be granted or denied access (the X session itself will be constrained to the assigned compartments). Therefore we are doing this early in PAM to prevent unauthorized access.

The (minor) problem we have is, that once xrdp has started, the PAM can't see newly added compartments. It's doing that via C-bindings in Python. But once the module has been loaded, the set of available compartments remains static. Which in some way actually is a limitation of the C-binding, not PAM. To work around this we have to restart xrdp. Only a minor inconvenience. But I had hoped the HUP against sesman could have solved this, and thereby allowing to add compartments while xrdp has active sessions.

[matt335672]

I think I see. The module is loading the LDAP groups when it is loaded rather then during PAM authorization.

The change I'm currently working on will probably make this work, but only if one user is logged in to the machine. Other than that, I think you may need to make changes to the way the Python works, or wait for #1961.

[danielperna84]

Correct. And refactoring (my code) would make sense anyways. IIRC the current implementation has trouble with concurrent logins / PAM invocations. Hence performing operations which could take longer shouldn't be done in PAM to not block other users from logging in (like if there's an LDAP timeout for some reason).

In any case, thanks for your feedback. 👍 Looking forward to #1961

[hulaneoTi]

To workaround this i make an bash to to verify if there's a new user on Keycloak (is what we use for create users) and if there's a new user is needed to verify if there's an logged user, when no one is logged it's just simply restart the xrdp service.