Re: problem with relaying

[Matti Aarnio <mea@nic.funet.fi>]

On Thu, Jan 18, 2001 at 03:11:16PM +0300, Eugene Crosser wrote:
> I'd second this.
> "Don't fix it if it ain't broken"
> sh-like language has its problems (notably dangerous variable expansion)
> but it also has advantages.  For example, most admins know it at least
> basically, and very few people are religious about it.
> 
> Eugene

	Like I noted before, "brokennes" is somewhat 'in the eye of
	the beholder'.

	... actually now that I compare code with carefull "don't let
	go of quotes in quoted string" and previous code, following
	test with "sticky quotes" shows near identical behaviour to
	that of previous generation:

z# rtrace
z#  v1=jjjjjjj
    v1=jjjjjjj
z# v2=kkkkk
    v2=kkkkk

	Note here string catenation without quotes around it:

z# v3=$v1:$v2
    v3=jjjjjjj:kkkkk
z# echo $v3
    echo jjjjjjj:kkkkk
jjjjjjj:kkkkk
z# echo $v1 $v2 $v3
    echo jjjjjjj kkkkk jjjjjjj:kkkkk
jjjjjjj kkkkk jjjjjjj:kkkkk
z# x="a b c d"
    x='a b c d'
z# for y in $x;do echo $y;done
    echo a b c d
a b c d
z# for y in $(ifssplit $x);do echo $y;done
    ifssplit (ifssplit 'a b c d') <0>
    echo a
a
    echo b
b
    echo c
c
    echo d
d
    echo `
`
z# 

	Hmm... What is that last one ??
	... oh, I see ... fixed.


	The difference is in that 'for' statement.  Before the implicite
	IFS splitting made first case to work as the second one does below:

	original code:

z# t="a b c d"
z# provide $t
    provide 'a b c d' b c d
        declare provide 'a b c d' b c d
            lreplace (lreplace provide a a) <0>
            lreplace (lreplace provide b b) <0>
            lreplace (lreplace provide c c) <0>
            lreplace (lreplace provide d d) <0>


	'sticky' code:

z# provide $x
    provide 'a b c d'
        declare provide 'a b c d'
            lreplace (lreplace provide 'a b c d' 'a b c d') <0>


	Above the implicite split shows.

	Come to think of it, this means that in function calls with
	position dependent parameter lists the new code means that
	spacefull data at a variable won't spill into wrong position
	in case the call happens without quoting string variables:

		$(funcall $var1 $var2 $var3)

	Following IFS-splitting looks quite ugly:
	(unmodified shell)

z# v1='dom ain';v2='plus tail';q=(1 2 3 4);routeuser $q $v2 $v1
    v1='dom ain'
?=1
    v2='plus tail'
?=1
    q=(1 2 3 4)
?=1
    routeuser (1 2 3 4) 'plus tail' tail 'dom ain' ain
        plustail2=''
        attributes (attributes (1 2 3 4)) <0>
        attr=4
        channel (channel (1 2 3 4)) <0>
        chan=1
        user (user (1 2 3 4)) <0>
        user=3
        key=3


	With 'sticky quotes' the thing looks like:

z# v1='dom ain';v2='plus tail';q=(1 2 3 4);routeuser $q $v2 $v1
    v1='dom ain'
    v2='plus tail'
    q=(1 2 3 4)
    routeuser (1 2 3 4) 'plus tail' 'dom ain'
        plustail2=''
        attributes (attributes (1 2 3 4)) <0>
        attr=4
        channel (channel (1 2 3 4)) <0>


	Ok, with this I am less worried about function bugs leaking in
	by omitting double-quotes from some important spot.
	(Actually even string-catenation 

	I just tried various ways to sneak in back-quotes ( `/bin/pwd` )
	which should cause calling of some (sub) function.  Nothing
	like that happened with non-modified shell.

	Only if the interpreted script has backquotes in it, then they
	cause the usual action (unmodified shell):

z# v1="`/bin/pwd`"; echo $v1
    (what /bin/pwd prints is at v1)
z# v2='`/bin/pwd`'; echo $v2
    v2='`/bin/pwd`'
z# v2='`/bin/pwd`'; v3=$v2; echo $v3
    v2='`/bin/pwd`'
    v3='`/bin/pwd`'
    echo `/bin/pwd`
`/bin/pwd`


	Therefore, the security worry about SMTP-server calling
	router, and feeding there bad input is not very generic.
	Unless the calling interface has a hole (should not),
	backticks are unable to effect anything.

		What have I missed ??

	Experimental SH-diffs are at  ftp://zmailer.org/zmailer/
	(and it isn't still any sort of official FTP site..)

-- 
/Matti Aarnio	<mea@nic.funet.fi>