https://bugzilla.redhat.com/show_bug.cgi?id=1177202

Also occurs under Scientific Linux 7.2

To quote from bug 1177202:

Description of problem: After booting up, I tried to remote desktop from Windows 8.1 machine to Fedora 21 machine. That failed. Looking at running processes on F21 machine, noticed that there were no xrdp processes running. Expected to see xrdp and xrdp-sesman running. Viewing /var/log/messasges showed these messages:
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 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.


Version-Release number of selected component (if applicable):
xrdp-0.6.1-5.fc21.x86_64

How reproducible:
Try to remote desktop (rdp protocol) to F21 machine

Steps to Reproduce:
1. Install xrdp
2. start xrdp service 
3. try to remote desktop from Windows machine to Fedora machine

Actual results:
Attempt to connect fails, /var/log/messages shows errors noted above, no xrdp processes running in Fedora

Expected results:
Attempt to connect succeeds, /var/log/messages shows no errors noted above, xrdp and xrdp-sesman processes running in Fedora

Additional info:
I am running with SELinux enabled. The problem appears to be with the security context of (at least) files /usr/sbin/xrdp and /usr/sbin/xrdp-sesman. The security context of these files, as installed, is "system_u:object_r:unconfined_exec_t:s0". Changing the security context to "unconfined_u:object_r:bin_t:s0" allows the service to start. This modified security context may not be optimal but it at least allows the service to start. If I had to guess the problematic setting is type=unconfined_exec_t.