Bug 27143

Summary:	Calling `system("-some-tool")` fails (although it is a valid `sh` command)
Product:	glibc	Reporter:	Ciprian Dorin Craciun <ciprian.craciun>
Component:	libc	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED MOVED
Severity:	normal	CC:	alx.manpages, drepper.fsp, fweimer
Priority:	P2	Flags:	fweimer: security-
Version:	2.32
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Ciprian Dorin Craciun 2021-01-03 17:30:07 UTC

As the subject states, the `system` function fails when calling it with a command that starts with a hyphen, which is an accepted executable name, and an accepted `sh` command.

Let's assume one has an executable starting with a hyphen, as in:
~~~~
ln -s -T /usr/bin/echo ~/.bin/-echo
~~~~

Assuming that `~/.bin` is in `$PATH` the following work in "plain" `sh` / `bash`:
~~~~
type -P -- -echo
which -- -echo
-echo a b
~~~~

However the following simple `main.c` doesn't work:
~~~~
> cat ./main.c
main() { system("-echo a b"); }

> gcc -o ./main ./main.c

> ./main
sh: - : invalid option
~~~~



The issue is simple:

* `system("-echo a b")` end's up calling `sh -c '-echo a b'`;

* unfortunately the `-c` argument states that it will use as a command the **first non-option argument** which in this case there is none as `-echo a b` is mistaken as an option argument;



The solution would be updating `system` to issue `sh -c -- {command}`, as in (taking the manual as example):
~~~~
execl("/bin/sh", "sh", "-c", "--", command, (char *) NULL);
                             ^^^^ this is added
~~~~



However this proposed solution might break systems where `sh` doesn't accept the `--` separator.  (Is this the case?)

An alternative would be, if the command starts with a hyphen then a space could be added at the beginning, as in: `sh -c ' -echo a b'`



My environment:

* `sh --version` -- `GNU bash, version 5.0.18(1)-release (x86_64-suse-linux-gnu)`;

* `getconf --version` -- `getconf (GNU libc) 2.32`

Comment 1 Florian Weimer 2021-01-04 10:31:08 UTC

Unfortunately, this bug is required by POSIX, which requires passing the string as an argument to the -c option of the shell.

You could report this to the Austin Group as a defect in POSIX: <https://www.austingroupbugs.net/>

Comment 2 Ciprian Dorin Craciun 2021-01-04 12:55:04 UTC

> [...] this bug is required by POSIX [...]

OK, I might understand this, however I find it hard to believe that `glibc` can do nothing about this...

For example one could:

(A)  Update the `system(3)` `glibc` man page to warn the user that at the moment there is a bug in the POSIX specification, and that any command starting with `-` would in fact trigger a failure of `sh`.

(B)  Update the `system(3)` implementation so that when a command starts with `-` it prepends a space.  This should have almost zero consequences because spaces are allowed (and trimmed) by virtually all existing `sh` interpreters out there.

Comment 3 Florian Weimer 2021-01-04 12:58:19 UTC

POSIX specifies the exact value of the -c argument.

The manual pages are maintained as a separate project: https://www.kernel.org/doc/man-pages/

Comment 4 Ciprian Dorin Craciun 2021-01-04 13:11:19 UTC

> The manual pages are maintained as a separate project:
> https://www.kernel.org/doc/man-pages/


OK, I've opened a feature request there:

  https://bugzilla.kernel.org/show_bug.cgi?id=211029


----


Out of curiosity, was this "bug mandated by POSIX" known or?

Comment 5 Alejandro Colomar (man-pages) 2021-01-04 14:29:15 UTC

The Bash manual page does mention that of the "first non-option argument", but the Dash manual page doesn't (Debian has sh -> dash).

However, I confirmed this also happens on systems with Dash.

Comment 6 Ciprian Dorin Craciun 2021-01-04 15:24:44 UTC

I've started the process of reporting the bug to the POSIX Austin Group, however as I don't have an account there and the procedure requires direct contact with the group's chair, it most likely will take some time...

I'll report back when I have some news.

Comment 7 Ciprian Dorin Craciun 2021-01-04 15:51:33 UTC

OK, I've opened an issue on the POSIX bug tracker:

  https://www.austingroupbugs.net/view.php?id=1440