On 11/14/11 20:54, Grant wrote: >> >> If you're intent on making a two-stage pull work; you can do it by >> creating a 'backups' user on your servers, and then using filesystem >> ACLs to grant backups+r to every file/directory you want to back up. >> That way, an attacker on the backup server can't decide to peruse the >> rest of your stuff. > > I like that. So use ACLs to grant access to the backups instead of > using ownership/permissions so that the ownership/permissions stay > intact. I've never used ACLs. Do they "override" > ownership/permissions? In other words, if the ACL specifies backups+r > to a file owned by root that is chmod 700, "backups" can read it > anyway?
Yup, they work like Windows ACLs if you've used those. You can grant one user read permission without affecting anything else. The '700' mode doesn't really make sense anymore after you apply an ACL.. the whole permissions-as-bits concept gets highly convoluted[1] but if you just want to add read access for one user it's easy. You can use setfacl to add permissions, and double-check with getfacl that they do what you think they do. The examples in `man setfacl` are pretty easy to understand. >> The easiest method, though, is to just add a third stage. Either move >> the backups on the backup server to another directory after the backup >> job completes, or sync/burn/whatever them off-site. In this case the >> backup server can't access anything you don't give it, and the >> individual servers can't trash their backed-up data. > > I don't see how that could work in an automated fashion. Could you > give me an example? We do push backups to one server, backup1, every night. Then, every day, backup1 syncs to another server, backup2. The individuals servers have no access to backup2, and it's physically separate from backup1. I make physical, removable, backups of backup2 every once in a while, but not as often as I should. [1] http://www.suse.de/~agruen/acl/linux-acls/online/
