Score:1

Logins like [email protected] cause profile files to be owned by root

eg flag

The users at my school are used to logging in to email, windows etc with a login [email protected] (authenticated with Active Directory via LDAP). Unfortunately this is causing havoc and corrupting their user profile.

UPDATE - CAUSE: This was caused by some custom modifications in our setup that I didn't know about and were before my time. Was a bit difficult for me to find.

Custom code was in: /etc/pam.d/common-auth Which ran a script that executed chown -R ${PAM_USER}. ${HOME_DIR}. When users logged in as [email protected] this becomes chown -R [email protected]. ${HOME_DIR}.

Problem login: username@xyz

New user logs in as [email protected]. LDAP authenticates with AD and accepts the login. System attempts to create new user profile in /home.. however the system fails somewhere and the new profile is owned by root.

Working login: username

If the user logs in the first time as just username then all is well. LDAP authenticated with AD, account is created and has correct owner.

System:

  • OS: KUbuntu 22.04 LTS. Error occurs on KUbuntu 20.04 LTS also
  • Authentication: LDAP (via SSSD)

How to attack this problem?

  • Can sddm or sssd filter out everything after "@..." ?
  • Which process actually copies /etc/skel then does chown ?
  • How to debug ?

Log Files

auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_unix(sddm:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  [email protected]
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_sss(sddm:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= [email protected]
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_succeed_if(sddm:auth): requirement "uid >= 1000000" was met by user "[email protected]"                                                        
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_exec(sddm:auth): Calling /bin/bash ...                                                         
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: gkr-pam: unable to locate daemon control file                                                           
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: gkr-pam: stashed password to try later in open session                                       
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:auth): pam_kwallet5: pam_sm_authenticate                                                                                               
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred                                  
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_unix(sddm:session): session opened for user [email protected](uid=15371234) by (uid=0)                                                         
auth.log.1:Jul 26 15:26:43 linux042 systemd-logind[1177]: New session 3 of user u5371234.                                                                                                                  
auth.log.1:Jul 26 15:26:43 linux042 systemd: pam_unix(systemd-user:session): session opened for user u5371234(uid=15371234) by (uid=0)                                               
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_unix(sddm-greeter:session): session closed for user sddm                                                                                              
auth.log.1:Jul 26 15:26:43 linux042 systemd-logind[1177]: Session 1 logged out. Waiting for processes to exit.             
auth.log.1:Jul 26 15:26:43 linux042 systemd-logind[1177]: Removed session 1.                                                                                                                               
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session                                                                                            
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: Couldn't create salt file                       
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: Couldn't read salt file                                                                                        
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: Fail into creating the hash
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_unix(sddm:session): session closed for user [email protected]                                                                                  
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_close_session                                                                                            
auth.log.1:Jul 26 15:26:43 linux042 sddm-helper: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
auth.log.1:Jul 26 15:26:43 linux042 systemd-logind[1177]: Session 3 logged out. Waiting for processes to exit.                                                                                             

daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Starting SSSD PAM Service responder private socket...
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Starting SSSD PAM Service responder socket...                                                                                                            
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Starting SSSD PAC Service responder... 
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1525]: [sssd] [main] (0x0070): Misconfiguration found for the pam responder.                                                  
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1525]: The pam responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sss
d/sssd.conf.                                                                                                                                                                                               
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1525]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the pam's socket by calling:
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1525]: "systemctl disable sssd-pam.socket"                                                                                    
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: sssd-pam-priv.socket: Control process exited, code=exited, status=17/n/a
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: sssd-pam-priv.socket: Failed with result 'exit-code'.                                                                                                    
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Failed to listen on SSSD PAM Service responder private socket.           
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Dependency failed for SSSD PAM Service responder socket.                                                                                                 
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.              
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1526]: [sssd] [main] (0x0070): Misconfiguration found for the pam responder.
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1526]: The pam responder has been configured to be socket-activated but it's still mentioned in the services' line in /etc/sss
d/sssd.conf.                                                                       
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1526]: Please, consider either adjusting your services' line in /etc/sssd/sssd.conf or disabling the pam's socket by calling:
daemon.log.1:Jul 26 15:26:43 linux042 sssd_check_socket_activated_responders[1526]: "systemctl disable sssd-pam.socket"
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Started SSSD PAC Service responder.
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: sssd-pam.socket: Control process exited, code=exited, status=17/n/a
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: sssd-pam.socket: Failed with result 'exit-code'.
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Closed SSSD PAM Service responder socket.
daemon.log.1:Jul 26 15:26:43 linux042 sssd_pac[1528]: Starting up
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Created slice User Slice of UID 15371234.
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Starting User Runtime Directory /run/user/15371234...
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Finished User Runtime Directory /run/user/15371234.
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1]: Starting User Manager for UID 15371234...
daemon.log.1:Jul 26 15:26:43 linux042 systemd[1546]: Failed to open configuration file '/home/u5371234/.config/systemd/user.conf': Permission denied
Raffa avatar
jp flag
You’re welcome … I apparently misinterpreted your question as a home directory creation issue while it is indeed an authentication and permissions related issue … Please, post the update part in your question as an answer and accept it to help future readers … Well done!
Score:1
eg flag

CAUSE:

The problem was on our end, not Ubuntu's. This was caused by some custom modifications in our setup that I didn't know about and were made before my time. Was a bit difficult for me to find.

Custom code was in: /etc/pam.d/common-auth, which then ran a script that executed chown -R ${PAM_USER}. ${HOME_DIR}. When users logged in as [email protected] this becomes chown -R [email protected]. ${HOME_DIR}. The chown command fails and user profile permissions are broken.

FIX:

Trimming everything after the "@" for the variable PAM_USER fixed the account creation process.

### Trim PAM_USER: :: [email protected] -> zid
#   Students are logging in as [email protected] which breaks chown below -> then breaks KDE login
PAM_USER=${PAM_USER%@*}
# ... this fixes: chown -R ${PAM_USER}. ${HOME_DIR}

Trim code based on: https://stackoverflow.com/questions/4168371

Raffa avatar
jp flag
Might be worth noting that the usage of a dot `.` as a `user:group` delimiter in the `chown` command is not advised ... it's very old and not portable and kept only for backward compatibility reasons ... Use a colon `:` instead.
Bastion avatar
eg flag
Thanks Raffa! Honestly it's the first time I've seen anyone use that delimiter with chown
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.