strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

[Lenny Foner]

    Date: Mon, 8 Jul 2002 21:18:18 +0800
    From: Adrian Ho <aho-sw-rsync at 03s.net>

    If the sender's/receiver's cwd is guaranteed to be the root of the
    corresponding rsync'd hierarchies, then yes, relative paths would
    suffice.

    > <example>
    > UPDATE	foo/
    > CREATE	foo/bar1
    > UPDATE	foo/oldie
    > DELETE	foo/gonzo
    > HLINK	foo/gorgon
    > SLINK	foo/plank
    > SPECIAL	foo/sock1
    > </example>

    I like the format.

I don't, unless pathnames with newlines in them are already explicitly
disallowed.  Otherwise, things become ambiguous.

If the format was just a list of pathnames, they could be
null-terminated, and the -0 arg to xargs could be used, as is
recommended when handling general lists of filenames.  (After all,
under Unix at least, no filename may contain a null, whereas it -is-
legal, though hardly recommended, for a filename to contain a
newline.)  However, doing this makes handling the keywords (e.g.,
using grep on them) much trickier.

It also means that every script that has to handle a particular kind
of file (updated, deleted, etc) has to prefilter its input.  OTOH,
this might be a better approach than having a separate command-line
arg for each type of file and every phase, e.g., you'd have to have
post-send-deleted=, post-recv-updated, etc etc, leading to a large
number of additional options.  (The additional options also make it
slightly harder to have a single logfile that accumulates them all,
but easier to have a logfile that accumulates only one type.)

I'm not sure which way people think about either the null issue or the
script-filtering-vs-extra-command-line-args issue, but I figured I'd
point them out.

Similarly, when --files-from= is finally implemented, it will also
have to decide whether the names are newline-terminated or null-terminated.
If the former, then the documentation will have to explicitly say that
there are just some pathnames that it won't be able to handle, and why.

And no, I myself have no pathnames like that, but I believe in being
defensive about such things when I can be.  It's a pity that Unix
semantics wrt naming and termination interact to make this so inconvenient.

Given all this, I think a cleaner solution would be something like a
spiffier version of --log-format.  My suggested format directives
borrow from the feel of recent versions of "date", and might look like
the below.  (And I'm -not- wedded to the specifics of the syntax &
letters here---in fact, I think my example syntax is awful.)

  %  starts a directive
  0  prepended to any directive, it null-terminates the resulting string
  @  ("action") takes a subdirective, and applies to the relevant action:
     D  delete
     C  create
     U  update
     etc
  P  the pathname (maybe P = absolute & p = relative?)
  ?  ?what other options do we want here?

and...

  %( %) grouping (see below)

Thus, if you said (oh ugh):
  --log-format="%@D%(DELETED\t%P\r%)%@0C%(I made one!-->P\r%)"
you might see this in your log:
  DELETED	/foo/bar
  DELETED	/blah/biff
  I made one!-->/etc/splat 
and no lines at all for updates or any other actions.

Yes, it's stupid to have some lines null-terminated and some
null-and-newline terminated; I'm just doing this as an example.

And maybe it's better to have a multiplicity of options than the
awful fake-conditional syntax I introduced above.  It'd certainly
be more readable.

(Where I'm going with this is something like Common Lisp's FORMAT
function, which parses a string a la printf, but where the string can
have embedded conditionals and is its own little language.  While I
hate inventing little languages and hate other applications forcing me
to learn theirs, there -is- a benefit here, namely that we might be
able to define something general enough that it would help most of the
people who need something like that.)

If there were some mechanism to put different --log-format results in
different places, it would be nice if multiple --log-format
occurrences would all be allowed, but then the syntax might be even
uglier:

  --log-format="%@0DP"=/tmp/deleted-files --log-format="%@0UP"=/etc/updated-files

would put a null-terminated list of deleted files in /etc/deleted-files,
and a null-terminated list of updated files in /etc/updated-files.

Maybe someone will think some of these ideas are worth pursuing...