This is the mail archive of the
mailing list for the glibc project.
Re: getopt() argument permuting considered risky
- From: "Michael T Kerrisk" <mtk-lists at gmx dot net>
- To: Paul Eggert <eggert at CS dot UCLA dot EDU>
- Cc: libc-alpha at sources dot redhat dot com,geoff at gclare dot org dot uk
- Date: Thu, 5 Aug 2004 15:27:29 +0200 (MEST)
- Subject: Re: getopt() argument permuting considered risky
- References: <firstname.lastname@example.org>
> "Michael T Kerrisk" <email@example.com> 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
> > 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
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.
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl