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