This bug could be considered an AFS variant of bug 4301. When AFS is in use, and the home directory is on AFS, one needs to logon to AFS early in the login process. It has been reported that adding "afslog" to /opt/thinlinc/etc/xstartup.d/01-tl-kinit.sh works. However, as an alternative, one alternative solution could be to let thinlinc-login check the KRB5CCNAME created by the SSH login, and then store/pass this information, so that this ticket can be used.
Åke Sandgren reports that to create a PAG he had to modify tl-xinit somewhat. This is the code that he submitted as the "new" tl-xinit, with the old file moved to tl-xinit.orig. ---- #!/bin/sh uid=`id -u` tkt=`find /tmp -user $USER -name krb5cc_$uid_\* | xargs ls -lart | tail -n 1 | awk '{print $NF}'` if [ -f $tkt ]; then mv $tkt $TLSESSIONDATA/krb5cc exec pagsh env KRB5CCNAME=$TLSESSIONDATA/krb5cc /opt/thinlinc/libexec/tl-xinit.orig "$@" else exec /opt/thinlinc/libexec/tl-xinit.orig "$@" fi ---- However it's worth to note that this will only work for ThinLinc systems where there is only one machine hosting both vsmserver and vsmagent because of how the session is started. Bug 4712 is relevant for this problem.
More info from Åke (translated from Swedish): > The PAG can be created without a Kerberos ticket, but you should(/must) set > KRB5CCNAME to a well-known name so you can pass the Kerberos ticket to it > before you run afslog.
Created attachment 592 [details] tl-kinit script by Åke Sandgren
Created attachment 593 [details] tl-xinit script by Åke Sandgren
Created attachment 600 [details] Updated tl-kinit to solve timing problem
The problem is equally valid for any home directory that requires a valid Kerberos ticket. So NFS also has this issue. This issue is now more visible in ThinLinc 4.10.0 as we have more error handling for startup issues. The session will now fail to start if there are issues with the home directory. Previously you would "just" get weird behaviours (e.g. .bashrc would not be loaded). Also see bug 4712 which might be one way of solving this issue.
(In reply to comment #9) > > Also see bug 4712 which might be one way of solving this issue. Probably not enough. Users might have Kerberos protected NFS home directories even if they are using passwords to access the system. E.g. a SSH login would work fine in such cases. Bug 4712 would be needed for a Kerberos authentication though.
We discussed some ideas for solving this. The key principle is that we need to get a ticket much earlier in the process, the question is just when and how. a) Get the ticket in tl-session. This is the "safest" approach in that it mimics what happens in a local login. However it has very little flexibility as tl-session is privileged and runs very early. As to how this would work, we see two obvious ways: 1. Start doing PAM authentication in tl-session, and not just PAM sessions. This is messy though as PAM might be more interactive than just a simple password. E.g. OTP or password changes. This also aggravates the issues we have with multiple authentications, where we'd ideally like to have just one. 2. Explicitly do Kerberos authentication. Basically re-implement what pam_krb5.so does in tl-session. This makes things more specific to just Kerberos and should hopefully avoid side effects. No bonus effects from this though and it is uncertain how much configuration options users would need. b) Get the ticket just before the login shell. At this point we're running as the user, so we have a lot more flexibility to do stuff that would be dangerous in tl-session, and we have the X server running if we want to be interactive with the user. The downside is that we aren't as sure we're truly running before anything that might touch the home directory. E.g. systemd can start things when the PAM session opens, and doing advanced stuff like GUIs might trigger things that read the home directory. As to how: 1. tl-xinit could run a script, or all scripts in a new directory similar to xstartup.d before it runs xsession. This would give us a general mechanism for "early" stuff. Via this mechanism we could run kinit, or even pop up a prompt and wait for the client to connect and show the user a GUI. 2. We could move the login shell invocation to xsession, and have it do the above before it runs the shell. We already have some environment setup in xsession that could fit in this new mechanism. Kerberos also supports smart card authentication which complicates things further. With the current system we don't have access to the card until the client connects, which would mean something along solution b). If we want solution a) then some new smart card mechanism would be needed.
Another problem is that the working directory for the session ends up being the session directory instead of the home directory since tl-xinit fails to change it: > tl-xinit: unable to change working directory: Permission denied
