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 bug report
#21534: Bug in mkdir?!
which was filed against the coreutils package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 21534 <at> debbugs.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)]
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)]
[Message part 5 (message/rfc822, inline)]
[Message part 6 (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 7 (text/html, inline)]
This bug report was last modified 9 years and 299 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.