rdiff-backup-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Rdiff-backup-bugs] [bug #21202] Crash : AssertionError: no ownership of


From: Marc Horowitz
Subject: [Rdiff-backup-bugs] [bug #21202] Crash : AssertionError: no ownership of ...
Date: Wed, 26 Dec 2007 07:05:32 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071204 Ubuntu/7.10 (gutsy) Firefox/2.0.0.11

Follow-up Comment #3, bug #21202 (project rdiff-backup):

I don't think your patch will do the right thing in my environment.  AFS is
weird.  It's possible to have a process which is authenticated to AFS in such
a way that the files it writes have a different uid than the process's uid. 
If you think of NFS's root/anon mapping, you'll get the right idea, although
the mechanism is different, and the process is not owned by root.  In
addition, AFS has directory acls which are more powerful that stat() can
represent, so they are invisible to stat().

In my situation, I have a rdiff-backup process running as uid X which is
writing files owned by uid Y.  This process will also be able to chmod the
files it creates.  If the file is mode 600, then the the new code will not
assert, but because dest_rp.readable() is false, get_one_sig will return None,
which I think will cause those files not to be backed up (this is inconvenient
for me to test).

In general, I think code which presumes filesystem semantics is always going
to be more fragile than simply performing the necessary operations, and
handling exceptions if they occur.
Taken to the logical extreme, this would argue for an even simpler method
body than in my original patch:

    try:
        return Rdiff.get_signature(dest_rp)
    except:
        # This branch can happen with root source and non-root
        # destination.  Permissions are changed permanently, which
        # should propogate to the diffs
        dest_rp.chmod(0400 | dest_rp.getperms())
        return Rdiff.get_signature(dest_rp)



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?21202>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]