RFC: shell-safe version of string_sub()?

Peter Samuelson peter at cadcamlab.org
Thu Oct 19 07:01:26 GMT 2000

CVS SAMBA_2_2 but probably applies more broadly ---

Barely-relevant background:

  The other day I set up a ps2pdf server using a print queue, a share,
  Ghostscript, and minimal glue.  Works great.  (And spoolss *rules*!)
  However, I ran into a glitch with the 'print command' option.

In print_job_end() (printing.c), the lp_printcommand() shell command
undergoes some substitutions such as '%J' for the print job name.
pstring_sub() calls string_sub() which mangles the job name to convert
several characters to underscores.  I managed to hit a corner case
somewhere with a print job with a space in the name -- the space didn't
get converted.  This of course caused my script to fail.

I know I could just quote the args myself:

  print command = /usr/local/bin/my_script -u "%U" -n "%J" "%f"

instead of

  print command = /usr/local/bin/my_script -u %U -n %J %f

but this is cheesy -- and we're still losing information as other
characters become underscores.  I would like to propose an alternate
function, call it string_sub_sh(), which instead of the string_sub()
mangling does shell-metacharacter mangling.  Basically anything not in
the list [A-Za-z0-9/=+_-] is backslashed.  That should be safe in all
known shells (known to me, that is).  Perhaps decimal 160-254 are OK
too -- they are in at least some shells.

That way shell command lines don't need to use quoting, which is
counterintuitive ("do I use single quotes or double quotes?").  Of
course one still has to tread carefully if the resulting command is a
Bourne or (horrors) csh script, but not if it's (say) C or Perl.  And
this case is IMHO analogous to setuid -- nobody sane would use plain
shell here if doing anything nontrivial.

Anyway, I imagine string_sub_sh would be useful lots of other places in
the corpus as well -- quite a few functions have to compose shell
command lines, right?  Does anyone else think I'm on to something here?
I'll try to find time to write a patch in the next 24 hours or so --
for me if no one else.


More information about the samba-technical mailing list