Can xrdp DefaultWindowManager script determine the port to which the user connected?

[jkeltz]

Hi.

I would like to know whether it's possible to run a different xrdp "DefaultWindowManager" script based on the port to which the user connected? or even better, can the existing script determine from which port the user is connected?

More detail:
I use one system (Apache Guacamole) which presents my users with a list of hosts to which they can connect. Xrdp is running on all the hosts. For one lab of hosts, I want Guacamole to offer two choices that go to the same. Both of them would connect to XRDP on the host, but the xrdp script that would run would be slightly different for both options.

I figured that one way I might be able to accomplish what I want is if instead of just running xrdp on each host on just port 3389, I allow it to listen to port 3390 as well. I could configure Apache Guacamole to connect to port 3389 for one option, and port 3390 for the other. If I could either run a different script based on the port to which the user connected, or even better, if my existing start script could just differentiate itself based on the port the user connected, my problem would be solved.

Right now, I see in xrdp-sesman.ini "[SessionVariables]" script, a setting for PULSE_SCRIPT. If I could add my own custom variable here, "XRDP_PORT=%port%" or something like that then my start script could read the environment variable, and act accordingly depending on what option the user chose. Something like this may be possible already, but after looking over the man pages multiple times, and doing various Google searches, I can't seem to find anything.

I know that the script can already grep the output of netstat -n looking for port 3389|3390 reference, and determine if a user on this machine is connected to port 3389 or 3390, but this just tells me that a user on this machine is connected - not which is used by my current session. That's right, one user may be connected to either option at the same time.

Any help would be greatly appreciated.

Jason.

[matt335672]

Hi @jkeltz

There's nothing which will support what you're looking for in the way you suggest, but one way might be to run two instances of xrdp and xrdp-sesman on the target host.

One instance would use ports 3389 and 3350, and the other could use 3390 and 3351 (for example). Or you could listen on different IP addresses if you overload your listening address.

You would need xrdp v0.9.15 or later for this. This version of xrdp supports passing a '-c' option in to the daemons, which would allow you to do what you want by setting different environment variables in the [SessionVariables] section of xrdp/sesman.ini

I haven't tested this myself, and it might be a bit fiddly to set up, but I think it should work.

[jkeltz]

Hi @matt335672

Thanks for your reply. I was thinking about that as well, but really wanting to avoid running multiple xrdp/xrdp-sesman on one system if at all possible because it just makes the setup more complex. I also have to apply this to 150+ systems. Do you think it would be worthwhile to request an enhancement to allow a SessionVariable to include something dynamic like "%port%"? Maybe there are other useful "dynamic" entries that could be added. I don't know if that would be considered.

Jason.

[matt335672]

Can we dig a bit more into what you're trying to achieve here?

I can see a couple of significant issues, but I may well be misunderstanding your requirement. These issues are:-

1 If you're using a single daemon that as things stand there would be nothing stopping a user connecting to a session started on the other port, i.e.:-

• User A connects to port 3389
• Session is started
• User A later connects to port 3390, and is then redirected to the original session.

The session variable would be set to 3389, as once the session is started, these do not change - they're just environment variables created when the session is created.

2 With a modern systemd-based system which uses systemd --user, a user on one machine can only have one graphical session regardless of how it is started. This is a limitation of systemd --user, not a limitation of xrdp. So if user A is connected to a machine already, an attempt to start another graphical session on the same machine as user A will not work well. You can work around this with some desktops, or by using a non-systemd based distro or OS.

You haven't told us enough of your actual requirement for me to tell whether these are significant problems or not.

[jkeltz]

Hi Matt,

I'm more than happy to provide more details. Typically, I try my best on mailing lists to try to describe the problem in the simplest way I can, because people don't usually have time for longer descriptions. :) I'm more than happy to write details.

In my environment (several education computer labs), first year students don't typically get an account. They login to hosts in the certain lab as user "user" with no password (which of course only works on the local console). They get an environment that resets back to defaults after their session. In later years, they get an account, and a home directory. In the lab, whether a first year students logs in as user "user", or a later year student logs in with their username and password, everything just works perfectly as I would expect.

