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.
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
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.
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
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
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
-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
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
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
-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
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
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
-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
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
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
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
$ ./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
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
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
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
[ 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
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
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
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
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
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
[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
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
, 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
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
-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
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
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
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:
34 matches
Mail list logo
