user namespaces affects session management may be suspended after KillDisconnected

[tsz8899]

xrdp version

0.10

Detailed xrdp version, build options

No response

Operating system & version

debian

Installation method

git clone & make install

Which backend do you use?

No response

What desktop environment do you use?

No response

Environment xrdp running on

No response

What's your client?

No response

Area(s) with issue?

No response

Steps to reproduce

When KillDisconnected triggers termination of a session, it immediately releases that session’s X11DisplayNumber. However, the session may not have fully terminated at that time, or it may have failed to terminate properly.
During this interval, a new session may connect and be assigned the same X11DisplayNumber, As a result, all subsequent new sessions are unable to enter the X11 session and instead display the XRDP login screen or a black screen.

If the user manually logout of the session, the X11DisplayNumber is released properly and this problem does not occur.

✔️ Expected Behavior

Request / Question
After KillDisconnected, is there a way to verify that an X11DisplayNumber is actually available before notifying the service to allow a new session to use it?
Or can a delay be introduced to ensure the old session has been fully cleaned up before the display number is reused?

❌ Actual Behavior

No response

Anything else?

No response

[matt335672]

Hi @tsz8899

Thanks for posting this.

I'm having trouble understanding how this is happening to you.

When a session is started, an X display number is allocated by sesman. This is passed to sesexec to start the session. sesman keeps a record of the display number in the session list.

While the session is on the session list, the display is unavailable to be allocated to another session. This check is implemented in session_list_get_available_display()

The KillDisconnected is currently implemented in xorgxrdp. When this triggers, the X server will receive SIGTERM and exit. This is picked up by sesexec.

sesexec then kills the rest of the session and exits. sesman picks up on sesexec exiting and removes the session from the list. At that point the display is available for new sessions.

All the postings we get from you are high quality, so I'm sure you're encountering a problem somewhere, but based on the information I've got so far I'm unable to find it.

Have you got any logs for this?

Thanks,

[tsz8899]

Thanks

Could you please check if the following analysis is correct?
I’m trying to share a file that both a service and users can access while /tmp user namespaces are enabled.

Failure trigger condition:
The system enables /tmp namespace isolation for regular users, but xrdp, sesman, and xorgxrdp still rely on the shared /tmp/.X11-unix/Xn and /tmp/.Xn-lock files to determine whether a display number is already in use by an existing session.
After the KillDisconnected timeout expires, xorgxrdp first sends a SIGTERM to the X server, and sesexec begins terminating the session.
If, during this time, the sesexec process (or its communication with sesman) exits earlier, sesman immediately removes the session from its list and releases the display number—even though the old X server has not yet fully cleaned up.

Reason the detection fails:
The function display_utils_get_free_display() relies on three checks to prevent reuse of an existing display number:

Verifying the existence of /tmp/.X11-unix/Xn socket
Checking for /tmp/.Xn-lock lock file
Attempting to bind to TCP ports 59xx/60xx/62xx
Since /tmp is now isolated per user, sesman and the newly spawned xrdp session cannot see those lock files that exist in the old session’s namespace.
As a result, all three checks incorrectly report the display as “free,” causing the function to assume the display number is available.
Race condition behavior:
If a new user connects during this short window, sesman reuses the display number that is still being cleaned up.
When the new X server tries to create /tmp/.X11-unix/Xn, it discovers that the resource is still occupied by the previous process and fails to start.
The client then either sees a black screen or is returned to the login interface.
The logs typically show that sesman releases and reallocates the same display number almost simultaneously, while the old Xorgxrdp or window manager process is still exiting.

Essential conclusion:
The root cause is not KillDisconnected itself, but that after /tmp is isolated, the "shared lock directory" that xrdp depends on to prevent display number conflicts becomes invisible.
All detection mechanisms fail as a result.
If a globally shared /tmp/.X11-unix (or an equivalent bind-mounted directory) is provided and made visible to all namespaces, the lock files become accessible again, and the display number reuse issue under KillDisconnected conditions disappears naturally.

[matt335672]

Hi @tsz8899

Thanks for the detailed analysis - that's very helpful, and I can see you've put a lot of work into it.

You're right that the poly-instantiated namespace will prevent a some of the display detection mechanisms working.

However, the KillDisconnected causes the X server to exit first. The X server has to exit and generate a SIGCHLD before sesexec will notice anything. By the time sesexec reacts, the display number will already be free. So I think there must be something else going on here.

Your analysis mentions that if sesexec exits before the X server we will have problems. Again, this is correct and I wonder if this is causing your original issue.

When a session is running, sesexec is designed to not exit until the X server, the session and chansrv have all finished. The following situations could mean sesexec exits too early:

1. sesexec is crashing
2. Another failure in sesexec is setting the g_terminate_loop variable which controls when sesexec exits:
   

   xrdp/sesman/sesexec/sesexec.c

   Line 271 in da82d96

   while (!g_terminate_loop)

This patch will generate a log message if sesexec exits too early:

--- a/sesman/sesexec/sesexec.c
+++ b/sesman/sesexec/sesexec.c
@@ -344,6 +344,11 @@ sesexec_main_loop(void)
             continue;
         }
     }
+    // The session should not be running at this point
+    if (session_active(g_session_data))
+    {
+        LOG(LOG_LEVEL_ERROR, "sesexec is exiting with an active session!");
+    }
 
     login_info_free(g_login_info);
 

Is that useful?