Homedir gets not correctly created at first login

[mvdberge]

I'm opening this as a new issue, although my problems have already been started to be discussed at #325 which has been marked as "closed" before finding a solution for my specific problem.

Short summary here:

I built xrdp upstream version and have a problem when connecting to the server for the very first time with a user. The server should then create a homedir (via pam_mkhomedir). The server is a member of an active directory, PAM is configured to authenticate via samba/winbind and create home directories for users on their first login. This works perfectly for e.g. ssh or other services but not for xrdp.

I had a look at bugs #182 and #196 which seem similar but have a different background. The problem of these referenced bugs is that VNC needs some time to start up before connecting to it - so a timeout (loop) has been implemented. This is not the case here.

In this bug, VNC starts but there seems to be a problem with the order a full PAM based authentification. xrdp is supposed to first do the PAM authentication (which would initially creating a users' home directory) and then start VNC. This seems not to work as expected somehow... In general, the home directory gets created somewhen, but obviously too late in the process so that VNC spits out the error lines

[20160229-15:51:49] [ERROR] env_set_user: error creating .vnc dir
[20160229-15:51:49] [WARN ] can't write vnc password hash file - /home/DOMAIN/username/.vnc/sesman_username_passwd

If I kill the Xvnc process (or completely restart xrdp) and try it again (after the homedir got created while the first login try), it works. If I create the user's home directory manually it also works.

I wasn't able to let PAM create the homedir before VNC starts, I tried almost every possible order of "session" entries (especially those with pam_mkhomedir.so at the beginning).

[evanlinde]

I've got a setup just like what you describe that I managed to get working. I'm running CentOS 7 and I installed the xrdp package (version 0.9.0-4) from epel. Most of my trouble was from SELinux.

Here are the steps that I went through to get everything working:

chcon --type=bin_t /usr/sbin/xrdp
chcon --type=bin_t /usr/sbin/xrdp-sesman

Edit /etc/pam.d/xrdp-sesman, adding the following as the first account line:
account optional pam_oddjob_mkhomedir.so umask=0077

    systemctl enable xrdp
    systemctl start xrdp

Try logging in. It should fail creating the home directory because of SELinux. Create a SELinux policy module to allow this:

    cd ~
    grep oddjobd /var/log/audit/audit.log | audit2allow -M xrdp_mkhomedir
    semodule -i xrdp_mkhomedir.pp

Try logging in again. It will still fail. Now complete the SELinux policy module.

    grep oddjobd /var/log/audit/audit.log > xrdp_mkhomedir.txt
    cat xrdp_mkhomedir.txt | audit2allow -M xrdp_mkhomedir
    semodule -i xrdp_mkhomedir.pp

After this, xrdp worked as expected with home directories created at first login. And I did not have to adjust the delay_ms setting in xrdp.ini.

Here are the contents of xrdp_mkhomedir.te:

module xrdp_mkhomedir 1.0;

require {
        type unconfined_service_t;
        type oddjob_t;
        type oddjob_mkhomedir_exec_t;
        class process transition;
        class file entrypoint;
}

#============= oddjob_t ==============

#!!!! This avc is allowed in the current policy
allow oddjob_t unconfined_service_t:process transition;

#============= unconfined_service_t ==============
allow unconfined_service_t oddjob_mkhomedir_exec_t:file entrypoint;

[mvdberge]

I don't have SELinux installed, so this seems not to be my problem. Also, I can't solve my issue by tweaking the delay_ms setting - I already tried this out.
Still, thanks for sharing your insights!

[casmic]

I am having the same problem if if I am using xorgxrdp, but the problem is the same.
delay_ms indeed does not help, as it delays the activation of xrdp-sesman, while the problem looks like being in what sesman actually does.
It looks to me that pam_open_session() is called too late, after that sesman tried to fork a new Xorg (maybe Xvnc in your case). Usually it should not be a big issue, but if the home directory does not exists, it fails.

From xrdp-sesman.log

[20161021-16:10:22] [INFO ] ++ created session (access granted): username testuser, ip 0.0.0.0:49346 - socket: 12
[20161021-16:10:22] [INFO ] starting Xorg session...
[20161021-16:10:22] [DEBUG] Closed socket 13 (AF_INET6 :::5910)
[20161021-16:10:22] [DEBUG] Closed socket 13 (AF_INET6 :::6010)
[20161021-16:10:22] [DEBUG] Closed socket 13 (AF_INET6 :::6210)
[20161021-16:10:22] [DEBUG] Closed socket 10 (AF_INET6 ::1:3350)
[20161021-16:10:22] [DEBUG] Closed socket 9 (AF_INET6 ::1:3350)
[20161021-16:10:22] [INFO ] Xorg :10 -config xrdp/xorg.conf -noreset -ac -nolisten tcp -retro -depth 24  
[20161021-16:10:32] [ERROR] X server for display 10 startup timeout
[20161021-16:10:32] [INFO ] starting xrdp-sessvc - xpid=31899 - wmpid=31898
[20161021-16:10:32] [CORE ] error starting xrdp-sessvc - pid 31897 - xpid=31899 - wmpid=31898
[20161021-16:10:32] [DEBUG] errno: 2, description: No such file or directory
[20161021-16:10:32] [DEBUG] execve parameter list:
[20161021-16:10:32] [DEBUG]         argv[0] = /usr/local/sbin/xrdp-sessvc
[20161021-16:10:32] [DEBUG]         argv[1] = 31899
[20161021-16:10:32] [DEBUG]         argv[2] = 31898
[20161021-16:10:32] [DEBUG]         argv[3] = (null)
[20161021-16:10:32] [ERROR] X server for display 10 startup timeout

from auth.log:

Oct 21 16:10:22 test xrdp-sesman[31892]: pam_sss(xrdp-sesman:auth): authentication success; logname= uid=0 euid=0 tty=xrdp-sesman ruser= rhost= user=testuser
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_unix(xrdp-sesman:session): session opened for user testuser by (uid=0)
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_systemd(xrdp-sesman:session): Cannot create session: Already running in a session
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_mkhomedir(xrdp-sesman:session): conversation failed
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_mkhomedir(xrdp-sesman:session): Executing mkhomedir_helper.
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_mkhomedir(xrdp-sesman:session): mkhomedir_helper returned 0
Oct 21 16:10:32 test xrdp-sesman[31898]: pam_unix(xrdp-sesman:session): session closed for user testuser

so we have at 16:10:22 an Xorg session starting but the pam messages are 10 seconds later, as the timeout.

looking at sesman/session.c

 480     pid = g_fork(); /* parent is fork from tcp accept,
 481                        child forks X and wm, then becomes scp */
[...]
 530         wmpid = g_fork(); /* parent becomes X,
 531                              child forks wm, and waits, todo */
 532         if (wmpid == -1)
 533         {
 534         }
 535         else if (wmpid == 0)
 536         {

 537             wait_for_xserver(display);
 538             auth_start_session(data, display);
 539             pampid = g_fork(); /* parent waits, todo
 540                                   child becomes wm */

wait_for_xserver waits for the 10 seconds that we see in the logs for a Xserver which is not started and afterwards proceeds with auth_start_session, where the pam session actually happens.

Knowing almost nothing about both xrdp and pam, I quickly run a test building xrdp-sesman blindly moving auth_start_session(data, display); (538) above both forks (530 and 480) and, quite confusingly for me, it works in both cases.
Who knows what issues introduces though...

Unfortunately I did not find a workaround besides asking the users to re-login after the first time....

[tfischer77]

I can confirm this bug. I'm running xrdp in an environment where pam authenticates against ldap/kerberos. So I need to create home directories by pam_mkhomedir. I tried the exact same as you: moving the line auth_start_session(data, display); (538) directly before (530). Then the home directory gets created and X just starts normally. I'm also not a pam specialist, but I would assume that the right place to call "auth_start_session" is just before line 530. Maybe @jsorg71 or some other programmer could tell us that.
What confuses me a little bit: it is only happening with xorgxrdp. The old X11rdp was just working.
@jsorg71: Would it be ok to do a PR for that to make users with "pam_mkhomedir" happy?

[Natureshadow]

Just for the record - it's not only mkhomedir. ecryptfs and others come to mind.

+1 for the fix.

[Natureshadow]

Btw, did I mention we should really strive to decouple session management from xrdp, by e.g. connecting into LightDM some day ;)?

[ksteinb]

Could please somebody fix this, it is also a security issue, as pam_limits.so will not work too, so it is not possible to limit sessions!

[jsorg71]

I'll do a PR

[jsorg71]

I added #694

[setharnold]

Has a CVE already been assigned for this issue? Thanks

[ksteinb]

Am 15.03.2017 um 23:41 schrieb setharnold:

Has a CVE already been assigned for this issue? Thanks

No. Sincerly, Klaus

…

-- Rechnerbetriebsgruppe / IT, Fakultät für Physik Klaus Steinberger FAX: +49 89 28914280 Tel: +49 89 28914287

[setharnold]

Use CVE-2017-6967.
Thanks

[mirabilos]

JFYI, I’d prefer to not introduce a hard dependency on LightDM (or any login manager, really) as those tend to introduce tons of other dependencies, problems, etc. and make it much harder to just drop xrdp and xorgxrdp on a system and It Just Works.

[Natureshadow]

and make it much harder to just drop xrdp and xorgxrdp on a system and It Just Works.

Except it doesn't. We cannot have identical sessions for RDP and local logins at Teckids because sesman handling of PAM is incomplete and even crashes when enabling some PAM modules otherwise used in the desktop session. xrdp does not "just work" as long as it cannot run the same desktop session as local users.

[mirabilos]

Dominik George dixit:

We cannot have identical sessions for RDP and local logins

Precisely. I don’t want to be forced to have identical sessions. (Especially as things like which Xmodmap to load depend on whether it’s xrdp or not.) There’s also the “startx” and “xinit” type of sessions, so this issue already exists. I do understand there are situations in which people might want such identical sessions, and I’m not against supporting that, just not forcing it, by whatever means sensible (still not sure calling out to a login manager is right, fixing the PAM stuff might be more helpful).

and even crashes when enabling some PAM modules otherwise used in the desktop session

That’s probably related to #858143 and thus already fixed in experimental and xrdp upstream. (Invitation to try.) gn8, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…

[kkellner]

Since this is still a problem, is there any non-source code change workaround?

[holmesb]

Be good to get this fixed. My experience in Ubuntu 16.04 is that pam_mkhomedir creates a home dir upon xrdp login, but it's root-permissioned, so useless to the user in question (they just see a blue screen when trying to start an xrdp session). Permissioned fine during ssh login.

[evanlinde]

I believe I must have encountered the permission issue on Ubuntu 16.04. Here's what I have in my setup notes:

Edit /etc/pam.d/common-session, add " umask=0077 skel=/etc/skel" to the end of the line with pam_mkhomedir.so

[holmesb]

Yes evanlinde, umask=0077 fixes home dir ownership issue. Thanks.

[tksrc]

Same here. only works whenever I add the pam_mkhomedir line below.

XRDP was failing to create a home directory for my AD user on the first login.

` /etc/pam.d/xrdp-sesman

BEGIN ANSIBLE MANAGED BLOCK

session required pam_env.so readenv=1 user_readenv=0
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077

END ANSIBLE MANAGED BLOCK

@include common-auth
@include common-account
@include common-session
@include common-password
`

[hangingman]

Great, I'll try xrdp with VNC