[scponly] new patch: makes rsync work

wby oblyr joe at sublimation.org
Tue Oct 31 03:19:47 EST 2006




Kaleb,

I also think you're right about getopt_long being better.

I have implemented the proposed patch sortof - instead of looping through looking for the relative position of optargs, I 
strip all the '--foo' arguments from argv before passing to getopt for examination.  the '--foo' options are checked without 
getopt as they appear, because there are seperate entries in the dangerous_args entry to each dangerous argument.

if you get the sourceforge CVS set up, you can see the changes i've made.

cvs diff -r SCPONLY_4_6 helper.c

In any case, I think your fix is superior, but should be encased in a HAVE_GETOPT_LONG macro, given the potential for 
portability problems.

joe


Kaleb Pederson wrote this message on Mon, Oct 30, 2006 at 23:08 -0800:
> P??ter,
> 
> Thanks for contributing.
> 
> Although this should work, I would prefer to only explicitely allow the ones 
> that we know safe -- in this case '--server' and '--sender'.  Using 
> getopt_long we could have a list of allowed args that we could validate in 
> its entirety.  Thus, if rsync or any other program comes out with a new 
> command line option, we wouldn't be vulnerable.
> 
> I had mostly finished this up a couple of months ago... but circumstances 
> haven't permitted me to finish it up :(
> 
> Basically, it just employed the concept shown up in the getopt_long manpage:
> 
> // make an array 
> static struct option allowed_long_opts[] = {
>     {"server", 1, 0, 'k'},
>     {"sender", 0, 0, 'k'},
>     {0,0,0,0}
>   };
> 
> c = getopt_long (argc, argv, OPTS_FOR_CMD_IN_USE,
>          allowed_long_opts, NULL);
> 
> if ('k' == c || other allowed shortopt)...;
> 
> Anyway, you obviously got around to it first -- and something is much better 
> than nothing... so thank you.
> 
> Hopefully with some other feedback we can end up with the best all-around 
> solution.
> 
> --Kaleb
> 
> 
> 
> On Sunday 29 October 2006 2:38 am, P??ter Szab?? wrote:
> > Dear scponly Developers,
> >
> > We have prepared a patch to scponly-4.3. The patch makes it possible to
> > use rsync with scponly. Before this patch scponly refused the ``rsync
> > --server'' option with this message in syslog:
> >
> >   option e is not permitted for use with /usr/bin/rsync (arg was rver)
> > requested command (/usr/bin/rsync --server --sender -vlogDtprz . v)
> >   tried to use disallowed argument
> >
> > Get the patch from
> >
> >   http://www.szszi.hu/~pts/scponly/pts-scponly-4.3-rsync.patch
> >
> > What do I have to do in order to get the patch integrated to scponly?
> >
> > Best regards,
> >
> > P??ter Szab??
> > free software consultant
> > Free Software Institute, Hungary
> >
> >
> >
> >
> >
> > _______________________________________________
> > scponly mailing list
> > scponly at lists.ccs.neu.edu
> > https://lists.ccs.neu.edu/bin/listinfo/scponly
> 
> _______________________________________________
> scponly mailing list
> scponly at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/scponly



More information about the scponly mailing list