GNU bug report logs -
#21534
Bug in mkdir?!
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 22 Sep 2015 20:09:35 -0700
with message-id <560217EF.4050807 <at> cs.ucla.edu>
and subject line Re: bug#21534: Bug in mkdir?!
has caused the debbugs.gnu.org bug report #21534,
regarding Bug in mkdir?!
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
21534: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21534
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Hi,
I'm working on a little project of mine involving a Fuse file system on
Linux. I'm having a problem where mkdir from coreutils fails with
Permission denied while mkdir from busybox works.
I'm running the command *mkdir -p a/b/c* and I get the following strace
output (showing only the relevant lines at the end):
*umask(0) = 022mkdir("a",
0755) = 0open("a",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)open("/usr/share/locale/locale.alias",
O_RDONLY|O_CLOEXEC) = 3fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...})
= 0mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f6a86f20000read(3, "# Locale name alias data base.\n#"..., 4096) =
2570read(3, "", 4096) =
0close(3) = 0munmap(0x7f6a86f20000,
4096) =
0open("/usr/share/locale/en_NZ/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1
ENOENT (No such file or
directory)open("/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) =
-1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en_NZ/LC_MESSAGES/coreutils.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en/LC_MESSAGES/coreutils.mo",
O_RDONLY) = 3fstat(3, {st_mode=S_IFREG|0644, st_size=619, ...}) =
0mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f6a86f20000close(3) =
0open("/usr/lib/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such
file or directory)write(2, "mkdir: ", 7mkdir: ) =
7write(2, "cannot create directory \342\200\230a\342\200\231", 31cannot
create directory ‘a’) =
31open("/usr/share/locale/en_NZ/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)open("/usr/share/locale/en/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en_NZ/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or
directory)open("/usr/share/locale-langpack/en/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)write(2, ": Permission
denied", 19: Permission denied) = 19write(2, "\n",
1) = 1close(1) =
0close(2) =
0exit_group(1) = ?+++ exited with 1 +++*
Please note that while the creation of directory 'a' succeeds, the
directory is created by the fuse with mode 0311 (-wx--x--x) and as such the
open call following the mkdir fails as expected.
If I try to simulate this on a normal file system by setting the umask to
0466, I get the following strace output:
*umask(0) = 0466mkdir("a",
0311) = 0open("a",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)chdir("a") = 0mkdir("b",
0311) = 0open("b",
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES
(Permission denied)chdir("b") = 0mkdir("c",
0311) = 0close(1) =
0close(2) =
0exit_group(0) = ?+++ exited with 0 +++*
I.e. the open still fails but apparently mkdir can live with it. Since it
also works on my fuse if I set the umask to 0466, I conclude that mkdir
inspects the umask to see if it expects to be able to open the directory?!
That sounds like a race to me since anything may change the mode of the
directory between the mkdir and open calls even on a normal FS and even
more so on a networked file system. Why is it trying to open the directory
in the first place? Shouldn't it just chdir into it and carry on?
Is this a bug or expected behaviour? Any ideas as to how to make mkdir
behave?
Cheers,
Seb
[Message part 4 (text/html, inline)]
[Message part 5 (message/rfc822, inline)]
[Message part 6 (text/plain, inline)]
Sebastian Unger wrote:
> Why is it trying to open the directory
> in the first place?
Security.
Apparently POSIX doesn't allow this level of paranoia for mkdir -p, so I removed
it in the attached Gnulib patch, and this should appear in the next coreutils
release.
A filesystem that doesn't let you read your own directory that you just created
is likely to run into other problems like this -- i.e., the practice may
introduce more security problems than it closes. But I digress.
[0001-savewd-remove-SAVEWD_CHDIR_READABLE.patch (text/plain, attachment)]
This bug report was last modified 9 years and 300 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.