ZFS snapshots are great for rolling backups. Say, we have
tank/home mounted at
/home. Then a simple
zfs snapshot tank/home@TIMESTAMP will give a backup accessible at
/home/.zfs/snapshot/TIMESTAMP. However, there is a problem when a user set too lax permissions on some file and corrects this error only after the snapshot has been made. The file will still be readable by the wrong people in the snapshot, and all the user can do is wait until the snapshot is destroyed (which happens via cron job as a part of the rolling backup scheme).
chmod go-rwx /home/.zfs/snapshot/TIMESTAMP/* would help, but snapshots are read-only. I came up with the following solution:
chmod o-rwx /home/.zfs/snapshot zfs snapshot tank/home@snap-TIMESTAMP zfs clone tank/home@snap-TIMESTAMP tank/clone-TIMESTAMP zfs set mountpoint=/root/tmp tank/clone-TIMESTAMP chmod go-rwx /root/tmp/* zfs set readonly=on tank/clone-TIMESTAMP zfs set mountpoint=/backup/TIMESTAMP tank/clone-TIMESTAMP
Now the backup can be accessed in a read-only manner by users at
/backup/TIMESTAMP, and it has the modified permissions.
At least one problem with this is that the permissions on
/home/.zfs/snapshot will be back to world-readable after a reboot. Can this behavior be changed? We cannot destroy the snapshot, since the clone depends on it.
A much simpler solution is, of course, to store the current permissions of the home directories, then run
chmod go-rwx /home/*, take the snapshot, and finally restore the permissions. This brings a number of race conditions, though.
Any better ideas?
Addendum: I have now settled for one dataset per user. So each user has her snapshots in
~/.zfs/snapshot. This is not a 100% solution. If a user has
0701 on her home directory, e.g., to make
~/public_html work, then still an attacker can read a file in a snapshot which had the wrong permissions at the time when the snapshot was taken. However, at least the user can now "pull the plug" in an emergency by making her home directory
Changing ownership and permissions of each
~/.zfs would be a better solution, but such changes do not survive a reboot. The appropriate chowns and chmods could be run at startup, but this needs to be implemented carefully in order not to create a short period in which files are still exposed.