Remapping Users And Groups With Bind Mounts For Portable Data
Binding Home Directories for User Portability
Enabling user portability for home directories across systems requires remapping user and group identifiers to a consistent range with bind mounts. This allows the same UID and GID to access the same persistent home directory data when a user logs into different systems.
Understanding user and group identifiers
Every user account on Linux is assigned a numeric user identifier (UID) and every group is assigned a group identifier (GID). These numbers identify the user and group ownership of files and directories. Typically UIDs and GIDs are assigned consecutively starting from 1000 when new users and groups are created on a system.
The potential issue arises when users are created on different systems with different UIDs and GIDs. For example, a user jamie may have UID 1001 on one server and UID 2001 on another. Even if the user account is named jamie on both systems, the differing UIDs mean jamie’s home directory ownership and permissions will not transfer between these systems by default.
Introducing bind mounts
Bind mounts provide a way to map the same file or directory to alternative locations in the system’s directory tree. The key capability bind mounts provide for portable home directories is the ability to remap user and group ownership of the bind mounted directory.
For example, we can bind mount jamie’s home directory from the first system where jamie has UID/GID 1001 to the second system even though the jamie user now has UID/GID 2001 on that system. Using bind mount options, we can force the jamie UID/GID from the second system to apply to the bound home directory.
Remapping the user and group ID
Creating consistent UIDs/GIDs across systems allows seamless access to home directories via bind mounts. When a user is created, useradd and groupadd should be configured to use specific UID/GID ranges per user class to ensure consistency.
As an example, assume databases UIDs start from 5000, application accounts from 10000, admin accounts from 20000, and user accounts from 30000. This separates user classes while providing room for growth within the ranges.
With consistent UID/GIDs, bind mounted home directories will remap cleanly to the user accounts on other systems. Optionally, bindfs can also explicitly change ownership of content within the bound directories.
Creating a portable home directory
With properly established UIDs/GIDs, portable home directories can be created on network storage, external drives, or any location accessible as a mount point from the systems a user may log into.
Allowing logins via LDAP with centralized accounts, automated distribution of ssh keys, and configuring the target mount location for the home directory on each system is recommended for smoothest user experience.
Binding the home directory at login
The portable home directories can be automatically bound and unbound from the consistent mount point by leveraging PAM modules.
For example, pam_mount.conf can be configured to bind mount a user’s portable home directory based on their username or uid when they login. The unmount happens automatically on logout based on PAM session lifecycle. There are also options like forcing the mount into a separate private namespace which provides additional security.
Example bind mount configurations
Assuming we have an NFS server hosting user home directories available at /net/homes. And on our systems, local home directories are expected under /home by default. We want to replace the local /home with a bind mount to /net/homes.
The main commands to achieve this user directory bind mount would be:
# Bind mounting read/write with remapped ownership $ mount --bind /net/homes /home $ mount -o bind,remount,rw,user,lookup=uid # Alternative with explict ownership change $ sudo bindfs -u $UID:$GID /net/homes /home
Breaking this down:
- The first bind mount command links the network location to our local home directory namespace
- The remount options tell it to apply the real UID/GID lookups and ownership changes to the bound directory while also ensuring read/write permission
- Alternatively bindfs can explicitly change ownership to the current user at mount instead of the remount options
Securing the bind mount point
Since anyone with mount privileges can effectively take ownership of a bind mounted directory through the mount options, it’s important to lock down access.
Some key measures to enable:
- Restrict mount capabilities via namespaces or SELinux policies
- Make the backing file system hosting the home directories read-only mounted on the server if possible
- Limit processes/users that can establish bind mounts in /etc/fstab
- Monitor logs and system calls for unexpected mounting activity
Auditing mount operations and reviewing who is permitted to mount under what circumstances is generally a good practice for all environments.
Potential issues to watch out for
Despite bind mounts being relatively simple, some nuances need awareness to avoid issues:
- Multi-bind scenarios can get messy if not unmounted properly – can end up hiding previously mounted directories
- Automounts combined with fixed bind mounts to the same location will likely conflict
- Recursive bind mounting subdirectories can have unintended consequences – minimize depth
- Binding over existing data can make the underlying data inaccessible until unmount which risks data loss if unmount fails or is forgotten
Carefully testing bind mount setups before rollout is advised. And setting reminders to audit and confirm bound directories are as expected over time.
Alternative approaches for portable home directories
Bind mounts provide a filesystem-level approach to linking user directory content across systems. Other tools like rsync and redirection provide some additional options.
For example, using rsync jobs in systemd that copy freshly written content periodically. This can sync changes to a centralized directory, with a redirecting bind mount providing access during login sessions.
An automated flow might:
- User logs in, triggering a bind mount redirect to central home location
- Writes occur to the virtual bound directory, tracking changes
- rsync jobs duplicate changed data every few minutes back to the central store
- On logout the virtual view is unmounted after sync confirmed
This blend of redirection plus replication allows both a live consistent view plus aggregated change capture.
Other tools like OverlayFS and hard links provide additional approaches that may suit certain data portability needs as well.