[PATCH] RFC: shell-safe version of string_sub()?
Nicolas.Williams at ubsw.com
Wed Oct 25 19:55:57 GMT 2000
On Wed, Oct 25, 2000 at 02:36:34PM -0500, Peter Samuelson wrote:
> [Nico Williams]
> > Very, very cool. I like this very much.
> > But I am very grateful as this patch is very good, from a security
> > point of view.
> Perhaps, but note that it is not a silver bullet. (Like a free lunch,
> there ain't no such thing.) It allows all manner of strange characters
> in command arguments. Sure, they are shell-escaped, but if your
> command line is *itself* a shell script, that script had better be
> careful! So, unless you are very very experienced with shell scripting
> and know the issues involved, I would recommend using something more
> robust, such as C, Perl or Python. Judging from the scripts I have
> come across in my career as a Unix user, an overwhelming percentage are
> not even close to weird-argument-safe -- so I must conclude that most
> Unix users are *not* in fact very familiar with these issues.
I understand. It's just that some of the Samba config parameters where
external commands can be executed use system(), and that uses /bin/sh.
Thus the need for this patch.
I can make sure my external scripts/programs are fairly secure. But I
can't make sure Samba is -- Samba is a much larger program than the
external programs I'm using in conjunction with Samba.
You're right about most scripts. In shell scripts one must be religious
about using double quotes wherever variables are referenced, especially
if those varfiables may contain "wierd" characters (that includes
space), unless one is specifically trying to split a variable's value
(and even then...).
Also, it's a very good idea to use "$@" in [Bourne, Korn, Bash] shell
scripts when referencing the script's [or function's] arguments. Few
people know the difference between "$@" and "$*" and $*...
E.g., 'for i in $*' is _bad_, use 'for i in "$@"' instead...
> > Hmmm, what about unicode/code pages? Will this patch work as intended?
> Unicode: no. The crt0.o argument passing convention specifies that
> command-line arguments are seen as null-terminated strings. Since
> Unicode uses the null character a lot...... Basically you *can't* pass
> raw Unicode strings on a command line -- so I hope Samba never tries.
I was thinking more about UTF-8. Unix syscalls all use char * for string
arguments; where they use unsigned char * UTF-8 can be used, so I was
wondering about the possibility filenames containing Unicode characters
(on the Windows side) being used which might screw up the quoting your
patch implements. I imagine this is not a problem since Unix filenames
are all ASCII strings anyways, so Samba has to map Windows filenames to
Unix filenames, and... Ok, yeah, Unicode probably doesn't enter the
picture here. Thanks.
> As to alternate code pages: I don't know enough about them to give a
> good answer.
More information about the samba-technical