| 1 |
>>Then I could have the backup server pull |
| 2 |
>> that copy from each system without giving it root access to each |
| 3 |
>> system. Can I somehow have the correct ownerships for the backup |
| 4 |
>> saved in a separate file for use during a restore? |
| 5 |
>> |
| 6 |
> |
| 7 |
> If you're intent on making a two-stage pull work; you can do it by |
| 8 |
> creating a 'backups' user on your servers, and then using filesystem |
| 9 |
> ACLs to grant backups+r to every file/directory you want to back up. |
| 10 |
> That way, an attacker on the backup server can't decide to peruse the |
| 11 |
> rest of your stuff. |
| 12 |
|
| 13 |
I like that. So use ACLs to grant access to the backups instead of |
| 14 |
using ownership/permissions so that the ownership/permissions stay |
| 15 |
intact. I've never used ACLs. Do they "override" |
| 16 |
ownership/permissions? In other words, if the ACL specifies backups+r |
| 17 |
to a file owned by root that is chmod 700, "backups" can read it |
| 18 |
anyway? |
| 19 |
|
| 20 |
> The easiest method, though, is to just add a third stage. Either move |
| 21 |
> the backups on the backup server to another directory after the backup |
| 22 |
> job completes, or sync/burn/whatever them off-site. In this case the |
| 23 |
> backup server can't access anything you don't give it, and the |
| 24 |
> individual servers can't trash their backed-up data. |
| 25 |
|
| 26 |
I don't see how that could work in an automated fashion. Could you |
| 27 |
give me an example? |
| 28 |
|
| 29 |
- Grant |
Archives