/etc/auto.smb is a script used by autofs to make Windows file servers
accessible to the automounter. The script basically works by by parsing the
output of 'smbclient -L SERVER'. My workplace has a fairly vanilla FreeIPA
setup with a one-way trust to an Active Directory domain, and in order for
smbclient to be able to list a file server's shares, it has to be able to
access the Kerberos ticket cache of the user who requested the mount in order
to authenticate to the file servers.
This isn't easy, because the script is launched by autofs, so it doesn't really
know anything about the user other than its UID and name. The standard script
just checks in some standard hardcoded locations:
DIR:/run/user/$AUTOFS_UID/krb5_cc_* and /tmp/krb5cc_$AUTOFS_UID; there's no
support for other locations, or any of the more interesting credential cache
types.
I discovered that SSSD has a 'ccacheFile' attribute that points to the location
of the user's Kerberos ticket cache. After adding '+ccacheFile' to
[ifp]user_attributes in sssd.conf and restarting sssd, the following patch to
/etc/auto.smb got things working.
The patch is pretty straightforward, it just retrieves the ccacheFile attribute
via the sssd infopipe API:
--- /usr/share/autofs/conffiles/auto.smb 2020-01-15 22:04:23.000000000
+0000
+++ /etc/auto.smb 2020-06-28 19:07:01.941702373 +0100
@@ -24,7 +24,19 @@
get_krb5_cache() {
cache=
- uid=${UID}
+ uid=${AUTOFS_UID}
+ # This requires busctl, jq, sssd's infopipe responder, and for sssd.conf
to contain [ifp]user_attributes = +ccacheFile
+ # ... maybe we should just su to the user to run smbclient?
+ if [[ -x /usr/bin/busctl ]] && [[ -x /usr/bin/jq ]]; then
+ _user_obj=$(busctl -j call org.freedesktop.sssd.infopipe
/org/freedesktop/sssd/infopipe/Users org.freedesktop.sssd.infopipe.Users
FindByID u "$uid" | jq -r '.data[0]')
+ if [[ -n $_user_obj ]]; then
+ cache=$(busctl -j get-property org.freedesktop.sssd.infopipe
"$_user_obj" org.freedesktop.sssd.infopipe.Users.User extraAttributes | jq -r
'.data.ccacheFile[0]')
+ if [[ -n $cache ]]; then
+ return
+ fi
+ fi
+ fi
for x in $(ls -d /run/user/$uid/krb5cc_* 2>/dev/null); do
if [ -d "$x" ] && klist -s DIR:"$x"; then
cache=DIR:$x
So, I come to this list to find out whether this is a good idea or not: is this
attribute an implementation detail, or something that a client of sssd can rely
upon? If not, would you consider making it stable, or provide another mechanism
to retrieve a user's Kerberos credential cache location--or else propose
another mechanism (e.g., I suppose the script _could_ use runuser, su or sudo,
etc., to run smbclient as the requesting user, which would automatically pick
up KRB5CCNAME via pam_sssd.so)... would that be a better way to do this?
(It appears that the cifs code within the kernel itself has a similar problem;
it is able to find a user's Kerberos credentials by use of cifs.upcall(8),
which peeks into the environment of the process that caused a key to be
requested, and uses the value of KRB5CCNAME that it finds there. autofs can't
do something similar because the kernels doesn't make the PID of the requesting
process available to it.)
BTW, I might have run into a bug while figuring out the above. I noticed that
changes to [libdefaults]default_ccache_name in krb5.conf weren't taking effect
even after a reboot! It turns out that pam_sss.so sets KRB5CCNAME during login
to the value from its cache, rather than from krb5.conf. I ended up using
ldbedit to remove the ccacheFile attribute from my user record and logging in
again, whereupon the attribute was added again with the new expected value.
--
Sam Morris <https://robots.org.uk>
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
