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

> > This brings up an issue that I believe can be solved in a simpler way
than
> > with brute force C code.  I suspect some of you will cringe when you
hear
> > this, but a taintperl log parsing program would be best for this. 
rsync
> > could generate a verbose log file that is not human readable, designed
to
> > be read by a perl postprocessing script.  I think this would allow
greater
> > flexibility, and modularize the functionality to avoid some possible
> > security problems.  This way log parsing would not be done at the
> > authentication level of rsync(root) but at some lower level with read
> > access to the log file.  Does this sound like a reasonable solution?
> 
> Perl should be avoided.  Perl is proof that sysadmins don't grok
> language design.
> 
Understood.  However, how about separating the log parsing anyway?  There
are many pre-built log file parsing programs out there.  A verbose, and 
consistant log format could allow more flexibility.

						Robert Weber
						University of Colorado

On Tue, Jul 09, 2002 at 12:20:09PM -0600, Robert Weber
wrote:
> > > This brings up an issue that I believe can be solved in a simpler
way than
> > > with brute force C code.  I suspect some of you will cringe when
you hear
> > > this, but a taintperl log parsing program would be best for this.
rsync
> > > could generate a verbose log file that is not human readable,
designed to
> > > be read by a perl postprocessing script.  I think this would
allow greater
> > > flexibility, and modularize the functionality to avoid some
possible
> > > security problems.  This way log parsing would not be done at the
> > > authentication level of rsync(root) but at some lower level with
read
> > > access to the log file.  Does this sound like a reasonable
solution?
> > 
> > Perl should be avoided.  Perl is proof that sysadmins don't grok
> > language design.
> > 
> 
> Understood.  However, how about separating the log parsing anyway?  There
> are many pre-built log file parsing programs out there.  A verbose, and 
> consistant log format could allow more flexibility.
I personally can live with log parsing.  It seems unnecessarily
complicated for the enduser, and I worry that not making rsync do the
right thing by default will lead to an increased number of breakins.  I
personally can handle the parsing; I'm more worried about the people who
won't even realize they need to do parsing to get reasonable behavior
from a security perspective.

In other words, if you insist, so be it.

-- 
Dan Stromberg                                               UCI/NACS/DCS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url :
http://lists.samba.org/archive/rsync/attachments/20020711/2825e6da/attachment.bin