os.MkDir and permission bits.

[Ignacio Grande]

Hi.

I'm posting this message here as suggested by Ian Lance in this issue: https://github.com/golang/go/issues/15210

A few months ago I made the same comment on Stack Overflow and I was "scolded" for not knowing how umask works.

In short, you need to provide to os.MkDir and os.MiDirAll the permission bits of the directory, but (at least on Linux) the directory is created using the umask bits, with no error. I was told that this is the expected behavior.

However, I'm still unsure if this is the intended behavior or at least, if the documentation is consistent as it is know:

Mkdir creates a new directory with the specified name and permission bits. If there is an error, it will be of type *PathError.

I see two inconsistencies:

1. The permissions provided may or may not be used. I don't know in which conditions they will be used. For example different Linux distributions or installations may have different umask values and the behavior will be different, with no error messages.
2. Linux mkdir accepts an optional mode using -m. I'm not sure if it is supposed to work everywhere but I tested in a couple of distributions and it works as expected (that is, it sets the provided permissions). If os.MkDir rationale is to mimic Linuxs mkdir, this would be different.
   

I'd be glad to hear the developer's thoughts about this (I'd not mind if I'm scolded again ;) )

Best regards.

 

[Steven Hartland]

IMO the documentation should be improved including mentioning that is applies OS specific rules when applying the permissions, such as umask on Unix OS's.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

On Sun, Mar 26, 2017 at 6:06 AM, Ignacio Grande <ncc17...@gmail.com> wrote:
>
> I'm posting this message here as suggested by Ian Lance in this issue:
> https://github.com/golang/go/issues/15210
>
> A few months ago I made the same comment on Stack Overflow and I was
> "scolded" for not knowing how umask works.
>
> In short, you need to provide to os.MkDir and os.MiDirAll the permission
> bits of the directory, but (at least on Linux) the directory is created
> using the umask bits, with no error. I was told that this is the expected
> behavior.
>
> However, I'm still unsure if this is the intended behavior or at least, if
> the documentation is consistent as it is know:
>
> Mkdir creates a new directory with the specified name and permission bits.
> If there is an error, it will be of type *PathError.
>
> I see two inconsistencies:
>
> The permissions provided may or may not be used. I don't know in which
> conditions they will be used. For example different Linux distributions or
> installations may have different umask values and the behavior will be
> different, with no error messages.

The permissions provided are always used. They are modified by the
process's umask.

> Linux mkdir accepts an optional mode using -m. I'm not sure if it is
> supposed to work everywhere but I tested in a couple of distributions and it
> works as expected (that is, it sets the provided permissions). If os.MkDir
> rationale is to mimic Linuxs mkdir, this would be different.

os.Mkdir is intended to mimic the mkdir C library call, not the mkdir
command: http://man7.org/linux/man-pages/man2/mkdir.2.html .

Ian

[Ian Lance Taylor]

On Sun, Mar 26, 2017 at 12:00 PM, Steven Hartland
<ste...@multiplay.co.uk> wrote:
> IMO the documentation should be improved including mentioning that is
> applies OS specific rules when applying the permissions, such as umask on
> Unix OS's.

The question is whether we should mention the umask for every single
function call that it affects, or whether there should be some
Unix-specific section somewhere in the os package docs that mentions
the umask.

Ian

[Rob Pike]

Or whether we should mention umask at all. As a reference point we do not describe how the permission bits work anywhere, so there isn't even a foundation in place on which to talk about umask.

I believe this is not a Go issue.

-rob

> email to golang-dev+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to golang-dev+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[Rob Pike]

Or to put it another way, this is a Unix documentation issue, not a Go one.

-rob

[Manlio Perillo]

However, for portable applications the fact is that, on some operating systems, the specified permission bits may be changed to a more restrictive value by the system.

Manlio

> email to golang-dev+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to golang-dev+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[Ralph Corderoy]

Hi Manlio,

> However, for portable applications the fact is that, on some operating
> systems, the specified permission bits may be changed to a more
> restrictive value by the system.

And some common Linux filesystems may impose further constraints, e.g.
no group-write bit, but I don't think that should be a warning.

$ umask 0
$ sudo mkdir -m 775 d
$ ls -ld d
drwxr-xr-x 2 root root 2048 Mar 27 16:39 d
$ sudo chmod 775 d
$ ls -ld d
drwxr-xr-x 2 root root 2048 Mar 27 16:39 d
$ umask
0000
$

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[Steven Hartland]

Unfortunately when using a language like go, users often don't understand the lower levels, for right or wrong, especially when using the standard library calls such as "os" and not the lower level "syscall" package; were it could more easily be argued that the user should know what they are doing.

Given this I'd still argue that mentioning OS specific rules when applying permissions would help, that's what documentation is for ;-)

You could draw similarities to how os.Executable() mentions that it's
not supported on nacl or OpenBSD (unless procfs is mounted)

Yes in this case its more about implementation detail but unless you look you don't know that os.Chmod doesn't also try to ensure the correct permissions by checking that the requested permission match the granted ones; and you could argue that a high level library might be expected to do that to ensure consistency.

As far as finding a good place to document it, it could be mentioned for each call that sets permissions or just on os.FileMode such, which is linked.

I don't think it should go into detail but simply:
When setting a file mode permission the underlying OS or filesystem may apply additional constraints, such as the filter applied by umask on Unix systems.

    Regards
    Steve

[Rob Pike]

I don't think so. Every operating system operation has nuances and it's not our job to explain them. This edit is reasonable in isolation but there are countless other examples of such things we could explain in the Go documentation. It's an impossible bar to meet, especially in an explicitly portable operating system interface.

-rob

[Steven Hartland]

I totally agree its not Go's job to document every nuance of each OS. However I do believe adding helpful pointers to key functionality, which can have confusing behaviour to the uninitiated, would help eliminate surprises and improve Go's accessibility.

Even if this took the form of some preamble in the os package, clarifying that a uniform interface across all operating systems is not always possible and points to some sort of external docs which can provide some detail, I think this would definitely be useful.

I always remember that one of key things which attracted us to golang was its portability, and as such you'll have people coming in from all sorts of backgrounds such as Windows were umask doesn't exist.

    Regards
    Steve

[brainman]

os.Mkdir perm parameter is ignored on windows.

Alex

[Nacho]

A comment on the preamble would be nice, or a comment in os.MkDir and related functions saying that it behaves like C's mkdir. By the way, os.Create right now mentions umask: Create creates the named file with mode 0666 (before umask), truncating it if it already exists.

On Tue, Mar 28, 2017 at 7:33 AM, Steven Hartland <ste...@multiplay.co.uk> wrote:

I totally agree its not Go's job to document every nuance of each OS. However I do believe adding helpful pointers to key functionality, which can have confusing behaviour to the uninitiated, would help eliminate surprises and improve Go's accessibility.

Even if this took the form of some preamble in the os package, clarifying that a uniform interface across all operating systems is not always possible and points to some sort of external docs which can provide some detail, I think this would definitely be useful.

I always remember that one of key things which attracted us to golang was its portability, and as such you'll have people coming in from all sorts of backgrounds such as Windows were umask doesn't exist.

    Regards
    Steve

You received this message because you are subscribed to a topic in the Google Groups "golang-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-dev/TXlDtwxaTcM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-dev+unsubscribe@googlegroups.com.