/unsw

From techdocs
Revision as of 11:47, 28 August 2023 by Plinich (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
To do
Consider replacing the CIFS protocol with SMB3 (see autofs_unsw.sh)

The /unsw top-level directory on all user-loginable New World hosts is a file system mount point managed by the autofs automounter.

When a user tries to access /unsw/zID, where zID is that same user's own UNSW zID, the automounter will attempt to mount that user's UNSW home folder (not CSE home directory) at that location[1]. This gives the user transparent read/write access to their UNSW home folder from CSE hosts via the /unsw/zID path.

Caveat: The user's Kerberos credentials need to be available on the CSE host for the mount to succeed. These credentials are automatically generated when the user logs using their zID via a VLAB GUI interface or on the console of a physical lab computer. If the user logs in via SSH, they'll instead need to set up their Kerberos credentials manually by running kinit zID in a terminal window and providing their UNSW zPass as password.

If the user attempts to access the /unsw/zID path without their Kerberos credential being available, the mount will fail and the user will need to wait for a timeout (how long?) to expire before they can try again (after, presumably, setting up their credentials).

Operational notes

  1. The /unsw mount point is created by the automounter from a specification in /etc/auto.master.
  2. The same specification tells the automounter it can get details of what/how to mount the user's home folder by running /usr/local/infrastructure/bin/autofs_unsw.sh with a single parameter -- effectively the user's zID[2].
  3. autofs_unsw.sh queries UNSW's Active Directory to get the UNC location[3] of the user's home folder.
  4. It also queries CSE's systems to get the user's UID and GID which are passed to the kernel so as to set file/directory permissions and ownerships to limit access to the home folder to the mount-requesting user only[4].
  5. The kernel needs to pass the user's Kerberos credentials to the home folder server when it requests the mount. It gets these from user space via the Linux request-key mechanism, specifically via the cifs.upcall binary. But because the credentials cache set up by PAM's pam_krb5.so on user login uses an unpredictable naming scheme[5] that cifs.upcall is not smart enough to search for on its own, a bash shim, cifs_upcall_shim.sh is inserted into request-key's /etc/request-key.d/cifs-spnego.conf file so the shim gets run instead of cifs.upcall. The shim then finds a suitable credential cache and THEN invokes cifs.upcall to finish off.

Important files

  • /etc/auto.master
  • /etc/request-key.d/cifs-spnego.conf
  • /usr/sbin/cifs.upcall
  • /usr/local/infrastructure/bin/autofs_unsw.sh
  • /usr/local/infrastructure/bin/cifs_upcall_shim.sh

Footnotes

  1. ↑ This will not be an NFS mount with Linux file system sematics. It will instead be a CIFS mount due to the UNSW home folder servers all being Windows-compatible servers with NTFS file systems.
  2. ↑ Can be run by root for testing with no unfortunate side effects.
  3. ↑ Server and path… with backslashes, by the way.
  4. ↑ This is a bit superfluous as the mount is performed using the user's Kerberos credential and thus access is limited at the server end by whatever permissions that user has there. However, setting permissions at the CSE-host end allows the CSE host to perform initial access control, and it means that ls -l shows something meaningful.
  5. ↑ /tmp/krb5cc_<UID>_<six-random-letters-or-numbers>
Retrieved from ‘https://techdocs.cseunsw.tech/mediawiki/index.php?title=/unsw&oldid=874’