bug#15083: MKNOD issue
close 15083 stop (triaging old bugs) On 13/08/13 02:24 PM, Bob Proulx wrote: Paul Eggert wrote: Manish Gupta wrote: when i try to create in NFS mounted volume, hitting with error "operation not permitted". It sounds like your NFS server is not permitting it. If so, it's not mknod's fault. You can double-check by running 'strace mknode' and seeing what system calls it's using. As far as I know NFS does not support the making of device nodes. Remember that NFS is not a POSIX compliant filesystem. It only supports a subset of file operations. [...] In order to know more you would need to tell us what command you were running that failed. And also include what type of system you were running on and what type of file system you were using. With no further comments in 5 years, I'm closing this bug. -assaf
bug#15083: MKNOD issue
while trying to create block device file using mknod in linux root directory , its working fine.But when i try to create in NFS mounted volume, hitting with error operation not permitted. Is it a bug or or any workaround to overcome this. -- Thanks -Manish
bug#15083: MKNOD issue
Manish Gupta wrote: when i try to create in NFS mounted volume, hitting with error operation not permitted. It sounds like your NFS server is not permitting it. If so, it's not mknod's fault. You can double-check by running 'strace mknode' and seeing what system calls it's using.
bug#15083: MKNOD issue
retitle 15083 mknod fails over NFS tag 15083 + moreinfo thanks Paul Eggert wrote: Manish Gupta wrote: when i try to create in NFS mounted volume, hitting with error operation not permitted. It sounds like your NFS server is not permitting it. If so, it's not mknod's fault. You can double-check by running 'strace mknode' and seeing what system calls it's using. As far as I know NFS does not support the making of device nodes. Remember that NFS is not a POSIX compliant filesystem. It only supports a subset of file operations. You are asking mknod to do something that the kernel/filesystem does not support. Therefore it is failing and telling you that the operation is not permitted. In this case it is not permitted by the system kernel. This is not anything that a userland utility like mknod can do anything about. It is not a bug in mknod. And mknod is operating correctly by emitting the error message. In order to know more you would need to tell us what command you were running that failed. And also include what type of system you were running on and what type of file system you were using. Bob
mknod --help fix
Like mkfifo, mknod has its --help output mangled. Andreas. --- mknod: correct misplaced -Z description in --help output * src/mknod.c (usage): Put it after the Mandatory arguments... line. --- diff --git a/src/mknod.c b/src/mknod.c index d93e2cb..f4028e9 100644 --- a/src/mknod.c +++ b/src/mknod.c @@ -56,12 +56,12 @@ usage (int status) Create the special file NAME of the given TYPE.\n\ \n\ ), stdout); - fputs(_(\ - -Z, --context=CTX set the SELinux security context of NAME to CTX\n\ -), stdout); fputs (_(\ Mandatory arguments to long options are mandatory for short options too.\n\ ), stdout); + fputs(_(\ + -Z, --context=CTX set the SELinux security context of NAME to CTX\n\ +), stdout); fputs (_(\ -m, --mode=MODE set file permission bits to MODE, not a=rw - umask\n\ ), stdout); -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mknod --help fix
Andreas Schwab [EMAIL PROTECTED] wrote: Like mkfifo, mknod has its --help output mangled. --- mknod: correct misplaced -Z description in --help output * src/mknod.c (usage): Put it after the Mandatory arguments... line. Thanks! Applied and pushed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 2:33 AM: | This test would fail not only because the built-in mknod | doesn't support -Z, but because it doesn't know about 'p' pipes. | | tests: avoid mkdir/selinux failure when mknod is a shell built-in | * tests/mkdir/selinux: Skip the mknod test if it's a built-in. Couldn't you try to defeat the shell builtin by using a subshell and exec to force the PATH lookup? For example, on bash: $ printf --version | head -n1 bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] $ (exec printf --version) | head -n1 printf (GNU coreutils) 6.10 Doesn't this also mean that you need to patch mknod.c to print USAGE_BUILTIN_WARNING? - -- 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 iEYEARECAAYFAkgF61YACgkQ84KuGfSFAYDxgQCfcCM73K1gHf3zzTLsJrkqLIY+ T44AnRKNgfzjU4x7mMOzysT2zHCHnR+T =TABh -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 2:33 AM: | This test would fail not only because the built-in mknod | doesn't support -Z, but because it doesn't know about 'p' pipes. | | tests: avoid mkdir/selinux failure when mknod is a shell built-in | * tests/mkdir/selinux: Skip the mknod test if it's a built-in. Couldn't you try to defeat the shell builtin by using a subshell and exec to force the PATH lookup? For example, on bash: $ printf --version | head -n1 bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] $ (exec printf --version) | head -n1 printf (GNU coreutils) 6.10 My first reaction was great! that looks much better. Unfortunately, the technique doesn't work with that shell: openbsd$ ./mknod --version|head -1 mknod (GNU coreutils) 6.10.188-7cb24 openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 /bin/sh: mknod: --: unknown option /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor /bin/sh: mknod: usage: mknod [-m mode] name p However, if m4/gl_POSIX_SHELL were to test for this, I could clean up this test as you suggest, and simply skip it whenever POSIX_SHELL is empty. Volunteers? Doesn't this also mean that you need to patch mknod.c to print USAGE_BUILTIN_WARNING? Yes. Good catch! Thanks! mknod --help: note that this command may be a shell built-in * src/mknod.c (usage): Print USAGE_BUILTIN_WARNING. Suggestion from Eric Blake. diff --git a/src/mknod.c b/src/mknod.c index 8a1718d..445117c 100644 --- a/src/mknod.c +++ b/src/mknod.c @@ -83,6 +83,7 @@ otherwise, as decimal. TYPE may be:\n\ c, u create a character (unbuffered) special file\n\ p create a FIFO\n\ ), stdout); + printf (USAGE_BUILTIN_WARNING, PROGRAM_NAME); emit_bug_reporting_address (); } exit (status); -- 1.5.5.56.gbcf7f ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Hello! On Wed, Apr 16, 2008 at 02:30:57PM +0200, Jim Meyering wrote: Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 4/16/2008 2:33 AM: | This test would fail not only because the built-in mknod | doesn't support -Z, but because it doesn't know about 'p' pipes. | | tests: avoid mkdir/selinux failure when mknod is a shell built-in | * tests/mkdir/selinux: Skip the mknod test if it's a built-in. Couldn't you try to defeat the shell builtin by using a subshell and exec to force the PATH lookup? For example, on bash: $ printf --version | head -n1 bash: printf: --: invalid option printf: usage: printf [-v var] format [arguments] $ (exec printf --version) | head -n1 printf (GNU coreutils) 6.10 My first reaction was great! that looks much better. Unfortunately, the technique doesn't work with that shell: openbsd$ ./mknod --version|head -1 mknod (GNU coreutils) 6.10.188-7cb24 openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 ^ exec? Regards, Thomas signature.asc Description: Digital signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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:30 AM: | My first reaction was great! that looks much better. | Unfortunately, the technique doesn't work with that shell: | | openbsd$ ./mknod --version|head -1 | mknod (GNU coreutils) 6.10.188-7cb24 | openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 | /bin/sh: mknod: --: unknown option | /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor | /bin/sh: mknod: usage: mknod [-m mode] name p That still uses a builtin. You need an exec in the loop to force a PATH search (even command, which bypasses functions, won't bypass builtins). Or perhaps a forwarding command will help; do any of these work? $ /bin/sh -c '(exec mknod --version)' | head -1 $ /bin/sh -c 'nice mknod --version' | head -1 $ /bin/sh -c 'nohup mknod --version' | head -1 - -- 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 iEYEARECAAYFAkgF9RMACgkQ84KuGfSFAYD3eACeJSYwRzZXjUCknA/wnqsOMHCU hMAAoKLQv1qEKOn07Gkc0mq7El/iJcgx =0FHy -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Jim Meyering [EMAIL PROTECTED] writes: Unfortunately, the technique doesn't work with that shell: openbsd$ ./mknod --version|head -1 mknod (GNU coreutils) 6.10.188-7cb24 openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 What about /bin/sh -c 'exec mknod --version'? Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Thomas Schwinge [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 02:30:57PM +0200, Jim Meyering wrote: ... My first reaction was great! that looks much better. Unfortunately, the technique doesn't work with that shell: openbsd$ ./mknod --version|head -1 mknod (GNU coreutils) 6.10.188-7cb24 openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 ^ exec? Of course. My stand-alone example was wrong. However, with 'exec' it fails the same way. On the other hand, Eric's suggestions to use nice or nohup do work: $ PATH=. /bin/sh -c 'exec mknod --version'|head -1 /bin/sh: mknod: --: unknown option /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor /bin/sh: mknod: usage: mknod [-m mode] name p $ PATH=. /bin/sh -c '(exec mknod --version)' | head -1 /bin/sh: mknod: --: unknown option /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor /bin/sh: mknod: usage: mknod [-m mode] name p $ PATH=. /bin/sh -c 'nice mknod --version' | head -1 mknod (GNU coreutils) 6.10.188-7cb24 $ PATH=. /bin/sh -c 'nohup mknod --version' | head -1 nohup: ignoring input and redirecting stderr to stdout mknod (GNU coreutils) 6.10.188-7cb24 $ So I'll go with nice. Thanks, Eric! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 :) :) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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? | $ 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 :) Here's the patch I've just pushed: From 57ae7da07593ab0134e120ea79819fdd069563a1 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 16 Apr 2008 15:28:33 +0200 Subject: [PATCH] tests: accommodate built-in mknod more cleanly * tests/mkdir/selinux: Undo most of previous change, bc22dbbf844f31ddaf2e68b167d0128a985d73ab, and instead invoke the command via nice. Using exec should be enough, but isn't with OpenBSD's PD KSH v5.2.14 99/07/13.2. Eric Blake suggested using nice. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- tests/mkdir/selinux | 12 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/tests/mkdir/selinux b/tests/mkdir/selinux index 4363275..45c2399 100755 --- a/tests/mkdir/selinux +++ b/tests/mkdir/selinux @@ -34,16 +34,12 @@ fi c=invalid-selinux-context msg=failed to set default file creation context to \`$c': -# In OpenBSD's /bin/sh, mknod is a shell built-in. -# In that case, just skip the mknod test. -( mknod --version 21 ) | grep 'GNU coreutils' \ - mknod='mknod b p' \ -|| mknod='mkdir dir' - # Test each of mkdir, mknod, mkfifo with -Z invalid-context. -for cmd_w_arg in 'mkdir dir' $mknod 'mkfifo f'; do - $cmd_w_arg -Z $c 2 out fail=1 +for cmd_w_arg in 'mkdir dir' 'mknod b p' 'mkfifo f'; do + # In OpenBSD's /bin/sh, mknod is a shell built-in. + # Running via nice ensures we run our program and not the built-in. + nice -- $cmd_w_arg -Z $c 2 out fail=1 set $cmd_w_arg; cmd=$1 echo $cmd: $msg exp || fail=1 -- 1.5.5.56.gbcf7f ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Matthew Woehlke [EMAIL PROTECTED] wrote: Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/16/2008 6:30 AM: | My first reaction was great! that looks much better. | Unfortunately, the technique doesn't work with that shell: | | openbsd$ ./mknod --version|head -1 | mknod (GNU coreutils) 6.10.188-7cb24 | openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 | /bin/sh: mknod: --: unknown option | /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor | /bin/sh: mknod: usage: mknod [-m mode] name p That still uses a builtin. You need an exec in the loop to force a PATH search (even command, which bypasses functions, won't bypass builtins). Or perhaps a forwarding command will help; do any of these work? $ /bin/sh -c '(exec mknod --version)' | head -1 $ /bin/sh -c 'nice mknod --version' | head -1 $ /bin/sh -c 'nohup mknod --version' | head -1 I realize you already pushed something, but for the record, wouldn't env' work as well (and without the side effects)? Ha! Good call. That's even better ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Matthew Woehlke [EMAIL PROTECTED] wrote: $ /bin/sh -c '(exec mknod --version)' | head -1 $ /bin/sh -c 'nice mknod --version' | head -1 $ /bin/sh -c 'nohup mknod --version' | head -1 I realize you already pushed something, but for the record, wouldn't env' work as well (and without the side effects)? This simple test has certainly been beaten to death. I confirmed that it works. I'll push this soon. Holler if the attribution should be different. From 0d03baa068c20f09bcba3a915fd756db7359a7fa Mon Sep 17 00:00:00 2001 From: Matthew Woehlke [EMAIL PROTECTED] Date: Wed, 16 Apr 2008 19:15:05 +0200 Subject: [PATCH] tests: accommodate built-in mknod more cleanly still * tests/mkdir/selinux: Use env rather than nice. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- tests/mkdir/selinux |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/mkdir/selinux b/tests/mkdir/selinux index 45c2399..91b23b1 100755 --- a/tests/mkdir/selinux +++ b/tests/mkdir/selinux @@ -38,8 +38,8 @@ msg=failed to set default file creation context to \`$c': for cmd_w_arg in 'mkdir dir' 'mknod b p' 'mkfifo f'; do # In OpenBSD's /bin/sh, mknod is a shell built-in. - # Running via nice ensures we run our program and not the built-in. - nice -- $cmd_w_arg -Z $c 2 out fail=1 + # Running via env ensures we run our program and not the built-in. + env -- $cmd_w_arg -Z $c 2 out fail=1 set $cmd_w_arg; cmd=$1 echo $cmd: $msg exp || fail=1 -- 1.5.5.56.gbcf7f ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: avoid mkdir/selinux failure when mknod is a shell built-in
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 4/16/2008 6:30 AM: | My first reaction was great! that looks much better. | Unfortunately, the technique doesn't work with that shell: | | openbsd$ ./mknod --version|head -1 | mknod (GNU coreutils) 6.10.188-7cb24 | openbsd$ PATH=. /bin/sh -c 'mknod --version'|head -1 | /bin/sh: mknod: --: unknown option | /bin/sh: mknod: usage: mknod [-m mode] name [b | c] major minor | /bin/sh: mknod: usage: mknod [-m mode] name p That still uses a builtin. You need an exec in the loop to force a PATH search (even command, which bypasses functions, won't bypass builtins). Or perhaps a forwarding command will help; do any of these work? $ /bin/sh -c '(exec mknod --version)' | head -1 $ /bin/sh -c 'nice mknod --version' | head -1 $ /bin/sh -c 'nohup mknod --version' | head -1 I realize you already pushed something, but for the record, wouldn't 'env' work as well (and without the side effects)? -- Matthew pinotree uses the large trout on tsdgeos and PutHuhn :) PutHuhn runs tsdgeos lights a fire and eats the trout (with apologies to Pino Toscano, PutHuhn and Albert Astals Cid, who came up with this entirely on their own) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
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 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mknod bug -- null ptr dereference
Noch einmal, I sent the previous report too soon I suppose. The same bug also show up in mknod (with different arguments): -- [EMAIL PROTECTED]:src$ ./mknod -Za - p Segmentation fault -- - Daniel ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [EMAIL PROTECTED]: Re: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)]
Martin Pitt [EMAIL PROTECTED] writes: I do not see the issue for mkfifo -- what can possibly go wrong with open()ing and fchmod()ing a freshly created FIFO? If mkfifo opens the FIFO for reading, and some other process then opens the FIFO for writing without O_NONBLOCK, the other process will assume that the FIFO is ready for business and has a reader, even though it doesn't really. Anyway, this issue is no longer relevant for mkfifo or mknod. coreutils 6.1 mkfifo does not use chmod (or fchmod or lchmod or whatever). So its mkfifo is safe (in the sense described in the original bug report), and the patch is irrelevant for it. Likewise for mknod. Only mkdir is still unsafe. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #17427] CVE-2005-1039, chmod race in mkdir, mkfifo, mknod
Update of bug #17427 (project coreutils): Status:None = Wont Fix Open/Closed:Open = Closed ___ Follow-up Comment #1: [I also replied to the Debian bug list, but here's another copy.] This patch doesn't look safe to me. mkfifo and mknod should not open device files or fifos, since this has undesirable side effects in some cases. For example, opening and then closing a tape drive might rewind it. As I wrote in April 2005, the original security issue is not a vulnerability in coreutils; it's a problem inherent to the Unix model. We cannot fix it by patching coreutils (and hundreds of other utilities). We must simply say: users cannot rely on directories that are writeable by untrusted users, unless the directories are sticky and are owned by trusted users. Sorry, but that's life in the Unix/Linux world. That being said, mkdir can be made a bit safer. It cannot be made completely safe, though, in the sense that you're asking for, since in some cases mkdir won't be able to read the newly-created directory (and therefore can't open it) but POSIX still requires mkdir to chmod it in this case. Hence the patch you submitted here isn't quite right, since it sometimes gives up when it shouldn't. We have fixed mkdir a different way in coreutils test version 6.1 ftp://alpha.gnu.org/gnu/coreutils/coreutils-6.1.tar.gz, so that it uses fchmod if possible, and falls back on chmod otherwise. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17427 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #17427] CVE-2005-1039, chmod race in mkdir, mkfifo, mknod
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17427 Summary: CVE-2005-1039, chmod race in mkdir, mkfifo, mknod Project: GNU Core Utilities Submitted by: None Submitted on: Monday 08/14/2006 at 06:29 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: Hello! Attached is a patch to fix the race in mkdir, mkfifo, and mknod, as seen in CVE-2005-1039 when running with --mode. It is the same as the patch sent to Debian, where other details and discussion can be found: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304556 (sorry for the anonymous bug, Savanah doesn't appear to be delivering email to me today... Please CC [EMAIL PROTECTED]) Thanks! ___ File Attachments: --- Date: Monday 08/14/2006 at 06:29 UTC Name: coreutils-chmod-race.patch Size: 3.23KB By: None PATCH: solve mkdir/mkfifo/mknod --mode chmod race http://savannah.gnu.org/bugs/download.php?file_id=10533 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17427 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils mknod test fails if built in sgid directory
I happened to build coreutils in a directory that was sgid. This caused a test failure in the mknod test. The sgid bit propagates into the directory created testing mkdir. The sgid mode bit was unexpected by the test script and it failed. Here is the relevent code from the mknod test script: mkdir -m 734 f3 || fail=1 set _ `ls -dgo f3`; shift; mode=$1 test $mode = drwx-wxr-- || fail=1 Here is the trace with the failure: + mkdir -m 734 f3 ++ ls -dgo f3 + set _ drwx-wsr-- 2 48 2006-06-15 01:11 f3 + shift + mode=drwx-wsr-- + test drwx-wsr-- = drwx-wxr-- + fail=1 + exit 1 It seems like this should be a reasonable thing to allow. That was the only failure. Here is a trivial and obvious solution. test $mode = drwx-wxr-- || test $mode = drwx-wsr-- || fail=1 What do you think? Thanks Bob 2006-06-15 Bob Proulx [EMAIL PROTECTED] * tests/misc/mknod: Improve permission checks to handle running mkdir test in set-gid directories. Index: tests/misc/mknod === RCS file: /home/bob/src/coreutils-cvsroot/coreutils/tests/misc/mknod,v retrieving revision 1.1 diff -u -r1.1 mknod --- tests/misc/mknod19 Dec 2005 18:19:38 - 1.1 +++ tests/misc/mknod15 Jun 2006 07:36:35 - @@ -34,6 +34,6 @@ mkdir -m 734 f3 || fail=1 set _ `ls -dgo f3`; shift; mode=$1 -test $mode = drwx-wxr-- || fail=1 +test $mode = drwx-wxr-- || test $mode = drwx-wsr-- || fail=1 (exit $fail); exit $fail ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils mknod test fails if built in sgid directory
[EMAIL PROTECTED] (Bob Proulx) writes: * tests/misc/mknod: Improve permission checks to handle running mkdir test in set-gid directories. Thanks, I installed that on the trunk. This reflects a change in behavior to mkdir (for compatibility with Solaris) that is not in the 5.9x branch, so we shouldn't need the patch there. However, now that I've looked into it, we're still not quite compatible in a few odd cases, and in some cases both systems seem to be just plain wrong: $ uname -a SunOS lindbrook 5.8 Generic_117350-28 sun4u sparc SUNW,Sun-Fire-V440 $ ls -ld . drwxr-sr-x 2 eggert csfac 4096 Jun 15 11:22 . $ /bin/mkdir -m +t a $ gmkdir -m +t b $ ls -ld a b drwxrwsrwt 2 eggert csfac 4096 Jun 15 11:23 a drwxrwxrwt 2 eggert csfac 4096 Jun 15 11:23 b(*) $ /bin/mkdir -m g-s c $ gmkdir -m g-s d $ ls -ld c d drwxrwsrwx 2 eggert csfac 4096 Jun 15 11:23 c(*) drwxrwsrwx 2 eggert csfac 4096 Jun 15 11:23 d(*) I'd say that the outputs marked (*) are wrong, which means two bugs for GNU mkdir and one for Solaris mkdir. I'll take a look at the GNU code. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils mknod test fails if built in sgid directory
Paul Eggert wrote: Thanks, I installed that on the trunk. This reflects a change in behavior to mkdir (for compatibility with Solaris) that is not in the 5.9x branch, so we shouldn't need the patch there. That did fix the test failure. Works now. Thanks! I'd say that the outputs marked (*) are wrong, which means two bugs for GNU mkdir and one for Solaris mkdir. I'll take a look at the GNU code. Yep, looks like. Thanks for digging into them. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
documentation fix to match recent mkdir, mkfifo, mknod fixes
I installed this to fix the documentation to match the recent code fixes.
The install invocation fixes are just to make it more regular
2005-04-23 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (install invocation): Use a= instead of 0 for
the point of departure for -m, and explain what it meeams.
(mkdir invocation, mkfifo invocation, mknod invocation):
The umask does not affect the point of departure.
Problem reported by Mike Stone.
--- coreutils.texi 12 Apr 2005 05:42:55 - 1.250
+++ coreutils.texi 24 Apr 2005 04:46:33 - 1.251
@@ -7013,8 +7013,9 @@ may be either a group name or a numeric
@cindex permissions of installed files, setting
Set the permissions for the installed file or directory to @var{mode},
which can be either an octal number, or a symbolic mode as in
[EMAIL PROTECTED], with 0 as the point of departure (@pxref{File
-permissions}). The default mode is @samp{u=rwx,go=rx}---read, write,
[EMAIL PROTECTED], with @samp{a=} (no access allowed to anyone) as the
+point of departure (@pxref{File permissions}).
+The default mode is @samp{u=rwx,go=rx}---read, write,
and execute for the owner, and read and execute for group and other.
@item -o @var{owner}
@@ -7766,8 +7767,7 @@ The program accepts the following option
@cindex modes of created directories, setting
Set the mode of created directories to @var{mode}, which is symbolic as
in @command{chmod} and uses @samp{a=rwx} (read, write and execute allowed for
-everyone) minus the bits set in the umask for the point of the
-departure. @xref{File permissions}.
+everyone) for the point of the departure. @xref{File permissions}.
@item -p
@itemx --parents
@@ -7819,8 +7819,8 @@ The program accepts the following option
@opindex --mode
@cindex modes of created FIFOs, setting
Set the mode of created FIFOs to @var{mode}, which is symbolic as in
[EMAIL PROTECTED] and uses @samp{a=rw} (read and write allowed for everyone)
minus
-the bits set in the umask for the point of departure. @xref{File permissions}.
[EMAIL PROTECTED] and uses @samp{a=rw} (read and write allowed for everyone)
+for the point of departure. @xref{File permissions}.
@end table
@@ -7890,8 +7890,8 @@ The program accepts the following option
@opindex -m
@opindex --mode
Set the mode of created files to @var{mode}, which is symbolic as in
[EMAIL PROTECTED] and uses @samp{a=rw} minus the bits set in the umask as the
point
-of departure. @xref{File permissions}.
[EMAIL PROTECTED] and uses @samp{a=rw} as the point of departure.
[EMAIL PROTECTED] permissions}.
@end table
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
fixed obscure mkdir, mkfifo, mknod permissions problem
In a few obscure instances mkdir, mkfifo, and mknod create files with
incorrect permissions. For example:
$ umask 027
$ mkdir -m =+x a
$ ls -ld a
d--x--x--x 2 eggert eggert 4096 Apr 22 17:03 a
The permissions are wrong here. They should be d--x--x---.
I verified that Solaris 8 conforms to POSIX, so it's pretty clear that
this is a bug.
I installed the following patch.
I see no need for the second argument for mode_compile any more; all
programs that I know of assume that it's MODE_MASK_ALL, with the
exception of install where the value of that argument is immaterial
since install runs with umask(0). So I'm inclined to remove the
second argument, since I think its presence contributed to this
permissions bug. I'll ask about this on bug-gnulib first, though.
2005-04-22 Paul Eggert [EMAIL PROTECTED]
* NEWS: Fix bug with mkdir -m =+x dir; the umask was being ignored
when the +x was being evaluated.
* mkdir.c (main): Compile mode with MODE_MASK_ALL and initial umask.
* mkfifo.c (main): Likewise.
* mknod.c (main): Likewise.
* tests/mkdir/perm: Test for the above bug.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.276
diff -p -u -r1.276 NEWS
--- NEWS9 Apr 2005 04:51:11 - 1.276
+++ NEWS22 Apr 2005 23:50:46 -
@@ -44,6 +44,9 @@ GNU coreutils NEWS
ls now refuses to generate time stamps containing more than 1000 bytes, to
foil potential denial-of-service attacks on hosts with very large stacks.
+ mkdir -m =+x dir no longer ignores the umask when evaluating +x,
+ and similarly for mkfifo and mknod.
+
pr -D FORMAT now accepts the same formats that date +FORMAT does.
test now detects integer overflow when evaluating large integers,
Index: src/mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.91
diff -p -u -r1.91 mkdir.c
--- src/mkdir.c 21 Sep 2004 22:26:42 - 1.91
+++ src/mkdir.c 22 Apr 2005 23:50:53 -
@@ -82,7 +82,7 @@ int
main (int argc, char **argv)
{
mode_t newmode;
- mode_t parent_mode;
+ mode_t parent_mode IF_LINT (= 0);
const char *specified_mode = NULL;
const char *verbose_fmt_string = NULL;
int exit_status = EXIT_SUCCESS;
@@ -125,16 +125,9 @@ main (int argc, char **argv)
}
newmode = S_IRWXUGO;
- {
-mode_t umask_value = umask (0);
-umask (umask_value); /* Restore the old value. */
-parent_mode = (newmode (~ umask_value)) | S_IWUSR | S_IXUSR;
- }
-
if (specified_mode)
{
- struct mode_change *change = mode_compile (specified_mode, 0);
- newmode = ~ umask (0);
+ struct mode_change *change = mode_compile (specified_mode,
MODE_MASK_ALL);
if (change == MODE_INVALID)
error (EXIT_FAILURE, 0, _(invalid mode %s), quote (specified_mode));
else if (change == MODE_MEMORY_EXHAUSTED)
@@ -142,6 +135,14 @@ main (int argc, char **argv)
newmode = mode_adjust (newmode, change);
}
+ if (specified_mode || create_parents)
+{
+ mode_t umask_value = umask (0);
+ if (! specified_mode)
+ umask (umask_value);
+ parent_mode = (S_IRWXUGO ~umask_value) | (S_IWUSR | S_IXUSR);
+}
+
for (; optind argc; ++optind)
{
bool ok;
Index: src/mkfifo.c
===
RCS file: /fetish/cu/src/mkfifo.c,v
retrieving revision 1.73
diff -p -u -r1.73 mkfifo.c
--- src/mkfifo.c21 Sep 2004 22:26:42 - 1.73
+++ src/mkfifo.c22 Apr 2005 23:50:53 -
@@ -116,13 +116,13 @@ main (int argc, char **argv)
newmode = (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
if (specified_mode)
{
- newmode = ~ umask (0);
- change = mode_compile (specified_mode, 0);
+ change = mode_compile (specified_mode, MODE_MASK_ALL);
if (change == MODE_INVALID)
error (EXIT_FAILURE, 0, _(invalid mode));
else if (change == MODE_MEMORY_EXHAUSTED)
xalloc_die ();
newmode = mode_adjust (newmode, change);
+ umask (0);
}
for (; optind argc; ++optind)
Index: src/mknod.c
===
RCS file: /fetish/cu/src/mknod.c,v
retrieving revision 1.84
diff -p -u -r1.84 mknod.c
--- src/mknod.c 21 Sep 2004 22:26:42 - 1.84
+++ src/mknod.c 22 Apr 2005 23:50:53 -
@@ -121,13 +121,13 @@ main (int argc, char **argv)
newmode = (S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH);
if (specified_mode)
{
- newmode = ~ umask (0);
- change = mode_compile (specified_mode, 0);
+ change = mode_compile (specified_mode, MODE_MASK_ALL);
if (change == MODE_INVALID)
error (EXIT_FAILURE, 0, _(invalid mode));
else if (change == MODE_MEMORY_EXHAUSTED)
xalloc_die
Re: mknod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Costa on 4/14/2005 8:07 AM: Hi Everybody, I have a problem on cygwin: You should ask this question on the cygwin mailing list, [EMAIL PROTECTED] mknod pipe p POSIX states that named pipes (aka fifos) are only portable if used in one direction (ie. you can't open them read-write and expect portable results). Beyond that, named pipes are a relatively new addition to cygwin, and there are still bugs being ironed out. For example, $ mkfifo f # shorthand for mknod f p $ ls -iF f 1125899907358221 f| $ mv f f1 $ ls -iF f1 1125899907358221 f1 preserves the inode, but changes the file type from pipe to a regular file (read-only at that). - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXwZS84KuGfSFAYARAl30AKCir40E0f1Y5SySvAmXN6GNk62dMgCg1kN7 b4tS9djYzJ84Z0z6j+oZWvM= =2Kee -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
My kneejerk reaction is that it's not worth making this change. The attack in question will work against almost any program that is operated in an insecure directory, including the chmod program itself. It'd be a real pain to work around this problem in all applications, one at a time, and it's not at all clear to me that it's even doable in general. I suggest simply warning users that if you let bad guys modify your directories, you're asking for trouble. Which is certainly true in any event. That being said, it would be an easy security improvement if mkdir -m would use lchmod rather than chmod, on platforms where lchmod is available. There may be several other programs where this would be advisable as well, and similarly for lchown versus chown. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
Paul Eggert [EMAIL PROTECTED] wrote: My kneejerk reaction is that it's not worth making this change. The attack in question will work against almost any program that is operated in an insecure directory, including the chmod program itself. It'd be a real pain to work around this problem in all applications, one at a time, and it's not at all clear to me that it's even doable in general. I suggest simply warning users that if you let bad guys modify your directories, you're asking for trouble. Which is certainly true in any event. That being said, it would be an easy security improvement if mkdir -m would use lchmod rather than chmod, on platforms where lchmod is available. There may be several other programs where this would be advisable as well, and similarly for lchown versus chown. I would be more interested in that approach if I knew that lchmod support were coming to Linux sometime soon. I see that NetBSD, OpenBSD, HPUX (but not Solaris) provide it. This reminds me of Solaris' very nice openat, fdopendir, fstatat functions[1]. They too provide useful functionality that can't be emulated cleanly, yet Linux doesn't provide the necessary syscalls. I suppose a weak replacement function is the `right' way to go -- then, as for openat, redirect complaints to the Linux kernel folks. Jim -- [1] I'm not interested in attribute-related semantics of openat, but rather in the fd-relative-open--related semantics. openat et.al. are very useful in any code that would otherwise have to change to a new directory and then later return to the initial working directory. No code that tries to do that with chdir (or even with open/fchdir) can be truly robust, but it's easy with openat and company. The problem is that sometimes it is impossible to return, even with open/fchdir. With openat, you define away the problem by making it unnecessary to change the current working directory. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#304556: file permissions race in mkdir, mknod, mkfifo (CAN-2005-1039)
Joey Hess [EMAIL PROTECTED] wrote:
Package: coreutils
Version: 5.2.1-2
Severity: important
Tags: security
Our coreutils seems to be vulnerable to the problem described in
CAN-2005-1039.
http://www.securityfocus.com/archive/1/395489
A quick strace of mkdir -m 400 foo shows the problem:
mkdir(foo, 0400) = 0
chmod(foo, 0400) = 0
So if this is run in a directory where the attacker has access, such as
a group writable directory (as commonly used for teams in eg, the Debian
project; on alioth, etc), then the attacker can race between the mkdir
and chmod calls, (re)moving the new directory and replacing it with a
symlink to a file or directory owned by the user who ran mkdir. The
chmod will then follow the symlink and act on that directory. And
similar for the other commands.
A fix would be to create the directory/device with the right perms
and not chmod it again afterwards.
Thanks for the report.
FYI, one approach to `fixing' this would cause problems.
For example, the following patch looks like an improvement,
but it would introduce a bug:
Index: mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.91
diff -u -p -r1.91 mkdir.c
--- mkdir.c 21 Sep 2004 22:26:42 - 1.91
+++ mkdir.c 14 Apr 2005 11:43:31 -
@@ -183,6 +183,7 @@ main (int argc, char **argv)
been created. */
if (ok specified_mode dir_created
+ (newmode ~S_IRWXUGO)
chmod (dir, newmode) != 0)
{
error (0, errno, _(cannot set permissions of directory %s),
If the affected directory's parent has a default ACL or has the set group
ID bit set, then the chmod may be required e.g., to reset the inherited
set group ID bit or to adjust any S_IRWXUGO bits that were changed via
the default ACL.
An alternative approach is to lstat the new directory, compare its mode to
the desired mode and then, only if necessary, call chmod. But this still
leaves the race-window open.
The only raceless approach I can see is to lstat the name, open it,
fstat its file descriptor, compare the dev/inode with those from lstat,
check the mode, and if needed, call fchmod. But that too can fail:
if the new directory is not readable by the user who just created it,
then the open will fail. But when setting such restrictive permissions,
resorting to the use of the race-vulnerable lstat+chown isn't a big deal.
But now we're talking about pretty much more code and a little added cost
(always call lstat,open,fstat,and-maybe-fchmod rather than just chmod).
All for a theoretically exploitable race condition.
Is it worth it in this case?
Opinions welcome.
For reference, here's a possible patch, relative to the upstream repository:
(I'm not sure I like the idea of calling chown upon failed open.
Also, I wouldn't really put this code in mkdir.c -- it'd be used
by mknod.c and mkfifo.c, too. )
Index: mkdir.c
===
RCS file: /fetish/cu/src/mkdir.c,v
retrieving revision 1.91
diff -u -p -r1.91 mkdir.c
--- mkdir.c 21 Sep 2004 22:26:42 - 1.91
+++ mkdir.c 14 Apr 2005 14:21:43 -
@@ -1,5 +1,5 @@
/* mkdir -- make directories
- Copyright (C) 90, 1995-2002, 2004 Free Software Foundation, Inc.
+ Copyright (C) 90, 1995-2002, 2004, 2005 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -28,6 +28,7 @@
#include makepath.h
#include modechange.h
#include quote.h
+#include unistd-safer.h
/* The official name of this program (e.g., no `g' prefix). */
#define PROGRAM_NAME mkdir
@@ -78,6 +79,79 @@ Mandatory arguments to long options are
exit (status);
}
+/* Call fchmod(2) on FILE only after ensuring that the file system
+ object to be modified is not a symbolic link.
+ If anything goes wrong,
+ - FILE is a symlink (set errno to EINVAL)
+ - failed system call
+ - FILE changed dev/inode between lstat and open calls (set errno to
EINVAL)
+ skip the fchmod and return -1. Otherwise, return 0.
+ In most cases, there is no possibility for an attacker to replace FILE
+ with say, a symlink, to cause the permissions of some other file to be
+ affected, but if FILE cannot be opened, we go ahead and call chown
+ directly.
+
+ This function is intended to be called on a FILE that has just been
+ created, and that may already have its mode set to MODE. In the
+ relatively unusual case that MODE does not reflect the permissions
+ of FILE, then we set them. */
+
+int
+safe_chmod (char const *file, mode_t mode)
+{
+ struct stat lstat_stats;
+ struct stat fstat_stats;
+ int fd;
+
+ if (lstat (file, lstat_stats) != 0)
+return -1;
+
+ if (S_ISLNK (lstat_stats.st_mode))
+{
+ errno = EINVAL;
+
