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

[Ben Escoto]

On Fri, 2002-07-12 at 17:01, Martin Pool wrote:
> I think the main questions are:
> 
>  - do people actually want all that flexibility?
> 
>  - is it worth starting from scratch?
> 
>  - is this a reasonable way to go
> 
> You can see the current thoughts here:
> 
>   http://samba.org/~mbp/superlifter/
> 
> I'd appreciate any comments you might have.

When I read this, the first thing that came to my mind was a project
that had three parts:

1.  The specification for an abstract protocol designed to allow a
single threaded application get good performance using a single,
possibly low bandwidth/high latency pipe.  No specific file commands
would enter in at this stage, but error reporting and recovery, some
kind of security policy, and some other stuff I'm omitting would be
included.

2.  A library to make it easy for applications to work with protocols
that have the form in 1.  A well-written interface to a scripting
language (probably python) would be considered a core part of this.

3.  Specification for a more specific, rsync-like protocol, and maybe
another library (again with at least a scripting wrapper) to make it
easy for applications to implement the protocol.

4.  The model application rsync3 which shows off what the protocol can
do.  Ideally this part should be really short and sweet.

The end result could be to let people develop different applications
very easily which have the power of rsync.  For instance, perhaps
something like rdiff-backup could have used the protocol defined in step
3, and maybe even an unmodified rsync server, and turn out faster than
it currently is.  Other people could use the tools to do something with
encrypted files, and maybe their app wouldn't use the rsync algorithm at
all.

    Is all this a good idea?  I have no idea, it is just what came to my
mind when I read your design notes.  But it does appear that some areas
of the project (like debating ":" vs "::") have little to do with other
areas (like TCP vs UDP, apache server mod).

    I'm not sure how much "market research" you have, but if you just
create a better rsync it might be hard to know how many people that
would help and how many find rsync good enough.  The above approach
could be a hedge against that because it could be used for a lot of
stuff and if you make it easy enough to work with (say with the
scripting support, simple APIs) I'm sure other people will dream cool
stuff up.

    This message is longer than I intended - it's always dangerous to
write volumes on something I know nothing about :-)


--
Ben Escoto


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20020712/10e735bb/attachment.bin