GNU bug report logs - #21534
Bug in mkdir?!

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21534 in the body.
You can then email your comments to 21534 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Unger <sebunger44 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Bug in mkdir?!
Date: Tue, 22 Sep 2015 22:29:44 +1200

[Message part 1 (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 2 (text/html, inline)]

Message #10 received at 21534-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sebastian Unger <sebunger44 <at> gmail.com>, 21534-done <at> debbugs.gnu.org
Subject: Re: bug#21534: Bug in mkdir?!
Date: Tue, 22 Sep 2015 20:09:35 -0700

[Message part 1 (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 #13 received at 21534-done <at> debbugs.gnu.org (full text, mbox):

From: Sebastian Unger <sebunger44 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 21534-done <at> debbugs.gnu.org
Subject: Re: bug#21534: Bug in mkdir?!
Date: Wed, 23 Sep 2015 16:02:11 +1200

[Message part 1 (text/plain, inline)]

Hi Paul,

First of all thanks for the exceptionally quick response & fix. The mode of
the file system isn't so much a security feature but a reflection of its
functionality: As you drop files into a particular area, they are moved
somewhere else under the hood by the fuse. But given what you are saying
about expecting issues like this with more tools, I may actually make
directories readable to avoid issues.

You did get my name ever so slightly wrong in the patch, but if that's
already committed, then don't bother with it.

Cheers,
Seb

On 23 September 2015 at 15:09, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> 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.
>

[Message part 2 (text/html, inline)]

Message #16 received at 21534-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Sebastian Unger <sebunger44 <at> gmail.com>
Cc: 21534-done <at> debbugs.gnu.org
Subject: Re: bug#21534: Bug in mkdir?!
Date: Wed, 23 Sep 2015 08:12:26 -0700

[Message part 1 (text/plain, inline)]

On 09/22/2015 09:02 PM, Sebastian Unger wrote:
> You did get my name ever so slightly wrong in the patch

Oh, sorry!  That's embarrassing.  Fixed with the attached patch.

[0001-Fix-ChangeLog-typo.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.