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.

Table of Contents

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.