No user session created with xrdp and pam_systemd_home account module

[usul0184]

Thanks for a great program! Newbie here, apologies for any inaccuracies. A recent change to the PAM configuration files in Arch repositories seems to be causing problems with xrdp. The current version of /etc/pam.d/system-auth contains the following account section:

-account   [success=1 default=ignore]  pam_systemd_home.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

The first line, -account [success=1 default=ignore] pam_systemd_home.so, results in no user session being created in xrdp. The output of loginctl session-status is Could not get properties: Unknown object '/org/freedesktop/login1/session/auto'. This causes problems like being unable to start a polkit authentication agent.

For debug purposes, I’ve changed the malfunctioning pam_systemd_home.so line to account [default=ignore] pam_systemd_home.so debug. journalctl shows the following in what I think relevant part when connecting to xrdp:

Sep 08 18:13:45 bigone xrdp-sesman[642]: pam_systemd_home(xrdp-sesman:account): pam-systemd-homed account management
Sep 08 18:13:45 bigone dbus-daemon[618]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.1543' (uid=0 pid=642 comm="/usr/bin/xrdp-sesman --nodaemon ")
Sep 08 18:13:45 bigone dbus-daemon[618]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Sep 08 18:13:45 bigone xrdp-sesman[642]: pam_systemd_home(xrdp-sesman:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Sep 08 18:13:45 bigone xrdp-sesman[642]: (642)(140313509857088)[INFO ] ++ created session (access granted): username esyu, ip 192.168.84.210:64145 - socket: 12
Sep 08 18:13:45 bigone xrdp-sesman[642]: (642)(140313509857088)[INFO ] starting Xvnc session...
Sep 08 18:13:45 bigone xrdp-sesman[642]: (642)(140313509857088)[DEBUG] Closed socket 38 (AF_INET 0.0.0.0:5910)
Sep 08 18:13:45 bigone xrdp-sesman[23600]: (23600)(140313509857088)[INFO ] calling auth_start_session from pid 23600
Sep 08 18:13:45 bigone xrdp[645]: (645)(140514163267136)[INFO ] xrdp_wm_log_msg: login successful for display 10
Sep 08 18:13:45 bigone xrdp-sesman[23600]: pam_systemd(xrdp-sesman:session): Failed to create session: No child processes
Sep 08 18:13:47 bigone xrdp-sesman[23731]: Failed to connect to session manager: Failed to connect to the session manager: Could not open network socket
Sep 08 18:13:52 bigone xrdp-sesman[23731]: xfsettingsd: No window manager registered on screen 0.
Sep 08 18:13:52 bigone xfsettingsd[23731]: Failed to get the _NET_NUMBER_OF_DESKTOPS property.

If the pam_systemd_home.so line is removed, everything works fine. Note that I do not have systemd-homed running. Xorg vs Xvnc makes no difference, nor does having a startwm.sh with just exec xterm in it.

Not sure if this is an xrdp problem or something else; for what it’s worth, local login and ssh work fine.

Additional info:

• OS and version: Manjaro 18.0 XFCE Edition
• xrdp version: 0.9.14
• xorgxrdp version: 0.2.14
• Client OS / Client software: Windows 10 Remote Desktop Connection
• Desktop: Xfce (but likely irrelevant; even xterm fails)
• Backend: Both Xorg and Xvnc

[matt335672]

Well, from what little research I've done on this, it seems that pam_systemd_home.so and systemd-homed go together:-

• Arch Linux systemd-homed description
• pam_systemd_home manpage

The error messages are consistent with this.

You've mentioned local logins and ssh are working OK. Are they using pam_systemd_home or the system-auth include?

Thanks.

[usul0184]

Local logins and ssh both include system_auth through a few other includes. For what it's worth, /etc/pam.d/sshd is the same as /etc/pam.d/xrdp-sesman. loginctl session-status works under an ssh connection with the pam_systemd_home.so line in system-auth, unlike xrdp.

The weird thing is that the pam_systemd_home.so line is essentially making it optional. The problem occurs even with [default=ignore], which should render the module completely redundant but still produces an effect for some reason.

Curious if this is reproducible on other distributions?

[matt335672]

I'll get a manjaro VM set up so I can investigate this. I'll let you know what I discover.

[matt335672]

Hi @usul0184

I've got a Manjaro VM up.

There seem to be two issues here:-

1. pam_systemd_home won't work without systemd-homed. This isn't related to xrdp. I get plentry of errors in the logs related to sudo, like this:-

Sep 11 12:20:55 manjaro sudo[103222]: pam_systemd_home(sudo:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.

2. pam_systemd in /etc/pam.d/system-login which is supposed to be creating the session is what is failing with XRDP. This happens to me whether or not pam_systemd_home is commented out.

So I think the pam_systemd_home messages above, which are after all related to the pam account type rather than the session type can be ignored.

debug can also be added to pam_systemd.so in /etc/pam.d/system-login. This produces the following:-

Sep 11 12:17:29 manjaro xrdp-sesman[102896]: pam_unix(xrdp-sesman:session): session opened for user mjb(uid=1000) by (uid=0)
Sep 11 12:17:29 manjaro xrdp-sesman[102896]: pam_systemd(xrdp-sesman:session): pam-systemd initializing
Sep 11 12:17:29 manjaro xrdp-sesman[102896]: pam_systemd(xrdp-sesman:session): Asking logind to create session: uid=1000 pid=102896 service=xrdp-sesman type=x11 class=user desktop= seat= vtnr=0 tty= display=:10 remote=no remote_user= remote_host=
Sep 11 12:17:29 manjaro xrdp-sesman[102896]: pam_systemd(xrdp-sesman:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Sep 11 12:17:29 manjaro xrdp-sesman[102896]: pam_systemd(xrdp-sesman:session): Failed to create session: No child processes

which brings us back to your comments on #778.

My findings seem to be at odds with yours. Are you saying that when you comment out pam_systemd_home you get sessions created? That doesn't seem to be what I'm seeing.

There also seem to be other session-related issues with Manjaro. If I log in on the console and log out again, loginctl doesn't appear to be cleaning up my old session. Are you seeing that?

[usul0184]

Thanks so much for looking into this! My thoughts below.

Yes, if I comment out -account [success=1 default=ignore] pam_systemd_home.so, a session is created.

I’ve added debug to pam_systemd.so in /etc/pam.d/system-login. If I keep pam_systemd_home.so (and no session is created), journalctl shows:

Sep 12 00:55:22 bigone xrdp-sesman[657]: pam_systemd_home(xrdp-sesman:account): pam-systemd-homed account management
Sep 12 00:55:22 bigone dbus-daemon[632]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.308' (uid=0 pid=657 comm="/usr/bin/xrdp-sesman --nodaemon ")
Sep 12 00:55:22 bigone dbus-daemon[632]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found.
Sep 12 00:55:22 bigone xrdp-sesman[657]: pam_systemd_home(xrdp-sesman:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Sep 12 00:55:22 bigone xrdp[660]: (660)(140366010705472)[INFO ] xrdp_wm_log_msg: login successful for display 10
Sep 12 00:55:22 bigone xrdp-sesman[4221]: (4221)(140238321407808)[INFO ] calling auth_start_session from pid 4221
Sep 12 00:55:22 bigone xrdp-sesman[4221]: pam_unix(xrdp-sesman:session): session opened for user esyu(uid=1000) by (uid=0)
Sep 12 00:55:22 bigone xrdp-sesman[4221]: pam_systemd(xrdp-sesman:session): pam-systemd initializing
Sep 12 00:55:22 bigone xrdp-sesman[4221]: pam_systemd(xrdp-sesman:session): Asking logind to create session: uid=1000 pid=4221 service=xrdp-sesman type=x11 class=user desktop= seat= vtnr=0 tty= display=:10 remote=no remote_user= remote_host=
Sep 12 00:55:22 bigone xrdp-sesman[4221]: pam_systemd(xrdp-sesman:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Sep 12 00:55:22 bigone xrdp-sesman[4221]: pam_systemd(xrdp-sesman:session): Failed to create session: No child processes

If I comment out pam_systemd_home.so (and a session is created), journalctl shows:

Sep 12 01:00:44 bigone xrdp-sesman[5216]: (5216)(140238321407808)[INFO ] calling auth_start_session from pid 5216
Sep 12 01:00:44 bigone xrdp[660]: (660)(140366010705472)[INFO ] xrdp_wm_log_msg: login successful for display 10
Sep 12 01:00:44 bigone xrdp-sesman[5216]: pam_unix(xrdp-sesman:session): session opened for user esyu(uid=1000) by (uid=0)
Sep 12 01:00:44 bigone xrdp-sesman[5216]: pam_systemd(xrdp-sesman:session): pam-systemd initializing
Sep 12 01:00:44 bigone xrdp-sesman[5216]: pam_systemd(xrdp-sesman:session): Asking logind to create session: uid=1000 pid=5216 service=xrdp-sesman type=x11 class=user desktop= seat= vtnr=0 tty= display=:10 remote=no remote_user= remote_host=
Sep 12 01:00:44 bigone xrdp-sesman[5216]: pam_systemd(xrdp-sesman:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a
Sep 12 01:00:44 bigone systemd-logind[634]: New session 11 of user esyu.
Sep 12 01:00:44 bigone systemd[1]: Started Session 11 of user esyu.
Sep 12 01:00:44 bigone xrdp-sesman[5216]: pam_systemd(xrdp-sesman:session): Reply from logind: id=11 object_path=/org/freedesktop/login1/session/_311 runtime_path=/run/user/1000 session_fd=12 seat= vtnr=0 original_uid=1000

It makes sense that pam_systemd_home won't work without systemd-homed. What I don’t understand is why it has an effect even when its control field is set to be entirely ignored.

I agree there are other session-related issues; it seems that certain processes aren’t terminated when logging out. Some quick Googling seems to indicate that is a problem with the individual programs. Setting KillUserProcesses=yes in /etc/systemd/logind.conf resolves this, but I don’t think that has any impact on the pam_systemd_home.so issue.

[matt335672]

I'm afraid I've hit a bit of a brick wall with this.

1. Removing pam_systemd_home.so has no affect on my (clean) installation. I get no difference in behaviour - just a "Failed to create session: No child processes". I'm running systemd 246.4-1. This is at odds with the behaviour reported above, but I can see no reason for it.
   2.I can't find a way in Manjaro to get hold of a debugging package in the same way that I can with RPM or DEB. Consequently I'm not able to step into the PAM module using a debugger to see what's going on. There doesn't even seem to be an easy way to just build a source package from the existing distro packages.

Regarding the second, this seems like such a basic thing to be missing from an open source distribution that I must be missing something. Can anyone enlighten me?

[usul0184]

Thanks for looking into this! I'm afraid I'm not knowledgeable enough to answer your questions either, unfortunately. But it does seem like other people are having the same problem: https://bbs.archlinux.org/viewtopic.php?id=258716, https://aur.archlinux.org/packages/xrdp/. Hopefully someone with more experience than I do can chime in?

[matt335672]

I've asked for some debugging pointers on the Manjaro forums. Hopefully I'm missing something straightforward.

[cpoulsen-dezide]

Any progress on this @matt335672 ? (I'm the poster of the issue on the arch board)

I can add that I have since tried creating a systemd-homed backed user, copied the previously working .xinitrc over and still has the same issue. (If that is any help at all).

[matt335672]

Still nothing to report here.

I've figured out how to build a debug systemd package now on Arch, so it's just finding the time to get into the nuts and bolts of this. It's definitely on the list, but please feel free to nag me again.

[matt335672]

Sorry - fat fingers.

[matt335672]

I may have found a reason for this.

First thing to say is that on an up-to-date Manjaro (as of 2020-10-27), I'm seeing what @usul0184 sees - if pam_systemd_home.so is commented out the session gets created. There are three calls to it in /etc/pam.d/system-auth - one each for auth, account and password. Maybe before I hadn't managed to catch them all.

The problem sees to be that sesman is setting up the PAM stack in its main process for authenticating and authorizing, and then forking before it uses the PAM stack to create the session.

When the user is authorized (before the fork), pam_systemd_home.so is called. This uses DBUS. Later, when pam_systemd.so is called (after the fork) it also uses DBUS. Since this is not the first DBUS call, it tried to use the bus connection it set up earlier. There's a check however in sd_bus_call() (in libsystemd.so) that the process ID hasn't changed. If the ID has changed, ECHILD is returned by sd_bus_call(), which is what we are seeing.

Removing pam_systemd_home.so prevents this as the DBUS connection isn't set up when pam_systemd.so is invoked as part of setting up the session.

The workaround for now is to comment-out all calls to pam_systemd_home.so in /etc/pam.d/system-auth. At the moment I don't have a better solution.

[matt335672]

I've done a bit more investigation into this.

With systemd version 246, the systemd PAM module connection to the system DBUS is stored in a PAM data object called "systemd-system-bus" - see pam_get_data(3). These data objects cannot be accessed from the application itself, but can be accessed from other PAM modules.

With that in mind, I've knocked up a PAM session module which can be used after pam_systemd_home.so has been called to clear "systemd-system-bus" before pam_systemd.so is invoked. This is another workaround for the problem which is arguably less invasive than modifying /etc/pam.d/system-auth.

Module is at https://github.com/matt335672/pam_close_systemd_system_dbus

It's a hack - use at your own risk, and not in production environments.

We'll need changes to sesman to fix this properly. They're significant changes however, and will take a bit of time to implement and test.

[cpoulsen-dezide]

I don't know if its related, but I have always been presented with a bunch of password boxes when logging in over xrdp (various keychains/wallets etc. not being authenticated automatically) - these things are automatically authenticated when I do a local login.
I guess that is a sort of authentication issue, so I just wanted to mention it in case it is relevant. Thanks!

[matt335672]

Hi @cpoulsen-dezide

Does it happen if you use one of the workarounds above? It seems likely this problem is causing polkit to have some problems - see #1709

[cpoulsen-dezide]

I'll give it a shot when I get home from work tonight. I saw the same behavior (with the missing unlocking etc.) before the arch update to the pam stuff, and I have a colleague on ubuntu who is also seeing similar behavior

[matt335672]

If the workarounds don't fix it, check you're getting a session created and if so you may need some polkit entries. #1709 and #1584 contain some useful info.

[chrispoulsen]

The behavior I'm seeing when logging into KDE through xrdp is that I'm immediately promped to enter my kdewallet password. When I login locally the wallet is automatically unlocked. Various other actions also popup a password box ("sudo") when they need to elevate their priviledges. (systemd homed commented out in pam for this, session seems to be created)

I am able to enter my password in the authentication box and make it take effect, so I think it something else than #1709 and #1584.

It has been like this all the time I've used xrdp (since late '19) so it is not directly related to the recent pam/homed changes (I just wanted to mention it, in case it is related to the pam interactions). My colleague on ubuntu needs to configure his color profiles (or something like that) on every xrdp login (also not happening on local login), so there seem to be some difference between what is defined/connected (xrdp vs local login)

If you do not think this is related to this issue, let me know and I'll create a new one. The extra password boxes are more of an observation than a problem for me.

[matt335672]

Hi Chris,

I'm not familiar with KDE wallet. I've had a quick poke-around, and you've presumably got kwallet-pam installed, or the unlock wouldn't happen locally. Is pam_kwallet5.so configured in the PAM stack for xrdp-sesman? This looks like something that needs to be done manually.

All your other issues sound as if they're polkit related.

Polkit is used for conferring privileges on applications as needed. Importantly, it makes a distinction between sessions on the console and remote sessions. XRDP is always regarded as a remote session by polkit.

Exactly what polkit allows to happen in remote sessions (with or without a password) can be affected by system packaging, but is ultimately the responsbility of the system administrator. The reason for this is that different systems have different user bases and different security profiles. You might be happy to allow a single user to reboot their system from a remote session, but if that system is providing a terminal service for 10 remote users, you may not wish to allow that at all.

Please have at the commentary at #1584. We've stepped through enabling polkit logging so that you can see for a particular action what is being requested, and how to allow that. There should be enough info there to help you, but if not feel free to create another issue and we can work through it.

The Ubuntu box is also a Polkit thing and affects the Xorg backend only. There's a good explanation on this blog which may be of interest to your colleague. I believe the Ubuntu LTS versions currently use a polkit version which is older than the Arch/Manjaro version and not configured in the same way.

I hope that's useful.

[cpoulsen-dezide]

Thank you for the elaborate explanation, I think your observations about the polkit are correct.

I have already spent some time with the polkit debug logging from the other issue. Apart from a changed location of the polkit.service file in Arch, everything else was directly applicable.

The kde wallet/keyring is mentioned in the pam file for my window manager (sddm) - So I guess that it makes sense that I need to setup xrdp-sesman to work in a similar fashion to match my setup - Too bad you guys aren't clairvoyants and are able to pre-package a pam file for every possible setup 🤣

I'll make sure to forward the ubuntu link!

So I guess there is nothing to do, but wait for an updated sesman - luckily the workarounds are not that bad IMO

[sshaikh]

Came here from https://bbs.archlinux.org/viewtopic.php?id=258716 - my desktop is a 2 day old i3wm so I didn't realise this was a new issue!

Just another datapoint: default i3 loads fine with default xrdp install, my only symptom was broken audio, which led me to a broken systemctl --user and then finally to an unset XDG/DBUS env.

Commenting out the line from system-auth sovled the issue here.

Edit: some keywords in case someone has the same symptoms as I do:

DBUS_SESSION_BUS_ADDRESS blank empty
XDG_RUNTIME_DIR blank empty

[matt335672]

Thanks for the datapoint - it may well be of use to someone else.

[sshaikh]

Another observation that may or may not be related - i3-wizard fails to create a complete config via an xrdp session, demonstrating the same behvaior as described here: i3/i3#2141 (comment). Elsewhere this is attributed to an "xkb_keymap_key_get_syms_by_level returned no symbols for keycode" error.

The pam fix above does not fix this however. Let me know if a new issue needs to be created.

[matt335672]

In general it's a different issue if the PAM fixes don't address it.

Hope that's useful.

[matt335672]

Quick progress update - I've got no shareable code as yet, although I'm hoping to have some soon.

For new sessions, the fix involves moving the user authentication and authorization into the initial sesman fork (the session leader). This process will ensure that all the necessary PAM calls before and after the session are made from the session leader, taking #350 (CVE-2017-6967 and #688 into account. Systemd compliance pretty much forces this approach to be used.

The implementation I'm working on has these features:-

• a new communication channel between sesman and the session leader (i.e. a private session leader API callable from sesman).
• session.c is currently a mix of session management code and the session leader code. I'm factoring the session leader code out from session.c into a separate file. This should hopefully make sesman easier to read.

Sesman also provides authentication for reconnection attempts and for proxy requests. These are currently handled in the main sesman process, and unless testing shows otherwise I'm not planning on changing this (but see below). In these instances the PAM contexts are very short-lived and are torn down immediately after authentication.

There are some limitations with the current implementation which I've currently left out of scope of the code I'm working on:-

• Because the current implementation performs all authentication in the main process thread, there's an assumption that authentication will complete in a timely fashion. If it doesn't (for example if you're in a domain and the DCs are unavailable), sesman will not be able to perform any other activities until the authentication times out.
• I've found a potential problem related to signal safety and adding new sessions. I'll raise an observation about it.

[hardhu]

Just a minor comment to this thread from a not-so-experienced linux user.
I have successfully installed Manjaro Ornara 21.0.4 XFce on Hyper-V with enhanced session, that means that I use xrdp to connect to guest Manjaro.

At the beginning I had problems to login: the xfce session was not starting after the xrdp login, and after some seconds I was back to xrdp login window.

So I edited .xinitrc and manually added the following line:
exec dbus-launch --sh-syntax xfce4-session

In this way xfce started, but I had problems with authorizations: I cannot update or add any software using Add/Remove Software gui because I get an “authentication” failed message.

This seems related to the issue discussed here, so I then applied one of the workaround here described, that is to comment out all lines with reference to pam_systemd_home.so in /etc/pam.d/system-auth
In this way I could get rid of the mentioned authentication problems, but not completely: indeed, when I try to update the kernel using Manjaro Graphical Settings Manager, I get "Changes failed, click on ‘Show Details’ for more information, but no information at all is provided.
The problem is only using the graphical interface, because I have successfully updated kernel using sudo mhwd-kernel -i linux512

[sshaikh]

@hardhu

On Arch via the AUR there was a bug in the build script that causes startwm.sh not to set up a correct environment. Details of the patch to fix it here:

https://aur.archlinux.org/cgit/aur.git/commit/?h=xrdp&id=b80ddf90ef7ce5f1688c670e3c85dd3e485f6efb

If your startwm.sh doesn't do the same there's a chance you'll see these kind of errors.

[hardhu]

@hardhu

On Arch via the AUR there was a bug in the build script that causes startwm.sh not to set up a correct environment. Details of the patch to fix it here:

https://aur.archlinux.org/cgit/aur.git/commit/?h=xrdp&id=b80ddf90ef7ce5f1688c670e3c85dd3e485f6efb

If your startwm.sh doesn't do the same there's a chance you'll see these kind of errors.

I don't know if I have exactly understood your message (as I wrote, I am not a linux expert), but if the problem you mention is related only to the #arch user and #arch blocks of code missing in /etc/xrdp/startwm.sh, I see that I have them in my one.

[Cromagnon31]

Two xrdp versions have been published for Manjaro on AUR since this issue has been reported.
Issue is always present.
Is a fix planned for this issue ?

[matt335672]

Yes it is.

It's a huge amount of work however. I'm hoping to get more of the SCP issues sorted out in the next release cycle, but given the architectural changes required (see #1961) it's going to take a while I'm afraid.

[HubKing]

Yes it is.

It's a huge amount of work however. I'm hoping to get more of the SCP issues sorted out in the next release cycle, but given the architectural changes required (see #1961) it's going to take a while I'm afraid.

Your page says:

Workaround for XRDP #1684

THIS IS A HACK - DO NOT USE IT IN PRODUCTION. IT HAS ONLY BEEN TESTED IN A NARROW RANGE OF CIRCUMSTANCES.

but I could not get XRDP working with Gnome Manjaro without that. Why should I not use it in production? Does it have a serious security problem or something?

[matt335672]

It's relying on an undocumented interface. If the interface changes, it will stop working, but nothing else bad should happen.

If you understand what it's doing, and you're OK with a major systemd update possibly breaking it (i.e. this will be caught by your own testing), then go ahead and use it.

[sshaikh]

Thanks for the hard work in completing this! Can you please elaborate on what workarounds etc we can now unwind?

[matt335672]

It's just merged into devel, so it will be a while before it hits an actual release. If you're happy to build devel, please do so, but please bear in mind it's a big change, so you might want to do some pre-prod testing of your own.

You shouldn't need to use the workaround module at https://github.com/matt335672/pam_close_systemd_system_dbus any more, or comment out pam_systemd_home.so.

[chevaris]

Not sure if it is related in any manner, but I have been using the WA module during last year succesfully. During last weeks I made a Manjaro update (via pamac update -a) and I saw that /etc/pam.d/xrdp-sesman removed configuration for the module (Credentials NOT requested again anymore for instance). It is working fine,
BUT
I observe massive amount of CPU usage by xrdp and gnome-shell compared with previous situation. Could be related with new fix?

UPDATE: I have realized that the fixed is NOT loaded yet in Manjaro. Currently using xrdp 0.9.22.1-1
Maybe something in this release is causing the extra CPU usage?