During covid19 times, we decided to use Guacamole to provide access to the students to many lab computers that would have otherwise just been sitting there unused. We had to generate accounts so that everyone could login to "Guacamole" as required. However, first year students would still use the "user" (resetting) environment.

I made a bunch of host entries for these lab machines in Guacamole, and configured Guacamole to connect to the the first year lab computers as user "user". Everything actually seemed to work great. The environment worked just like in the lab with the exception that those hosts could only be used for user "user", and not for regular users. However, I then discovered a major unperceived flaw! When a user would drop their session, another user could pop in and resume it which wasn't what I wanted. I could have ensured that when a session was dropped, it was terminated right away, but I really didn't want the student to lose their work. I wanted to give them a few minutes to come back. I came up with a plan to log the user in with their actual username and password, and during the login process via scripting to switch over to user "user". This actually worked much better, and has been used fine for awhile.

The only problem is that unlike on the local computer console, those computers can now only be used in Guacamole by user "user", and can't be used by any other courses that need the standard environment. I know that to do what I want to do, I need two host entries in Guacamole for each host anyway because each entry also has an sftp entry back to the machine to allow files to be dragged back and forth. The "user" entry has to connect to sftp in one way, and the regular entry has to connect as the given user. I actually don't mind if user X can only connect to port 3389 OR 3390, and can't do both. In fact, I would enforce that with the script anyway. In addition, students will only see one option (while the teachers/admins would see both).

I know if I use the dual xrdp/xrdp-sesman that you suggested, I could have 3389 be the "regular" user (like on all the other machines), and 3390 be just for user "user" environemnt. It would work. I guess if there was just some way to do it without having to run another set of daemons it would be preferable, although I honestly don't really see an option with the existing setup.

Thanks for taking an interest in my problem, and providing your feedback. I appreciate your time!

Jason.

[jkeltz]

I had a look, and it appears that the pid file location is hard-coded. This would mean that I would have to also compile a separate xrdp daemon to change the pid path...

Jason.

[jkeltz]

In addition to this issue, there's another issue... it appears that xrdp automatically reads the xrdp-sesman port from sesman.ini! It doesn't know that I created an alternate sesman.ini (sesmanu.ini) and even though both xrdp and xrdp-sesman allow you specify the configuration path on the command line, xrdp daemon doesn't know which sesman.ini to use for finding the management port.

[matt335672]

Thanks for the extra info - a long description is better I think as it makes it much easier to explore options.

Your observations regarding the sesman port are indeed going to make it impossible to use my suggestion. I think we can work around the PID issue, but not the port one.

One option close to where you currently are is for Guacamole to send over the shell for the user to run. You could use this to run something other than the standard startwm.sh script for some users.

Another way which is potentially more manageable (in my limited opinion) to do this could be to use a characteristic of the user account rather than of the destination host.

Are you using some sort of directory for users and group (AD/LDAP or whatever)? If so, could you simply add the users to a "year1" group and pick that up in your script? In shell, you could do something like this:-

#!/bin/bash
. . .
in_year1()
{
    local i
    set -- $(id -Gn)
    for i; do
        if [ $i = year1 ]; then
            return 0
        fi
    done
    return 1
}
. . .
if in_year1; then
    # Do some magic
. . .

That moves the problem into the directory server, which is a single point-of-admin. There are probably better ways to test for group membership, but that's off the top of my head.

Let me know if either/both of those sound like potential ways forward.

[jkeltz]

Hi Matt,
The truth is, I think the sesman port issue is a bug and I should probably report as such. Both xrdp and sesman take a -c option (in fact it was my request to add that functionality), but it's not correct for xrdp to simply look at sesman.ini (likely to find the management port) when sesman.ini might, in fact, be mapped to a different location. If xrdp is only looking at sesman.ini for the management port, then maybe you can specify the management port on the command line for xrdp as well.

