Bug 1659623

Summary:	bash fails to source either ~/.bashrc or ~/.bash_profile on login for remote accounts
Product:	Red Hat Enterprise Linux 8	Reporter:	Doug Ledford <dledford>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED NOTABUG	QA Contact:	sssd-qe <sssd-qe>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	8.0	CC:	dledford, extras-orphan, extras-qa, grajaiya, jhrozek, lslebodn, mzidek, nalin, pbrezina, sbose, tmraz, tscherf
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1658290	Environment:
Last Closed:	2018-12-18 15:28:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1658290
Bug Blocks:

Description Doug Ledford 2018-12-14 20:18:57 UTC

+++ This bug was initially created as a clone of Bug #1658290 +++

Description of problem:

The bash environment for the user is not getting set properly

Version-Release number of selected component (if applicable):

bash-4.4.23-5.fc29.x86_64
pam-1.3.1-8.fc29.x86_64
freeipa-client-4.7.0-3.fc29.x86_64
systemd-239-6.git9f3aed1.fc29.x86_64
util-linux-2.32.1-1.fc29.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Create at least one local account, and join a freeeipa domain with separate freeipa based accounts
2. Use local home directories instead of automount maps for ipa user home dirs
3. Login to the local user account and the freeipa account from either a text terminal login or by creating gnome-terminals with the login shell option present
4. Local account will process ~/.bash_profile, ipa account will process all of the /etc/profile and /etc/bashrc contents, but will not process any user specific files
5. Login to the local account and the freeipa account with a non-login shell, local account will process ~/.bashrc but ipa account will not (and will have a mostly uninitialized shell with a prompt of "sh-2.4 $")

Actual results:

Shell does not process any home directory files on the ipa account, in spite of the fact that there is a local home directory and the files are present

Expected results:

Shell will process home directory bash files: .bashrc, .bash_profile, .bash_logout

Additional info:

I dumped this on pam_ldap because ldap logins are the only thing effected to my knowledge.  But, it could be some other part of the login process that's failing.  I don't really have a good trace (I don't know what options to enable where in order to debug this), but am willing to create one if you'll give me instructions on how to trace the login process to find the failure.

Comment 1 Doug Ledford 2018-12-14 20:20:29 UTC

Originally filed under Fedora 29, but the same issue exists in the rhel8 beta, so cloning here.

Issue prevents graphical users from being able to configure their environment if they happen to be a user via an ipa server.

Comment 2 Jakub Hrozek 2018-12-17 09:51:38 UTC

Do I understand it correctly that there is *the same* user (IOW, same UID, same username, same password) created in both /etc/passwd and IPA and the "user duplicate" is just a way to "prime" the system with the home directory?

Comment 3 Doug Ledford 2018-12-17 15:34:43 UTC

No, I was testing with two totally separate accounts.  One is a local user account (mainly intended for ansible logins), one is an IPA handled account (I'm using IPA for my home account services now, so this used to be a local account, but now it's an IPA account).  The local account is merely to show that bash sourcing of .bash_profile or .bashrc works.

The machine was joined to the IPA domain using the ipa-client-install.

The ipa user's home directory is local, not NFS mounted, and the ipa setup includes using oddjob to create home directories on first login (although in this case, the home directory had already been there as it's my personal home directory and I transferred it from the prior workstation to this workstation).

Comment 4 Jakub Hrozek 2018-12-17 19:03:20 UTC

