Bug 1177202 - xrdp fails to start with permission denied error
xrdp fails to start with permission denied error
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
23
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
: Reopened
: 1205939 1244573 1352262 (view as bug list)
Depends On:
Blocks: 1258453
  Show dependency treegraph
 
Reported: 2014-12-25 00:27 EST by Jim
Modified: 2016-11-02 18:31 EDT (History)
27 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-158.15.fc23 selinux-policy-3.13.1-158.21.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-02 05:26:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim 2014-12-25 00:27:08 EST
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.
Comment 1 Jim 2014-12-25 10:53:01 EST
To get a flavor of how the investigation unfolded see: http://forums.fedoraforum.org/showthread.php?t=302176.

I did not experience the problem in F20. For me it showed up after upgrading, via fedup, to F21. In the above thread, stasyok, reported that he had the problem in F20. I suspect that, for some reason, I did not have SELinux enabled in F20 and the upgrade enable it.

Stasyok discovered that copying /usr/sbin/xrdp* to /usr/bin and then copying the /usr/sbin files back to /usr/sbin fixed the problem. I was the one to discover that it was the security context change caused by the copy that fixed the problem.
Comment 2 Clarke Wixon 2014-12-29 11:06:07 EST
I'll confirm this.  I used xrdp frequently in F20, and now in F21 (upgraded via fedup, like Jim) I get the same problem -- SELinux is apparently keeping the services (xrdp and xrdp-sesman) from starting, silently, without any notification from SELinux -- I do get the same log messages as above.

I DID have SELinux enabled in F20, so I'm reasonably sure this is a problem associated with either the upgrade or the present xrdp package vesion.

Setting SELinux to permissive mode will then allow me to restart the services without problem.  I haven't tried resetting the executable file contexts as Jim did, but I suspect the outcome would be the same.
Comment 3 Patrick Reinhart 2015-01-05 07:19:00 EST
Exactly the same problem here
Comment 4 Jim 2015-01-09 21:55:17 EST
Just did a yum update and that included an update to xrdp. As I expected, that rebroke the service. All I had to do to get it working again was:
sudo chcon --type=bin_t /usr/sbin/xrdp
sudo chcon --type=bin_t /usr/sbin/xrdp-sesman
sudo systemctl reenable xrdp.service
sudo systemctl start xrdp.service

This to me confirms that type is the problematic setting.
Comment 5 Clarke Wixon 2015-01-13 15:14:28 EST
I'll confirm Jim once again -- that's exactly how I fixed my installation.  I never tried copying to /usr/bin and back; I went straight for the chcon.

I wonder if it would be a good idea to update this bug so the affected Component is selinux-policy rather than xrdp.  If the real problem lies in the file contexts and transition rules, it might make sense to have those SELinux folks looking at it.
Comment 6 Jim 2015-01-13 21:25:36 EST
I am curious about who owns this problem, too.
Comment 7 Hakan Duran 2015-01-27 15:22:02 EST
Thank you for this very informative thread. I discovered today that I had the same issue and Jim's solution above worked as a charm.
Comment 8 Satta Matka 2015-01-29 06:41:56 EST
(In reply to Jim from comment #4)
> Just did a yum update and that included an update to xrdp. As I expected,
> that rebroke the service. All I had to do to get it working again was:
> sudo chcon --type=bin_t /usr/sbin/xrdp
> sudo chcon --type=bin_t /usr/sbin/xrdp-sesman
> sudo systemctl reenable xrdp.service
> sudo systemctl start xrdp.service
> 
> This to me confirms that type is the problematic setting.

Hi Buddy,

I have been searching for the solution of this issue on Fedora 21 and was unable to find the right, I am really glad that your solution worked for.

Thank You Very Much,

SattaMatka Satta

(http://www.indianmatka.com)
(http://www.dailymatka.com)
Comment 9 Gabriel Somlo 2015-03-25 19:51:17 EDT
if "chcon -t bin_t /usr/sbin/xrdp*" works, the bug might be in selinux_policy.

I switched the "component" of this bug to selinux, hopefully that gets the attention of the right fedora people...
Comment 10 Miroslav Grepl 2015-04-09 12:42:00 EDT
There was a reason to have

/usr/sbin/xrdp	system_u:object_r:unconfined_exec_t:s0

in older Fedora. 

Basically if you log in using, what does

$ id -Z
Comment 11 Gabriel Somlo 2015-04-09 13:17:23 EDT
I still can't actually log all the way in via xrdp (see bug 1205939), so I can't run 'id -Z' that way.

For whatever it's worth, if I run it from an xterm while logged in from the actual console, it says "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"
Comment 12 Miroslav Grepl 2015-04-10 02:58:18 EDT
(In reply to Gabriel Somlo from comment #11)
> I still can't actually log all the way in via xrdp (see bug 1205939), so I
> can't run 'id -Z' that way.
> 
> For whatever it's worth, if I run it from an xterm while logged in from the
> actual console, it says
> "unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023"

Which is correct.

So we need to wait for #120593 fix.
Comment 13 mko 2015-04-10 08:21:20 EDT
I use Centos 7.1 with xrdp-0.6.1-7.fc20.x86_64 and fixed the xrdp service start failure with 
> sudo chcon --type=bin_t /usr/sbin/xrdp
> sudo chcon --type=bin_t /usr/sbin/xrdp-sesman

as mention by Jim.

User authentication is done with Active Directory, users with existing home dir could login. New user will get 'Call to Inusertemp failed (temporary directories full?). Check your installation.' from af KDE desktop.

journalctl
SELinux is preventing /usr/sbin/oddjobd from using the transition access on a process. For complete SELinux messages. run sealert -l 893ca98b-f16f-453f-bd84-4705dfacb5fa

[root@test ~]#  sealert -l 893ca98b-f16f-453f-bd84-4705dfacb5fa
SELinux is preventing /usr/sbin/oddjobd from using the transition access on a process.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that oddjobd should be allowed transition access on processes labeled unconfined_service_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep oddjobd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:oddjob_t:s0-s0:c0.c1023
Target Context                system_u:system_r:unconfined_service_t:s0
Target Objects                /usr/libexec/oddjob/mkhomedir [ process ]
Source                        oddjobd
Source Path                   /usr/sbin/oddjobd
Port                          <Unknown>
Host                          test
Source RPM Packages           oddjob-0.31.5-4.el7.x86_64
Target RPM Packages           oddjob-mkhomedir-0.31.5-4.el7.x86_64
Policy RPM                    selinux-policy-3.13.1-23.el7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     test
Platform                      Linux ri-ngs-test 3.10.0-229.1.2.el7.x86_64 #1 SMP
                              Fri Mar 27 03:04:26 UTC 2015 x86_64 x86_64
Alert Count                   12
First Seen                    2015-04-09 11:39:28 CEST
Last Seen                     2015-04-10 14:09:21 CEST
Local ID                      893ca98b-f16f-453f-bd84-4705dfacb5fa

Raw Audit Messages
type=AVC msg=audit(1428667761.386:408): avc:  denied  { transition } for  pid=2731 comm="oddjobd" path="/usr/libexec/oddjob/mkhomedir" dev="dm-1" ino=136553087 scontext=system_u:system_r:oddjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process


type=SYSCALL msg=audit(1428667761.386:408): arch=x86_64 syscall=execve success=no exit=EACCES a0=7fa295a906b0 a1=7fa295a96260 a2=7fa295a90d20 a3=7265735f64656e69 items=0 ppid=1319 pid=2731 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=oddjobd exe=/usr/sbin/oddjobd subj=system_u:system_r:oddjob_t:s0-s0:c0.c1023 key=(null)

Hash: oddjobd,oddjob_t,unconfined_service_t,process,transition

I think these is related.
Comment 14 Clarke Wixon 2015-04-14 18:33:47 EDT
I'm not sure why 1205939 is blocking this one -- that sounds like a very different bug, and xrdp works for me and others following Jim's SELinux context change presented upthread (comment 4).

In any case, with that context change made, and logged in via xrdp and inside a gnome terminal, when I run 'id -Z' I get:

system_u:system_r:unconfined_service_t:s0
Comment 15 Gabriel Somlo 2015-04-14 21:17:46 EDT
(In reply to Clarke Wixon from comment #14)
> I'm not sure why 1205939 is blocking this one -- that sounds like a very

Because Miroslav asked for 'id -Z' output from an terminal opened from within
an xrdp session, and, on a vanilla up-to-date f21 install and the workaround

	chcon -t bin_t /usr/sbin/xrdp*

applied (to be able to start the xrdp service), I can't actually log in
all the way and get a terminal and run that command.

If some selinux policy update actually ends up fixing the xrdp service
startup issue for others tracking this bug, I have no problem with
removing the dependency :)
Comment 16 Clarke Wixon 2015-04-26 14:06:43 EDT
Same bug exists in f22 beta as of today.  With:

xrdp-0.6.1-8.fc22.x86_64
selinux-policy-3.13.1-122.fc22.noarch

And as before, using chcon to change xrdp and xrdp-sesman to type=bin_t allows the services to start and run normally for me.
Comment 17 Gabriel Somlo 2015-04-27 17:25:15 EDT
I set up a VM and installed from the beta 22 x86_64 live workstation image.
Got the same versions as cwixon in comment 16 above.

After running "chcon -t bin_t /usr/sbin/xrdp*" I can get in *eventually*
(still getting lots of fast-scrolling seemingly repeating over and over
messages in the Connection Log window, but I'm willing to assume all that
is unrelated to this bug). I'm trying to remove the dependency I added on
bug 1205939, as that's most likely unrelated.
Comment 18 Itamar Reis Peixoto 2015-07-15 11:48:14 EDT
how can we fix this bug ?
Comment 19 Gabriel Somlo 2015-07-15 16:09:28 EDT
Still happens in F22, and "chcon -t bin_t /usr/sbin/xrdp /usr/sbin/xrdp-sesman" is still a workaround.
Comment 20 Itamar Reis Peixoto 2015-07-15 16:16:57 EDT
*** Bug 1205939 has been marked as a duplicate of this bug. ***
Comment 21 Seb L. 2016-02-04 11:23:42 EST
Still happens in F23, and "chcon -t bin_t /usr/sbin/xrdp /usr/sbin/xrdp-sesman" is still a workaround.
Comment 22 Dominik Gronkiewicz 2016-02-25 15:31:01 EST
I confirm this in Fedora 23. This bug is so old, it was first mentioned back in 2007. This is ridiculous.
Comment 23 Christopher Tubbs 2016-03-08 16:52:59 EST
This bug also seems to affect RHEL7 and CentOS7.
Comment 24 Lukas Vrabec 2016-05-03 11:00:07 EDT
*** Bug 1244573 has been marked as a duplicate of this bug. ***
Comment 25 Fedora Update System 2016-06-22 11:26:36 EDT
selinux-policy-3.13.1-158.20.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-4c9c2badcb
Comment 26 Fedora Update System 2016-06-22 18:58:35 EDT
selinux-policy-3.13.1-158.20.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-4c9c2badcb
Comment 27 Fedora Update System 2016-07-02 16:54:33 EDT
selinux-policy-3.13.1-158.21.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7bed6e7c72
Comment 28 Todd 2016-07-03 00:58:38 EDT
This bug also reproduces in EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1352262
Comment 29 Fedora Update System 2016-07-13 20:23:20 EDT
selinux-policy-3.13.1-158.21.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 30 Itamar Reis Peixoto 2016-10-28 21:18:05 EDT
*** Bug 1352262 has been marked as a duplicate of this bug. ***
Comment 31 Itamar Reis Peixoto 2016-10-28 21:19:11 EDT
happens in Fedora EPEL / Centos / RHEL 7 too.

https://bugzilla.redhat.com/show_bug.cgi?id=1352262
Comment 32 Lukas Vrabec 2016-11-02 05:26:40 EDT
I open new bug against RHEL, this one should be closed if it's fixed in F23
Comment 33 Christopher Tubbs 2016-11-02 18:31:42 EDT
(In reply to Lukas Vrabec from comment #32)
> I open new bug against RHEL, this one should be closed if it's fixed in F23

Can you link to the new bug against RHEL, so subscribers can follow that one?

Note You need to log in before you can comment on or make changes to this bug.