Re: [rdiff-backup-users] HFS+ Resource Fork Patch

[Ben Escoto]

>>>>> "akb" == Andrew K Bressen <address@hidden>
>>>>> wrote the following on Wed, 16 Jul 2003 04:11:05 -0400

  >> not changed at all.  For this reason I think we'll move away from
  >> the current extended attribute system and compare files by ctime.
  >> This will be more complicated though.

  akb> Can there be a way to force a full compare? If some cracker
  akb> messes up ctimes in order to cover their tracks, unwinding
  akb> could really suck; I'd like to know when the files actually
  akb> changed, not when the filesystem thinks they changed...

Well the plan was just to add ctime to the current list of things
compared (basically what you could get from an lstat call:  mtime,
file type, file size for regular files, etc.).

Currently rdiff-backup does not use ctime at all.  It was like this
for historical reasons, because ctime cannot usually be set by the
user, so created destination files would always look different from
the source files.  Now that metadata is stored separately, the
original ctime can be preserved.

The full compare issue seems to be orthogonal.  Right now rdiff-backup
wouldn't notice if someone updated a file's regular data without
affecting its lstat() information, so the prospect of an attacker
being able to do this to a file's extended attributes as well doesn't
seem too worrying in comparison.

  akb> I don't suppose transmitting a hash would address the "don't
  akb> want to resend the whole rsrc fork" issue?

A full compare option (for both regular data and EAs/ACLs) might be
useful in some cases (although probably quite slow---all the contents
of the directory would have to be read from disk).  Then sending
md5/sha1 hashes seems like the reasonable thing to do.

There were also some more good ideas in your message at
http://mail.gnu.org/archive/html/rdiff-backup-users/2003-06/msg00050.html
that I haven't really thought about yet.  My main goal for 0.13.0 is
to get EAs/ACLs somewhat working.


-- 
Ben Escoto

pgpiH_yNZgrqL.pgp
Description: PGP signature