Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
You probably mean "used setfacl to make the whole directory (tree) /home readable by it". –  Hauke Laging Feb 23 '13 at 20:44
    
What sense does it make to give only read access but no execute access for a directory? –  Hauke Laging Feb 23 '13 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 '13 at 21:04

2 Answers 2

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.

share|improve this answer
    
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 '13 at 21:10

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

share|improve this answer
    
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 '13 at 21:06
    
@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. –  Hauke Laging Feb 23 '13 at 21:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.