[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