Re: getopt() argument permuting considered risky

["Michael T Kerrisk" <mtk-lists at gmx dot net>]

Paul,

> "Michael T Kerrisk" <mtk-lists@gmx.net> writes:
> 
> > we can construct other examples

Just in passing:

    chmod 644 *

> Sure, but you'd have a more convincing argument if you had real-world
> examples rather than artificial ones.

Yes, well my point was to talk about the *possibility* of security 
holes; it seems to me that in theory there might be many examples 
where glibc's getopt() could change the behaviour of a shell script 
that runs fine on most (all?) other Unix systems.  But I admit that 
I'm unsure of the degree to which the "theory" translates into 
practice.

> > My point is that glibc's getopt() behaviour introduces a 
> > behaviour not present on other Unix systems.
> 
> No, similar behavior is present on other Unix systems, in some cases.
> Here's Solaris 9, for example:
> 
>    $ export PATH=/usr/xpg4/bin:/usr/bin
>    $ ls
>    $ echo foo >foo
>    $ sort foo -o bar
>    $ ls
>    bar  foo

Well, sort(1) was always a special, idiosyncratic case.

> This behavior does not conform to POSIX 1003.1-2001 (which says that
> "sort" must try to read a file named "-o"), but it's quite common on
> older platforms and was even required by some earlier standards.
> 
> 
> >> As a practical matter, portable scripts cannot assume the
> >> POSIX-specified behavior here.  
> >
> > You mean because of the glibc behaviour?
> 
> Yes, that's mainly it.  Though I wouldn't be surprised if some other
> implementations worked similarly.

In passing, I did some testing on the following systems, and didn't 
see any cases where other systems behaved as Linux: Solaris 8, 
FreeBSD 5.1, MacOS X (Darwin 7.4.0), HP-UX 11, and Tru64 5.1.

And another note in passing: if we're trying to avoid the
glibc behavior by the consistent and appropriate use of "--" 
in scripts, we can still be caught out by inconsistencies in 
the command line API; for example, gcc doesn't understand 
"--", moaning that it's an "ambiguous abbreviation.

But overall, I do take your points:

-- glibc's getopt() has changed the landscape irrevocably.

-- in general one simply has to be very careful about
   processing all kinds of input to shell scripts, and 
   that's true with or without glibc's getopt(); indeed
   the role of glibc's getopt() in this need to be careful
   is clearly more minor than I thought to start with.
   (This morning, I went and reviewed some of my own shell
   scripts and discovered that there *were* several breakages
   to be seen as a result of this discusion; however,
   I could only attribute a minority of them to the
   glibc behaviour.)
    
Bur, it still strikes me as a little unfortunate that the 
original choice wasn't to make the default behavior 
consistent with other implementations, and have the 
glibc behaviour as an extension that could be turned on 
if desired (perhaps reversing the use of the '+' sign!)
But clearly, it's history.

Thanks for your responses.

Cheers,

Michael

-- 
Michael Kerrisk
mtk-lists@gmx.net

NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl