Bug 1177202

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.

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.

Exactly the same problem here

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.

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.

I am curious about who owns this problem, too.

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.

(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)

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...

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

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"

(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.

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.

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

(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 :)

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.

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.

how can we fix this bug ?

Still happens in F22, and "chcon -t bin_t /usr/sbin/xrdp /usr/sbin/xrdp-sesman" is still a workaround.

*** Bug 1205939 has been marked as a duplicate of this bug. ***

Still happens in F23, and "chcon -t bin_t /usr/sbin/xrdp /usr/sbin/xrdp-sesman" is still a workaround.

I confirm this in Fedora 23. This bug is so old, it was first mentioned back in 2007. This is ridiculous.

This bug also seems to affect RHEL7 and CentOS7.

*** Bug 1244573 has been marked as a duplicate of this bug. ***

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

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

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

This bug also reproduces in EPEL7
https://bugzilla.redhat.com/show_bug.cgi?id=1352262

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.

*** Bug 1352262 has been marked as a duplicate of this bug. ***

happens in Fedora EPEL / Centos / RHEL 7 too.

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

I open new bug against RHEL, this one should be closed if it's fixed in F23

(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?

(In reply to Matka420 from comment #34)
> Thank you for this very informative thread im also face this poblem.
> https://www.[gambling site].com/

Would someone please boot Matka420 off this Bugzilla for spamming us?

Removing CC for spammers. Not sure if it will help.

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
dpmatka.net

Hi there,this is really amazing post it also helps me a lot. Thank you for sharing.
 https://bit.ly/3cNl4ZX