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

jw schultz jw at pegasys.ws
Mon Jul 8 15:57:02 EST 2002


On Mon, Jul 08, 2002 at 05:40:58PM -0400, Lenny Foner wrote:
>     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.

I did consider the newline in the filename issue and the
possibility of using null termination.  Although xargs can
deal will the nulls most common tools cannot.  So far i have
never seen a file created with a newline in the filename
(except, perhaps as a test).  The newline in filename issue
is an old one that just doesn't seem to come up except in
theory.

[snip] 

> 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.

It might be worth looking up in SuS-3.  Maybe it is
addressed there.  Certainly from a security standpoint it
might be a good idea to disallow it on account of all the
tools used in administration that don't handle it well.  It
has been hard enough dealing with spaces!

> 
> 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)
[snip]

I don't care for the grouping and lithpiness :) but i think
we may be getting a concensus that improving log-format is
the best way to go.  Dave D. has even chimed in on that.  If
we just had % directives that seperated printing of paths
from links and for printing the "action" it would be a big
improvment.  The possiblility of having null terminations is
a good one and I have felt for awhile that the -v -v -v -v
business was a terrible way to decide what to put in the
log.  If i had a better idea of my future time constraints i
might consider taking it on.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt




More information about the rsync mailing list