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

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.

  • You probably mean "used setfacl to make the whole directory (tree) /home readable by it". Feb 23, 2013 at 20:44
  • What sense does it make to give only read access but no execute access for a directory? Feb 23, 2013 at 20:49
  • @Laging, my original setfacl command was incorrect. You're right, it needs "rx" permission. I've edited the post.
    – emarti
    Feb 23, 2013 at 21:04

2 Answers 2


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


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.

  • Okay, so even though "ls -l" reads "-rw-r-x---+", the file is not group readable? I should believe getfacl's output "group::---"? Thanks, this clears things up.
    – emarti
    Feb 23, 2013 at 21:10
  • For more, see unix.stackexchange.com/questions/475698 .
    – JdeBP
    Oct 17, 2018 at 7:02
  • gosh, I wish they just left the base case permissions the way they were though with a + at the end, and show the extensions due to the facls when getfacl is called. This posix behavior (I think it is posix behavior) is way too complicated to have any use.
    – user314968
    Feb 5, 2019 at 21:26

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)?

  • This is not an ssh problem per se, it just happens to involve the ssh key. I had assumed that it was 'safer' to have an account with read-only access. In general I disable ssh access from root.
    – emarti
    Feb 23, 2013 at 21:06
  • 1
    @emarti You can even limit root to read-only access: mount --bind -o ro .... Mount the backup source read-only into the chroot environment for the backup process. Or use a LSM (Apparmor, SELinux, ...) to limit access even for a root process. Feb 23, 2013 at 21:19

You must log in to answer this question.

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