bugrdiff-backup - Bugs: bug #19034, Fatal ListError when trying to...

 
 

bug #19034: Fatal ListError when trying to mirror / as a non-root user

Submitter:  Stephan Sokolow <ssokolow>
Submitted:  Mon 12 Feb 2007 05:30:33 AM UTC
Votes: 100
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 04 Mar 2007 09:03:02 PM UTC, comment #2: 

I see this as a bug for two reasons:

First, proper stdout/stderr separation, redirecting stdout to /dev/null, and using cron to run your backup will get you mailed error messages that only appear in the event of failures. (That's why rsync and traditional UNIX tools like cp work the way they do) I suspect this is where our difference of opinion primarily originates.

Second, I (and many other admins, I'm sure) would much rather see the backup succeed partially than fail in the following situations:

1. The backup depends on proper file permissions and there's a malicious user with enough access to change those permissions. (In my case, I run my backups as a non-root user for the same reason one would chroot an http daemon. Things like /etc/shadow get backed up separately.)

That works in two situations: First, if the user in question has ownership of (or group access to) everything non-public that's being backed up. Second, if the system is using something other than the standard UNIX file permissions. (eg. POSIX ACLs, SELinux security rules, etc.)

2. Something goes wrong (it doesn't matter what) and the admin is away. In this situation, total failure to make backups could lose the admin his/her job.

3. Permissions get mangled by impending drive failure. (I don't know if this is possible, but I doubt you want to risk the wrath of angry admins)

Also, how do I re-open a bug in Savannah? I only have experience doing so with Bugzilla.

Stephan Sokolow <ssokolow>
Tue 27 Feb 2007 05:19:38 AM UTC, comment #1: 

Rdiff-backup has the design choice of failing audibly (aka "crash and burn") when it cannot complete the backup that you have requested. Therefore, if it encounters a permission denied error it stops. Personally, I would rather know when a backup has failed, instead of having the program march on in silence.

Secondly, you'll need to run as root anyway if you want to backup your entire machine (not as user 'ssokolow').

If you believe there is still a bug here (adding -R is more of a feature request, for the wiki), please reopen it.

Thanks,
Andrew

Andrew Ferguson <owsla>
Group administrator
Mon 12 Feb 2007 05:30:33 AM UTC, original submission:  

It seems that unlike rsync, rdiff-backup 1.0.5 crashes and burns when it runs into a directory it cannot traverse. (When, not if. On a UNIX-like system, "Permission denied" should never be fatal to a tool that walks the filesystem.)

For example...
ssokolow@darkstar ~ $ rdiff-backup / /srv/backups/test/
ListError root [Errno 13] Permission denied
ssokolow@darkstar ~ $ rdiff-backup --exclude /root / /srv/backups/test/
ListError root [Errno 13] Permission denied
ssokolow@darkstar ~ $

Not only does this make me very suspicious (how trustworthy could a backup tool which such a simple problem be?), it absolutely prevents me from switching for the following reasons:

1. It could be 6 months before I have time to fix the problem myself and I'm not going to risk having a scheduled backup die because I increased the security on some random directory that is already in the --exclude-globbing-filelist.

2. My backup solution specifies that /srv/backups/<hostname>/ on the chosen backup machine must contain a from-the-root mirror of the given machine. On a related note, this is something that rsync makes trivial for backups that aren't started from the root via the -R option. rdiff-backup 1.0.5 seems to offer no such alternative so I can't even use it for portions of my backup tree.

Stephan Sokolow <ssokolow>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by owsla (Posted a comment)
  • -email is unavailable- added by ssokolow (Submitted the item)
  •  

    There are 100 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-03-04 ssokolow Carbon-Copy- Added ssokolow
    2007-02-27 owsla Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code