I may have missed something, or maybe someone else has suggested this already, but why not pull instead of push?
ie, from the machine that is the backup, connect to the master server and rsync that way - this will mean that anything that's world readable but only writable by root wont be a problem (you can write locally, and read with a normal user) - anything that's readable only by root, well, you'd need root to back it up, I don't think you can escape that. On Fri, Feb 12, 2010 at 7:29 PM, James Gray <ja...@gray.net.au> wrote: > > On 12/02/2010, at 4:18 PM, Daniel Pittman wrote: > > > James Gray <ja...@gray.net.au> writes: > > > >> I've googled this one for a while and can't find any examples of people > >> doing *system* file sync with rsync. So I thought I'd throw it out to > the > >> collective wisdom of SLUG. Here's the full story. > >> > >> We have a SuSE-based production application/DB server pair and a > >> corresponding pair in a disaster recovery location (offsite, bandwidth > >> consumption needs to be minimised). We need to sync a number of files > >> between these servers and some require elevated (root) privileges at > *both* > >> ends. Here lies the problem; we don't allow remote root logins (via SSH > or > >> any other method either...sudo, console or nadda). > >> > >> I want to use rsync because of it's ability to transfer > >> differential/incremental changes and thus bandwidth friendly, however > any > >> other tool would be fine too. However, due to the inability for root to > >> login directly, how the heck do I synchronise particular files in > privileged > >> locations (like /etc/shadow)? > > > > ...if you allow this tool to write to /etc/shadow[1], just allow root > logins: > > you have added *nothing* by forbidding them. Why? An attacker with > access to > > the rsync tool can add an additional root user with a known password > anyhow, > > so additional "security" doesn't actually change the problem space at > all. > > I'm not going to get into the "allow root, or not to" holy war. This is a > big multi-billion dollar company and the "security team" have decreed no > direct root logins. End of story, it's not an option. Whether I agree with > them or not is irrelevant, it's just not an acceptable solution in the > environment I work. > > >> I can start whatever services I need at either end (like an rsync > server) > >> but the main thing is all files maintain the same owner/group/mode at > each > >> end. > >> > >> Ideas? > > > > Just use root, if you want to go down this path. > > See above. > > > Alternately, I would suggest using something like puppet which is > designed to > > do system management like this in an automated fashion; it is a > completely > > different approach, but one that will probably solve your underlying > problem > > without needing to change your security model so much. > > I've used bconfig before and was moving towards puppet when that employer > decided to commit corporate suicide and ended my tenure (along with everyone > else's!) before really getting stuck into it. This will probably be the > long-term solution but for now we simply need something to make the auditors > go away with happy thoughts. > > > [1] ...and, by implication, /etc/passwd, since the later isn't much use > > without the former being updated too. > > Yep - we also need to sync /etc/group and a bunch of other > application-specific fru-fru like CIFS passwords for /etc/fstab that are > store root-readable (and no-one else) files too. The reason for > highlighting /etc/shadow is that, unlike its /etc/passwd counterpart, is > only root-readable ;) This is why using privileged accounts at both ends is > necessary. > > Thanks for the input. > > Cheers, > > James > > > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
