setfacl incorrectly changes group permissions

Question

To backup the "/home" directory tree of a server, I've created a 'backup' account and used setfacl to make the whole directory readable by it. My cron job runs this command as root each night:

setfacl -R -m u:backup:rx,d:u:backup:rx /home

Great, except for one problem: whenever I run this command, it changes the group permissions of my ssh key.

me@myserver:~/.ssh$ ls /home/me/.ssh/id_rsa -l
-rw-r-x---+ 1 me me 1679 Jan  8 18:35 /home/me/.ssh/id_rsa

Well, this causes my ssh program to barf because it is now group readable. Strangely, getfacl disagrees with the permissions.

me@myserver:~/.ssh$ getfacl /home/me/.ssh/id_rsa
getfacl: Removing leading '/' from absolute path names
# file: home/me/.ssh/id_rsa
# owner: me
# group: me
user::r--
user:backup:r-x
group::---
mask::r-x
other::---

getfacl thinks the file is not group readable. If I run the obvious command

chmod 400 id_rsa

the permission is fixed, but reverts every time I re-run the original command (setfacl -R -m u:backup:rx,d:u:backup:rx /home). What's going on?

Note: I do want my id_rsa to backup up, so let's not worry about those security implications.

Answer 1

If we have a look at the acl(5) man page, we see:

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

The permissions defined by ACLs are a superset of the permissions specified by the file permission bits.

There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permis‐ sions correspond to the permissions of the ACL_GROUP_OBJ entry. The other permissions correspond to the permissions of the ACL_OTHER_OBJ entry.

If you look at your getfacl output, you'll see that the mask is r-x, without which backup wouldn't have access to the file.

Actually, that r-x in the mode doesn't mean the me group has access to the file (it doesn't), just that someone else (user or group) may have access to it.

Still, for ssh it's the same, it's not good enough.

When you do the chmod 400, you clear the mask, which means the backup user no longer has access to it.

It's a bit confusing, but it's probably the best approach at conciliating the two permission mechanisms.

For your problem, you probably need to do your backup as root or use capabilities.

Answer 2

My ssh does not behave like that (openssh-6.0p1-2.3.3).

It would be interesting to see the output of strace for the ssh call, just the checks for the file.

I generally doubt that this is a good strategy. Why not use root for backups? Or at least give CAP_DAC_READ_SEARCH and CAP_DAC_OVERRIDE to the backup process (with setcap or Apparmor)?