Honestly I don't think there is an ejection possible. The arguments are passed seperately anyway.

At least I don't manage to shell inject:

  src$ touch \`touch\ x\`
  src$ ls
  `touch x`
  src$ ls ../trg/
  `touch x`
  src$ 

  src$ touch "; touch x"
 src$ ls -l ../trg/
  total 0
  -rw-r--r-- 1 axel axel 0 Nov 25 15:30 ; touch x
  -rw-r--r-- 1 axel axel 0 Nov 25 15:29 `touch x`

This is because Lsyncd never plainly spawned shells as one string command, but always using an exec call that provides the arguments as array.

Have you tried the examples I gave in #348?

Ah sorry, my fault. You're correct.

let me check if providing " in the filenames breaks it again

src$ mv "; touch x"   "\" x \"; touch x"
src$ ls -al
total 8
drwxr-xr-x  2 axel axel 4096 Nov 25 15:44 .
drwxr-xr-x 11 axel axel 4096 Nov 25 15:42 ..
-rw-r--r--  1 axel axel    0 Nov 25 15:30 "; touch b
-rw-r--r--  1 axel axel    0 Nov 25 15:31 " x "; touch x
src$ 
src$ ls -al ../trg/
total 8
drwxr-xr-x  2 axel axel 4096 Nov 25 15:44 .
drwxr-xr-x 11 axel axel 4096 Nov 25 15:42 ..
-rw-r--r--  1 axel axel    0 Nov 25 15:30 "; touch b
-rw-r--r--  1 axel axel    0 Nov 25 15:31 " x "; touch x
src$ 

Looks good to me, anything else one could do to escape/break it?

Now probably only special names beginning with a dash would be a problem (will be treated as parameters), but as I mentioned in #348 - lsyncd requires passing absolute paths to work correctly so the potential exploit will usually be prevented by the user running the daemon. Nevertheless, that bug should probably be corrected as well if the patch (e.g. adding '--') wouldn't break lsyncd on non GNU/Linux platforms.

I see, in -nodaemon mode paths can be relative, but it will always prepend at least a directory name before it. So I don't think it can happen

That is as long the user doesn't provide a target name starting with a dash.

Just tested it on a fairly old OSX i got around. Shell utils accept "--", so I see no reason to not add them

Done. Sorry i delayed this by a year.