I'm backing up servers on a backup server. Each server which is backed up has it's own account on the backup server, and the files are rsynced. It is important that the permissions remain intact (using rsync -p) to simplify restores.

I'm trying to create a script which can read the files and create some statistics. I don't like that script to be running under the root user, and it it also impossible to run it for every backup user, as the script should be able to read all files from all users. However, this creates a problem when a file is for example chmodded 600. I don't want to touch permissions, but another user except for root and the owner can't read it.

A specific - non root - user should be able to read all files in a directory or partition, regardless the permission levels (and the owner of the files should have no way to prevent it). Is there a way to achieve this? I'm running FreeBSD with a ZFS volume.


6 Answers 6


Use sudo.

If your sudoers file lists an exact and specific command then the command must be called exactly as listed in the sudoers or it will be denied.


backupuser  ALL=(root) /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

In this example the user backup can execute the command exactly as shown:

sudo /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

If they call sudo rsync... instead of sudo /usr/bin/rsync the command fails, or if the flags or paths are different the command fails.

If you're doing this in a script then you want to enable passwordless use of those commands:

backupuser  ALL=(root) NOPASSWD: /usr/bin/rsync -aH /files/to/backup/ /copy/of/backup/

For more see the sudoers(5) man page under Cmnd_list.

  • Great idea. I added the ls, cat, head, tail etc. commands to the sudoers file and can now execute them with root privileges and read all the files. Might not be the best solution for everyone, as the user is able to read all files on the system, but that is not a problem in my setup.
    – Evianon
    May 25, 2014 at 20:22
  • Well if you were using Solaris I would have suggested RBAC and pfexec. But since you're on BSD, sudo will have to do.
    – bahamat
    May 27, 2014 at 16:44

You could write a suid version of cat that is only executable by your backup user (make a group exclusive to the backup user and make the executable readable only by that group). This cat would only allow you to read files in the directory you're interested in. (You'd probably want to disallow symbolic links and watch out for tricks like /dir/../otherdir/.)

Then your script can use this executable to read files without having root privileges.


WARNING: As Stephane pointed out in the comments below, the owners of the files will still be able to revoke the ACL.

If you have root access to the machine, you could do this with ACLs:

setfacl -R -m u:USERNAME:r /path/to/direcory

This will give use USERNAME read access to all files and directories under /path/to/directory.

  • The owners of the files would still be able to remove those ACLs. May 23, 2014 at 15:19
  • @StephaneChazelas oh. Even if this was done by root? I didn't realize that. Do you know any way around it?
    – terdon
    May 23, 2014 at 15:21
  • No, on Linux I would have looked at a combination of Linux capabilities and LSM. On FreeBSD I have no idea. May 23, 2014 at 15:26

Bindfs is a FUSE filesystem that provides views of a directory tree with different permissions and ownership. There's no port for FreeBSD, but you can compile from source.

To give the user backupper (and only that user) a view of /some/files where all files are readable, mount a world-readable view of /some/files in a private directory of backupper.

mkdir -p ~backupper/spyglass/files
chown backupper ~backupper/spyglass
chmod 700 ~backupper/spyglass
bindfs -p a+rX-w /some/files ~backupper/spyglass/files

ZFS has some mechanisms for this.

One of the mechanisms is still in the works and not implemented yet, but allows a dataset to be mounted with an 'owner' override. In this case, you could clone a snapshot, mount it with the owner overridden to the backup user, back it up, then destroy the clone. the downside is that you don't backup the real ownership of the files.

The best solution is probably the ZFS nfsv4 style ACLs


I have two ideas for how to solve this problem using FreeBSD-specific technologies, though I haven't tried either:

  • Use Capsicum. This is my preferred method. Also, since it's recently been ported to Linux, it should work there too. It would go like this:

    1. Create a drop-cap-write command that drops CAP_WRITE then execs a command supplied on the command line
    2. Use sudo to allow the backup user to execute that command without a password
    3. Optionally, use sshd_config's ForceCommand directive to automatically execute that command whenever the backup user logs in. That way, the remote user wouldn't need to specify drop-cap-write in his backup script.
  • Use mandatory access control. This doesn't work on Linux AFAIK, and it's more awkward to setup. It would go like this:

    1. Create a backup-jail whose rootdir is /. Hard-code the jailid.
    2. run sshd in the backup jail. Allow root to login here, even if you don't allow root logins in the regular sshd
    3. Set ugidfw_enable="YES" in /etc/rc.conf
    4. Use a ugidfw rule that looks something like this:

    ugidfw add subject uid root jailid BACKUP_JAIL_ID mode rsx

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .