On Wed, Dec 13, 2017 at 5:46 AM, <matthijskooij...@gmail.com> wrote:
>
> I just ran into some inconsistencies wrt permissions and `os.Mkdir()`, at
> least on Linux. I'm not sure what part of this is actual bugs that need to
> be fixed and what is a documentation bug, but let me state what I've found.
>
> The documentation for Mkdir says: "Mkdir creates a new directory with the
> specified name and permission bits.". To me, this suggests that any
> permissions would be applied as-is, with no further processing. However, in
> practice, on at least Linux and probably other unices, the umask is applied:
>
> matthijs@grubby:/tmp$ cat test.go
> package main
> import "os"
> func main() {
> os.Mkdir("/tmp/foo", 0770)
> }
> matthijs@grubby:/tmp$ go build test.go
> matthijs@grubby:/tmp$ ./test
> matthijs@grubby:/tmp$ ls -ld foo
> drwxr-x--- 2 matthijs matthijs 4096 Dec 13 14:25 foo (Note missing g+w
> bit)
> matthijs@grubby:/tmp$ rmdir foo
> matthijs@grubby:/tmp$ umask 0
> matthijs@grubby:/tmp$ ./test
> matthijs@grubby:/tmp$ ls -ld foo
> drwxrwx--- 2 matthijs matthijs 4096 Dec 13 14:25 foo (Note permissions
> are as requested)
> matthijs@grubby:/tmp$ umask 777
> matthijs@grubby:/tmp$ rmdir foo
> matthijs@grubby:/tmp$ ./test
> matthijs@grubby:/tmp$ ls -ld foo
> d--------- 2 matthijs matthijs 4096 Dec 13 14:25 foo (Note all
> permissions masked away)
>
> By itself, this is not uncommon for mkdir, it's just calling the mkdir
> syscall, so it behaves the same as the libc mkdir as well. This suggests
> this is merely a documentation bug.
>
> However, when looking at the source for Mkdir, I find:
>
> // mkdir(2) itself won't handle the sticky bit on *BSD and Solari
> if !supportsCreateWithStickyBit && perm&ModeSticky != 0 {
> Chmod(name, perm)
> }
>
> This means that, on BSD platforms (which also have umask), an explicit Chmod
> happens using the passed permissions, completely bypassing umask. This is at
> least inconsistent and surprising, and could be a security problem in some
> cases.
>
>
> I also suspect that both of these problems exist exactly like this for
> OpenFile (I assume OpenFile also adheres to umask without this being
> documented, and it also special cases for the sticky bit).
>
> As suggested by the docs, I'm asking here before filing a bug, since I'm not
> sure what the exact bug and path forward should be from here. Making the
> permission argument behave as documented and always running a chmod seems
> like an obvious fix, but that completely breaks compatibility, likely
> resulting in security problems, so that seems out of the question...
>
> A backward compatible fix in user code would be to just pass 0 as the
> permission to Mkdir or OpenFile, and then manually Chmod to whatever value
> is needed, which should be secure and work in most cases (except when some
> other process is waiting for the directory or file to be created, exposing a
> race condition).
I think the inconsistency in the handling of umask on *BSD systems is
a bug. Please open an issue for that at https://golang.org/issue.
We've discussed in the past how much to document umask in the os
package. After all, umask is a standard part of Unix operating
systems, and has no equivalent on non-Unix systems. We do mention
umask very briefly in the docs for the Create function, and have done
so since the function was introduced in https://golang.org/cl/4357052.
I would be fine with a similar brief mention in the Mkdir docs.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
