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

[jw schultz]

On Mon, Jul 08, 2002 at 09:18:18PM +0800, Adrian Ho wrote:
> On Mon, Jul 08, 2002 at 03:52:16AM -0700, jw schultz wrote:
> > Also the path should not be fully qualified but instead should match
> > that of the commandline with cwd the same as the rsync launch.
> 
> 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.

It doesn't need to be the src/dest directory.  It is only
required that relative paths be correct for the cwd which
would be unchanged from the invocation.  On the initiator
this means use the path from the commandline + the 
path relative to that.

Sorry if i react strongly to the absolute path suggestion.
I have unpleasant memories of having to clean up after
programs that decided to _discover_ the REAL paths, bypassing
symlinks, and wound up with unofficial temporary paths that
broke later; and with people/programs that used absolute
paths that broke when things moved.  That sort of thing is
the bane of sysadmins.  The path i type is the one i want
you to use--don't try to outsmart me.

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

My focus with the format above was to make it immune to
filename contents messing with it.  It would even work with
unicode filenames as long as no filenames contain newlines.
That is why i didn't include the destination for links.

> BTW, does the current protocol reflect the receiver's disposition of
> each target back to the sender?  If not, I would certainly like to see
> that added to the protocol, so that the post-send script can also take
> some well-informed actions.

What do you mean?  Update, delete, create? Or do you mean
per file success/failure/completion?  I believe that
sender-receiver communication is one-way.  I expect the next
protocol change (don't quote me) will probably be reserved
to for breaking the transfer into smaller blocks (oom) and
isolating the stages.  Changing the protocol is expensive.
You would need a pretty compelling reason to get a protocol
change now.

> 
> > For some uses this output would actually be an improvement on the
> > logging so it might be nice to be able to direct it into a file without
> > spawning a process.
> 

Perhaps.  If we added the % codes for the action (as in my
example) and path (without the link stuff).  At present
i see no way to know whether a file is listed because of
creation, update or because it is a special file (dev, pipe,
etc).  Special files seem to be listed even if unchanged
since all that is needed is the stat info.  Directories are
easy to identify by the trailing / and links by [-=]> as
long as no filenames contain those strings.  Still have the
leading and trailing messages to strip off.

I'm not sure of the value for the sender having this
functionality and i don't think it should be allowed on the
remote end except if specified in the rsyncd.conf when
running an rsync server.  Be bad form to blythly allow
remote execution of an arbitrary executable via rsync.


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

		Remember Cernan and Schmitt