Can't remote desktop to F21 after upgrade from F20

[jim1944]

I just upgraded to F21 from F20 using fedup. Now I can't remote desktop from Windows to F21. It appears that xrdp won't start. This is what I've tried:
1. turning off the firewall
2. Doing 'sudo /bin/systemctl enable xrdp.service' and 'sudo /bin/systemctl start xrdp.service'. Both complete without complaint but there is still no xrdp process running ('ps -ef | grep xrdp' returns nothing except the grep process itself) and I can't connect.

What do I need to do to get this working again?

FWIW my firewall configuration has only SSH marked as a trusted service and one port added to 'Other Ports": 3389/tcp/ms-wbt-server. Nothing else is checked or added.

Thanks
Jim

[jim1944]

I was able to get it to work by, as root, running '/usr/sbin/xrdp-sesman' and '/usr/sbin/xrdp'. Doing this allowed me to do remote desktop from Windows. However this is just a workaround. So question still remains: What do I need to get this working the way it is supposed to work?

Thanks
Jim

[upnort]

Check that remote access is enabled (dconf: org.gnome.desktop.remote-access) and vino-server is running on the remote system.

[jim1944]

Check that remote access is enabled (dconf: org.gnome.desktop.remote-access) and vino-server is running on the remote system.

Since it does work when I manually start the xrdp processes and without vnc-server running, I don't think that these are relevant. Vino has to do with VNC not remote desktop.

Anyway, there is a script, /etc/xrdp/xrdp.sh which is supposed to start the xrdp processes but it does not work. It expects xrdp and xrdp-sesman to be in /usr/local/sbin. They are infact in /usr/sbin. I made the change to the script to correctly access the executables and the script does start them.

Still 'sudo /bin/systemctl enable xrdp.service' and 'sudo /bin/systemctl start xrdp.service' do not cause that script to be run.

Rebooting to see if the corrected script does get run a startup.

Jim

[jim1944]

Upon reboot the xrdp processes are not running. So, the script is incorrect but correcting it does not fix the underlying issue that the processes do not get started at bootup.

Jim

[jim1944]

OK, something is definitely fubar. This is what I see in /var/log/messages at bootup time:

Dec 23 17:57:16 localhost systemd: Failed at step EXEC spawning /usr/sbin/xrdp-sesman: Permission denied
Dec 23 17:57:16 localhost systemd: Failed at step EXEC spawning /usr/sbin/xrdp: Permission denied
Dec 23 17:57:16 localhost abrtd: Can't open file '/var/tmp/abrt/ccpp-2013-01-05-20:43:26-659/type': No such file or directory
Dec 23 17:57:16 localhost abrtd: Can't open file '/var/tmp/abrt/ccpp-2013-01-05-20:43:26-659/type': No such file or directory
Dec 23 17:57:16 localhost abrtd: '/var/tmp/abrt/ccpp-2013-01-05-20:43:26-659' is not a problem directory
Dec 23 17:57:16 localhost systemd: xrdp-sesman.service: main process exited, code=exited, status=203/EXEC
Dec 23 17:57:16 localhost systemd: Unit xrdp-sesman.service entered failed state.
Dec 23 17:57:16 localhost systemd: xrdp-sesman.service failed.
Dec 23 17:57:16 localhost systemd: xrdp.service: main process exited, code=exited, status=203/EXEC
Dec 23 17:57:16 localhost systemd: Unit xrdp.service entered failed state.
Dec 23 17:57:16 localhost systemd: xrdp.service failed.

Actually that shows two issues: xrdp processes did not start and there is some kind of problem with abrtd not finding /var/tmp/abrt/ccpp-2013-01-05-20:43:26-659/type. The directory /var/tmp/abrt/ccpp-2013-01-05-20:43:26-659 does exist. The content of /var/tmp/abrt/ is:

[jim@localhost xrdpbackup]$ cd /var/tmp/abrt
[jim@localhost abrt]$ ls -l
total 60
drwxrwx---. 2 root abrt 4096 Dec 23 17:57 ccpp-2013-01-05-20:43:26-659
drwxrwx---. 2 root abrt 4096 Dec 23 17:57 ccpp-2013-03-31-13:43:09-865
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2013-07-07-11:45:35-8260
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-01-03-14:27:19-1222
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-01-30-12:50:54-1170
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-04-02-15:38:27-1299
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-04-09-08:08:47-1232
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-04-24-12:56:37-1266
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-04-30-22:52:39-1246
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-11-23-22:09:14-1250
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-11-28-19:02:40-1259
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-12-21-14:19:56-1257
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-12-22-22:10:47-1754
drwxrwx---. 2 jim  abrt 4096 Dec 23 17:57 ccpp-2014-12-23-17:48:44-1808
-rw-------. 1 root root   19 Dec 23 17:48 last-ccpp
[jim@localhost abrt]$

Some of those directories have a file name type in them.

Returning to the xrdp issue: the xrdp.service file contains:

[Unit]
Description=xrdp daemon
Requires=xrdp-sesman.service
After=syslog.target network.target xrdp-sesman.service

[Service]
EnvironmentFile=/etc/sysconfig/xrdp
ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS --nodaemon

[Install]
WantedBy=multi-user.target

And the xrdp-sesman.service file contains:

[Unit]
Description=xrdp session manager
BindTo=xrdp.service
After=syslog.target network.target
StopWhenUnneeded=true

