RFC: shell-safe version of string_sub()?
Jean Francois Micouleau
Jean-Francois.Micouleau at dalalu.fr
Thu Oct 19 07:39:39 GMT 2000
On Thu, 19 Oct 2000, Peter Samuelson wrote:
> 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.
IMNSHO, %J substitution shouldn't be mangled at all. IIRC, this mangling
is from previous printing database time.
The only mangling that should happen is adding quotes around the string.
> 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