(In reply to Doug Ledford from comment #3)
> No, I was testing with two totally separate accounts.  One is a local user
> account (mainly intended for ansible logins), one is an IPA handled account
> (I'm using IPA for my home account services now, so this used to be a local
> account, but now it's an IPA account).  The local account is merely to show
> that bash sourcing of .bash_profile or .bashrc works.
> 

OK, sorry, there was a similar bug report earlier where the reporter used local accounts to bootstrap the environment, so I guess I mixed up or confused the two.

> The machine was joined to the IPA domain using the ipa-client-install.
> 
> The ipa user's home directory is local, not NFS mounted, and the ipa setup
> includes using oddjob to create home directories on first login (although in
> this case, the home directory had already been there as it's my personal
> home directory and I transferred it from the prior workstation to this
> workstation).

Does calling 'getent passwd $user' show the expected home directory? Is the home directory owned by this user's UID and GID? I think journal + getent passwd $user and id $user are as good information as any to start the investigation..

Comment 5 Doug Ledford 2018-12-17 19:09:30 UTC

[dledford@haswell-e ~]$ getent passwd dledford
dledford:*:2217:2217:Doug Ledford:/home/dledford:/bin/sh

That's all correct.

[dledford@haswell-e ~]$ ls -ld .
drwx--x---+ 44 dledford dledford 4096 Dec 16 13:58 .


And just to double check the SELinux context:

[dledford@haswell-e ~]$ ls -ldZ .
drwx--x---+ 44 dledford dledford unconfined_u:object_r:user_home_dir_t:s0 4096 Dec 16 13:58 .

What journal info would you like?

Comment 6 Jakub Hrozek 2018-12-17 19:20:56 UTC

(In reply to Doug Ledford from comment #5)
> [dledford@haswell-e ~]$ getent passwd dledford
> dledford:*:2217:2217:Doug Ledford:/home/dledford:/bin/sh

So this and the actual PAM conversation are (more or less) whatever interfaces sssd has towards the system. So as far as sssd is concerned, so far I'm not sure what is wrong..
> 
> That's all correct.
> 
> [dledford@haswell-e ~]$ ls -ld .
> drwx--x---+ 44 dledford dledford 4096 Dec 16 13:58 .
> 
> 
> And just to double check the SELinux context:
> 
> [dledford@haswell-e ~]$ ls -ldZ .
> drwx--x---+ 44 dledford dledford unconfined_u:object_r:user_home_dir_t:s0
> 4096 Dec 16 13:58 .
> 
> What journal info would you like?

I'm not sure myself, is there anything suspicious if you just tail journal (journalctl -f) and log in as that user? Anything from pam_sss perhaps? If you log in as that user on the console, is your cwd in the expected homedir?

Comment 7 Doug Ledford 2018-12-17 19:36:41 UTC

Complete logs of a login on tty4, and I confirmed after login that my .bashrc/.bash_profile were not source (my PS1 was still set to the default instead of my git prompt PS1 I set in .bashrc):

Dec 17 14:28:23 haswell-e.nc.xsintricity.com login[19036]: pam_sss(login:auth): authentication success; logname=LOGIN uid=0 euid=0 tty=tty4 ruser= rhost= user=dledford
Dec 17 14:28:23 haswell-e.nc.xsintricity.com audit[19036]: USER_AUTH pid=19036 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_succeed_if,pam_sss acct="dledford" exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:23 haswell-e.nc.xsintricity.com audit[19036]: USER_ACCT pid=19036 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_sss,pam_permit acct="dledford" exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:23 haswell-e.nc.xsintricity.com audit[19036]: CRED_ACQ pid=19036 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="dledford" exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:23 haswell-e.nc.xsintricity.com audit[19036]: USER_ROLE_CHANGE pid=19036 uid=0 auid=2217 ses=16 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:24 haswell-e.nc.xsintricity.com systemd-logind[1196]: New session 16 of user dledford.
-- Subject: A new session 16 has been created for user dledford
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: https://www.freedesktop.org/wiki/Software/systemd/multiseat
-- 
-- A new session with the ID 16 has been created for the user dledford.
-- 
-- The leading process of the session is 19036.
Dec 17 14:28:24 haswell-e.nc.xsintricity.com systemd[1]: Started Session 16 of user dledford.
-- Subject: Unit session-16.scope has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit session-16.scope has finished starting up.
-- 
-- The start-up result is done.
Dec 17 14:28:24 haswell-e.nc.xsintricity.com login[19036]: pam_unix(login:session): session opened for user dledford by LOGIN(uid=0)
Dec 17 14:28:24 haswell-e.nc.xsintricity.com audit[19036]: USER_START pid=19036 uid=0 auid=2217 ses=16 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_sss,pam_umask,pam_lastlog acct="dledford" exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:24 haswell-e.nc.xsintricity.com audit[19036]: CRED_REFR pid=19036 uid=0 auid=2217 ses=16 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_localuser,pam_sss acct="dledford" exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:24 haswell-e.nc.xsintricity.com audit[19036]: USER_LOGIN pid=19036 uid=0 auid=2217 ses=16 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=2217 exe="/usr/bin/login" hostname=haswell-e.nc.xsintricity.com addr=? terminal=tty4 res=success'
Dec 17 14:28:24 haswell-e.nc.xsintricity.com login[19036]: LOGIN ON tty4 BY dledford

Comment 8 Doug Ledford 2018-12-17 19:38:28 UTC

Just as a test, I disabled SELinux.  Problem persisted.

Comment 9 Sumit Bose 2018-12-18 06:22:25 UTC

(In reply to Doug Ledford from comment #5)
> [dledford@haswell-e ~]$ getent passwd dledford
> dledford:*:2217:2217:Doug Ledford:/home/dledford:/bin/sh
> 

Is there any change if you replace '/bin/sh' with '/bin/bash' ?


> That's all correct.
> 
> [dledford@haswell-e ~]$ ls -ld .
> drwx--x---+ 44 dledford dledford 4096 Dec 16 13:58 .
> 
> 
> And just to double check the SELinux context:
> 
> [dledford@haswell-e ~]$ ls -ldZ .
> drwx--x---+ 44 dledford dledford unconfined_u:object_r:user_home_dir_t:s0
> 4096 Dec 16 13:58 .
> 
> What journal info would you like?

Comment 10 Doug Ledford 2018-12-18 15:28:13 UTC

Yep, that solved the problem.  I didn't know you had to specify the shell as bash for it to process .bash_profile and .bashrc.  I'll change the default shell on the ipa server and update the users.  Thanks!