[Service]
EnvironmentFile=/etc/sysconfig/xrdp
ExecStart=/usr/sbin/xrdp-sesman $SESMAN_OPTIONS --nodaemon

[Install]
WantedBy=multi-user.target

I am curious about the --nodaemon option. That does not make sense to me and that is not the way /etc/xrdp/xrdp.sh starts the processes. So I removed the option and tried again with the same result.

So systemd is trying to start xrdp but can't. But I can.

Time to write a bug report? Any other ideas?

Thanks Jim

[stasyok]

Hi Jim

I met the same problem on a clean Fedora 20, without any upgrade operations. xrdp daemons simply were unable to start.

The problem was solved by copying all xrdp files from /usr/sbin to /usr/bin. After this both daemons start working.

[jim1944]

Hi Jim

I met the same problem on a clean Fedora 20, without any upgrade operations. xrdp daemons simply were unable to start.

The problem was solved by copying all xrdp files from /usr/sbin to /usr/bin. After this both daemons start working.

Thanks but that did not work. I'm guessing that your cause of faliure was different, proably a file not found vs. the permission denied error I'm getting.

It is kind of boggling my mind. Exactly what permission to what thing or activity is being denied and why? It has to be something that is denied to systemctl when trying to start the xrdp service but that is either not accessed or not denied when starting the processes by just running them with sudo.

Thanks
Jim

[Steve80289]

Reinstalling the package with

yum reinstall xrdp

...might help

[stasyok]

Thanks but that did not work. I'm guessing that your cause of faliure was different, proably a file not found vs. the permission denied error I'm getting.

It is kind of boggling my mind. Exactly what permission to what thing or activity is being denied and why? It has to be something that is denied to systemctl when trying to start the xrdp service but that is either not accessed or not denied when starting the processes by just running them with sudo.

Thanks
Jim

Sorry, i forgot to say that you also need to modify both .service files, xrdp and xrdp-sesman, (change 'sbin' to 'bin') and execute systemctl daemon-reload.
However, later i copied xrdp files back to /usr/sbin/, reconfigured .service files one more time (returned them to an original state) and my xrdp services still can be started without Permissions Denied error.
It looks like a problem with installation: files are created with wrong permissions, and copying to another direcrory fix this moment.

P.S. I tried re-installation before, it didn't help me.

[jim1944]

OK, I tried the reinstall and that didn't help but...(more on that in a moment).

I then tried pointing the service files to the /usr/bin copies and that did work (yaaa!). But that makes no sense since the permissions on both versions are the same including the permissions on the directories.

But (the moment has arrived) the sizes of the files in /usr/sbin were different than the copes in usr/bin which means that the resinstall provided different versions of those files. Why? You'd think that the upgrade and subsequent yum updates (latest done this morning) would result in the same versions of the files that I would get from a reinstall.

Anyway, I copied the new /usr/sbin files to /usr/bin and they still work. Haven't tried copying the files back and reverting the service files yet. I am a little reluctant to fix what, for now, isn't broken especially since nothing makes sense.

Another issue: won't we run into this problem again if there is an update to the xrdp package?

Thanks
Jim

[stasyok]

Another issue: won't we run into this problem again if there is an update to the xrdp package?

Yes, it's possible, so i made a backup of binaries and .service files. But i have a hope that in the next version of xrdp the problem will be fixed =)

[jim1944]

I have an idea. Copying the files does change the their security context as shown via ls --lcontext. For example:

[jim@localhost Desktop]$ ls --lcontext /usr/sbin/xrdp
-rwxr-xr-x. 1 system_u:object_r:unconfined_exec_t:s0 root root 91912 Aug 21 14:24 /usr/sbin/xrdp

While the copied version:
[

jim@localhost Desktop]$ ls --lcontext /usr/bin/xrdp
-rwxr-xr-x. 1 unconfined_u:object_r:bin_t:s0   root root 91912 Dec 24 15:13 /usr/bin/xrdp

Could this change be what is allowing systemctl to start the service? Do the files, as insalled, have the wrong security context? If not then what else?

Jim

[jim1944]

I think I have confirmed this. First I stopped xrdp service Then I used chcon to change the security context of the xrdp files copied to /usr/bin to the security contexts of the /usr/sbin versions and tried to start xrdp and it failed with permission denied. I then used chcon to revert the security contexts of the /usr/bin files to what they had been after the copy. I was then able to start the xrdp service.

So nthe security context of xrdp and xrdp-sesman, as installed, does not work and results in xrdp service failing to start with permission denied errors. That security context is "system_u:object_r:unconfined_exec_t:s0". These map to

• user = system_u
• role = object_r
• type = unconfined_exec_t
• range = s0

Changing the security context to "unconfined_u:object_r:bin_t:s0" allows the xrdp service to be started. I have no idea whether this is an optimal security context but at least it does not cause it to fail.

I think this is a bug that should be reported to bugzilla.

If I had to guess, based on what I've seen of the security contexts of other files, it is the "type = unconfined_exec_t" that is the problem.

I think this only matters if you are running with SELinux enabled which I am (type sestatus) at least since the upgrade to F21. Since stasyok saw the problem in F20 and I did not, I am speculating that SELinux was not enabled in my F20 and the upgrade enabled it.

Jim

[jim1944]

I opened up bug 1177202. https://bugzilla.redhat.com/show_bug.cgi?id=1177202

Jim