Re: avoid mkdir/selinux failure when mknod is a shell built-in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/16/2008 6:57 AM: | $ PATH=. /bin/sh -c 'exec mknod --version'|head -1 | /bin/sh: mknod: --: unknown option Ouch - this looks like a POSIX compliance bug in exec; I'm adding bug-autoconf to the distribution in case we want to document this corner case bug in the shell portability section. POSIX states that exec is supposed to bypass shell builtins (and while special shell builtins, like 'exit', give undefined behavior when passed to exec, regular shell builtins, like 'fg', are required to exist in PATH even if they can't quite do as much work as their builtin counterpart). Do you know which shell heritage the OpenBSD /bin/sh derives from? | $ PATH=. /bin/sh -c 'nice mknod --version' | head -1 | mknod (GNU coreutils) 6.10.188-7cb24 | So I'll go with nice. Sounds nice to me (sorry, couldn't resist :) - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgF+h4ACgkQ84KuGfSFAYBgwQCgkm+chKbhFZ+zkxx7U6Mn6QT1 NCUAoKAcBXl5/fg6KyURTn9fKu2kxPFL =SDPR -END PGP SIGNATURE-
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 4/16/2008 6:57 AM: | $ PATH=. /bin/sh -c 'exec mknod --version'|head -1 | /bin/sh: mknod: --: unknown option Ouch - this looks like a POSIX compliance bug in exec; I'm adding bug-autoconf to the distribution in case we want to document this corner case bug in the shell portability section. POSIX states that exec is supposed to bypass shell builtins (and while special shell builtins, like 'exit', give undefined behavior when passed to exec, regular shell builtins, like 'fg', are required to exist in PATH even if they can't quite do as much work as their builtin counterpart). Do you know which shell heritage the OpenBSD /bin/sh derives from? This is on 3.9 GENERIC#617 i386 OpenBSD, and /bin/sh is a hard link to /bin/ksh. strings says it's PDKSH: PD KSH v5.2.14 99/07/13.2 | $ PATH=. /bin/sh -c 'nice mknod --version' | head -1 | mknod (GNU coreutils) 6.10.188-7cb24 | So I'll go with nice. Sounds nice to me (sorry, couldn't resist :) :)
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Hi Eric,
* Eric Blake wrote on Wed, Apr 16, 2008 at 03:07:42PM CEST:
According to Jim Meyering on 4/16/2008 6:57 AM:
| $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
| /bin/sh: mknod: --: unknown option
Ouch - this looks like a POSIX compliance bug in exec; I'm adding
bug-autoconf to the distribution in case we want to document this corner
case bug in the shell portability section. POSIX states that exec is
supposed to bypass shell builtins (and while special shell builtins, like
'exit', give undefined behavior when passed to exec, regular shell
builtins, like 'fg', are required to exist in PATH even if they can't
quite do as much work as their builtin counterpart).
Can you please point me to where POSIX specifies these things? I cannot
find in the page describing exec, that it has to bypass built-ins.
Also, I cannot find at all that regular shell builtins have to exist as
independent programs in $PATH. The only thing I found wrt. special
built-ins was
The special built-in utilities in this section need not be provided
in a manner accessible via the exec family of functions defined in
the System Interfaces volume of IEEE Std 1003.1-2001.
which isn't a requirement on the implementation.
I'm looking at SUSv3, by the way.
* Eric Blake wrote on Wed, Apr 16, 2008 at 06:14:35PM CEST:
Any comments before I check it in?
[EMAIL PROTECTED] @command{exec}
+Posix divides the set of shell built-ins into two groups. Special
+built-ins (such as @command{exit}) must impact the environment of the
+current shell, and need not be available through @command{exec}.
+Regular built-ins (such as @command{echo} or @command{cd}) must not
+propogate variable assignments to the environment of the current shell,
propagate
+On the other hand, @command{pdksh} 5.2.14 refuses to execute the
+executable replacement, using the built-in no matter what:
OpenBSD's /bin/sh is heavily modified from pdksh. While it seems that
both share this bug, in general one should not be quick to assume both
share all features.
+This has the interest effect that @command{pdksh} can use @command{exec}
s/interest/interesting/
+on special built-ins, even though Posix doesn't require it:
Thanks,
Ralf
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: case bug in the shell portability section. POSIX states that exec is supposed to bypass shell builtins (and while special shell builtins, like 'exit', give undefined behavior when passed to exec, regular shell builtins, like 'fg', are required to exist in PATH even if they can't quite do as much work as their builtin counterpart). Can you please point me to where POSIX specifies these things? I cannot find in the page describing exec, that it has to bypass built-ins. Point taken. XCU 2.9.1.1 Command Search and Execution gives this order: 1. special built-ins 2. user-provided shell functions 3. certain utilities (for example, true or command) (the point of this list is to guarantee that regardless of how badly PATH is munged, these utilities will still work rather than executing a trojan implementation earlier on the path; useful since command can then be used to generate a repaired PATH) 4. PATH search, including shell-provided functions and regular builtins: the command shall be searched for using the PATH environment variable as described in XBD Chapter 8 (on page 173): i. If the search is successful: a. If the system has implemented the utility as a regular built-in or as a shell function, it shall be invoked at this point in the path search. This makes it sound like the shell cannot use the builtin unless the PATH search succeeds, but once successful, the shell can then invoke its builtin instead of calling execv() on what was found on PATH. So I guess POSIX does not require that exec must bypass builtins, and therefore, pdksh is not buggy, just different. Also, I cannot find at all that regular shell builtins have to exist as independent programs in $PATH. The only thing I found wrt. special built-ins was The special built-in utilities in this section need not be provided in a manner accessible via the exec family of functions defined in the System Interfaces volume of IEEE Std 1003.1-2001. which isn't a requirement on the implementation. In addition to the above wording about simple command execution requiring a successful path search, I think this wording in command is most applicable here: http://www.opengroup.org/onlinepubs/009695399/utilities/command.html Two types of regular built-ins could be encountered on a system and these are described separately by command. The description of command search in Command Search and Execution allows for a standard utility to be implemented as a regular built-in as long as it is found in the appropriate place in a PATH search. So, for example, command -v true might yield /bin/true or some similar pathname. Other implementation-defined utilities that are not defined by this volume of IEEE Std 1003.1-2001 might exist only as built-ins and have no pathname associated with them. These produce output identified as (regular) built-ins. Applications encountering these are not able to count on execing them, using them with nohup, overriding them with a different PATH , and so on. So mknod qualifies as a candidate for a regular builtin that need not be PATH- based (since POSIX doesn't require mknod(1)). I would almost claim that true MUST exist in the PATH, except that true is on the list of 17 utilities that must work regardless of PATH search (hmm - the Posix example of command -v true yielding /bin/true is thus suspect). But printf is a good example - it is a POSIX-mandated utility, not on the special list of required utilities, but often implemented as a builtin; even if it is a builtin, this statement says it must also exist on PATH. I'm looking at SUSv3, by the way. As am I. * Eric Blake wrote on Wed, Apr 16, 2008 at 06:14:35PM CEST: Any comments before I check it in? Thanks for the nitpicks. How about this attempt at rewording things? (I dropped mention of exec special-builtin, since that is already explicitly undefined by Posix) From 9651f4a0e1b80c55da23a5ceaa0237121e0b95f2 Mon Sep 17 00:00:00 2001 From: Eric Blake [EMAIL PROTECTED] Date: Wed, 16 Apr 2008 10:10:31 -0600 Subject: [PATCH] Document pdksh exec behavior. * doc/autoconf.texi (Limitations of Builtins) exec: New subsection. Discovered by Jim Meyering. Signed-off-by: Eric Blake [EMAIL PROTECTED] --- ChangeLog |7 +++ doc/autoconf.texi | 48 2 files changed, 55 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index b1d9a4e..9d9d04e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2008-04-16 Eric Blake [EMAIL PROTECTED] + + Document pdksh exec behavior. + * doc/autoconf.texi (Limitations of Builtins) exec: New + subsection. + Discovered by Jim Meyering. + 2008-04-14 Ralf Wildenhues [EMAIL PROTECTED] * tests/autotest.at (AT_CHECK_AT): Allow to pass additional diff --git a/doc/autoconf.texi b/doc/autoconf.texi index 8b10387..554d2ec
Re: avoid mkdir/selinux failure when mknod is a shell built-in
[ re-added bug-autoconf ] * Eric Blake wrote on Wed, Apr 16, 2008 at 08:04:23PM CEST: Subject: [PATCH] Document pdksh exec behavior. * doc/autoconf.texi (Limitations of Builtins) exec: New subsection. Discovered by Jim Meyering. This looks good to me, thanks. Cheers, Ralf
