[debbugs-tracker] bug#21534: closed (Bug in mkdir?!)

[GNU bug Tracking System]

Your message dated Tue, 22 Sep 2015 20:09:35 -0700
with message-id <address@hidden>
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
address@hidden)


-- 
21534: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21534
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: Bug in mkdir?! Date: Tue, 22 Sep 2015 22:29:44 +1200

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)                                = 022
mkdir("a", 0755)                        = 0
open("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) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a86f20000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x7f6a86f20000, 4096)            = 0
open("/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) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=619, ...}) = 0
mmap(NULL, 619, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f6a86f20000
close(3)                                = 0
open("/usr/lib/charset.alias", O_RDONLY|O_NOFOLLOW) = -1 ENOENT (No such file or directory)
write(2, "mkdir: ", 7mkdir: )                  = 7
write(2, "cannot create directory \342\200\230a\342\200\231", 31cannot create directory ‘a’) = 31
open("/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)     = 19
write(2, "\n", 1
)                       = 1
close(1)                                = 0
close(2)                                = 0
exit_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)                                = 0466
mkdir("a", 0311)                        = 0
open("a", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES (Permission denied)
chdir("a")                              = 0
mkdir("b", 0311)                        = 0
open("b", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW) = -1 EACCES (Permission denied)
chdir("b")                              = 0
mkdir("c", 0311)                        = 0
close(1)                                = 0
close(2)                                = 0
exit_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

--- End Message ---

--- Begin Message --- Subject: Re: bug#21534: Bug in mkdir?! Date: Tue, 22 Sep 2015 20:09:35 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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
Description: Text document

--- End Message ---