From what I can tell, Guacamole can't send over the shell to be run. There are limited options in that respect. I can only specify the host and the port. This is why it would be useful if the session manager allowed me to specify a different script depending on the port called.

In addition, I've considered using groups as well (we're using Samba AD), but that only works if you get access to one or the other group. It doesn't work if you have certain users who are members of both groups... a teacher has to be able to access the first year environment, or the regular environment on the same machine. They aren't even in the firstyear group, but if they were it wouldn't know which option to choose.

One "hacky" way I thought about making this work would be to have Guacamole login to the host as -USER. Now, a PAM module sees -USER, and reverts back to "", but it seems kind of hacky. This may be the option if I could figure it out.

Thanks again...
Jason.

[matt335672]

By all means report a bug - we added the -c option as a feature request which you yourself raised in #1588!

I've got an old Guacamole installation. I can't be certain what the version is, but it's running on Fedora 31 in containers. In that, I can't create a connection and specify an initial program, but if I edit the connection after creation I can do so:-

So that may be worth revisiting. If you know a way I can find the guacamole version I can tell you what it is.

I take the point about groups. However, you could work around the teacher issue by adding a separate group for staff, and then using a Zenity dialog to prompt the teacher on login which type of session they want to run. I can sketch something out for you along those lines if it sounds like a goer.

In any case, thanks for the interesting discussion.

Matt

[jkeltz]

Hi Matt,
I believe I tried using the "initial program", but I think it's a Windows specific thing, as are most of those options. I even though of changing the keyboard layout, or timezone as an indication as well, but I don't get the info in xrdp. I think you can find the Guac version on the login screen.

I understand the Zenity idea, and was actually thinking of going that way to begin with. It's just that the guac sftp connection back to the machine ties the drag/drop capability to the "sftp" user. If admins (or come to think of it 2nd+ year students) used the system, drag of files wouldn't go to their directory, but to "user" directory. That's the reason I started thinking about options for moving to a dual script setup. If only there was a way to pass something from those guac options into xrdp as a "hint" that the user chose the other option, it would be ideal.

Thanks for your help..
Jason.

[matt335672]

Initial program works for me.

I set mine to /etc/xrdp/startwm2.sh, then on the target box:-

1. copied /etc/xrdp/startwm.sh to /etc/xrdp/startwm2.sh
2. edited /etc/xrdp/startwm2.sh to set the environment variable XRDP_SESSION_TYPE=zzz

On login, I get this in /var/log/xrdp-sesman.log:-

[20210714-17:04:05] [INFO ] [session_start_fork(session.c:589)] Starting user requested window manager on display 11: /etc/xrdp/startwm2.sh

Previously I had:-

[20210712-14:10:16] [INFO ] [session_start_fork(session.c:621)] Starting the default window manager on display 10: /etc/xrdp/startwm.sh

Also the environment variable is set.

Do you want to give it another go? Maybe you had a file permissions issue or similar, and you ended up defaulting back to the stardard script.

[matt335672]

Also:-

root@748c2f6db150:/# /usr/local/guacamole/sbin/guacd -v
Guacamole proxy daemon (guacd) version 1.2.0

[jkeltz]

Matt,

You are absolutely correct! I just tried, and that works perfectly! I'll have to plow through the older logs later to see what I did wrong before, but this is excellent news. It gives rise to all kinds of other interesting possibilities as well.

Thanks much much for your help, and patience!!!
Jason.
PS: Does this forum only let me mark my final post as an answer, and not your response?

[matt335672]

Great - glad we got there, and thanks for the feedback.

One other thing which you might want to be aware of is since PR #1270, it should be possible to pass parameters to the 'initial program' by using spaces. That might help to simplify the scripts a bit.

I can't comment on the answer marking I'm afraid, as the discussions are relatively new to us all here. I think getting it as close as you can will be fine for most people reading this,

[matt335672]

I've marked the last comment as an answer, even though it doesn't really fit. However, any reader should be able to figure this one out.

Anyone who does read this far might want to also see @jkeltz's #1948 which is somewhat relevant to the discussion