cc @jayconrod like the other bug.

Same question here: is there anything to actively do for this issue? (Should we leave it open, or close it and just use it as a point of reference?)

Hmm... At the very least, the documentation for os.Chmod should be updated.
It currently says:

On Windows, only the 0200 bit (owner writable) of mode is used; it controls whether the file's read-only attribute is set or cleared. The other bits are currently unused. For compatibility with Go 1.12 and earlier, use a non-zero mode. Use mode 0400 for a read-only file and 0600 for a readable+writable file.

It notably does not mention any behavior for directories.

Windows files and directory permissions cannot be mapped onto Unix user/group/everyone + read/write/execute. Most Windows users don't care about file permissions - as long as their files inherit permissions of containing directories, most things just work. For anything unusual Windows Go users would have to use Windows APIs directly.

More documentation is not always better. If documentation is long, people won't read it.

But we should correct wrong documentation.

Alex

I'm in way over my head, but from what I can tell there may be a reasonable mapping of the unix “write” permission bit to the windows ACTRL_DIR_CREATE_OBJECT, ACTRL_DIR_CREATE_CHILD or ACTRL_DS_CREATE_CHILD, and ACTRL_DIR_DELETE_CHILD or ACTRL_DS_DELETE_CHILD permissions.

Similarly, the execute bit might reasonably map to ACTRL_DIR_TRAVERSE or ACTRL_DS_LIST.

(But none of that is to say that we should actually implement that mapping.)

I'm in way over my head,

Same here. I will let Jason reply to you, if he wants to. I think we should leave things as they are.

Alex

I'm in way over my head, but from what I can tell there may be a reasonable mapping of the unix “write” permission bit to the windows ACTRL_DIR_CREATE_OBJECT, ACTRL_DIR_CREATE_CHILD or ACTRL_DS_CREATE_CHILD, and ACTRL_DIR_DELETE_CHILD or ACTRL_DS_DELETE_CHILD permissions.

Similarly, the execute bit might reasonably map to ACTRL_DIR_TRAVERSE or ACTRL_DS_LIST.

(But none of that is to say that we should actually implement that mapping.)

Mapping Unix permission bits to Windows ACLs probably makes more sense than what we do now, which is mapping a single Unix permission bit to a "file attribute", which is not an ACL (and apparently doesn't work for directories either).

I think there probably would be a quasi coherent scheme we could come up with, for all of user, group, and world, and maybe even for the sticky bit. It would map better than what we currently have and would wind up supporting things like directories.

But it does certainly require more than a moment's thought. As with most things Windows, the devil is in the details.

The actual implementation would wind up looking something like:

func unixPermToSA(perm FileMode) *SECURITY_ATTRIBUTES
func saToUnixPerm(sa *SECURITY_ATTRIBUTES) FileMode

And then all of the various Windows file creation and retrieval functions will take or return a security attribute struct, which we're currently passing in as nil.

But, as I said, the devil is really in the details, and there are tons of unanswered questions. Then, let's say we get the mapping down. Do we want to emulate umask too? Probably, since people tend to pass in 0666 rather than 0644. So now we're doing umask emulation...

It all seems possible to do, but probably hard, and risky if it's not done right. So maybe this kind of project is best deferred until somebody actually complains compellingly about the status quo.

@jstarks has Microsoft published a guide re mapping Unix filemode to/from Windows security_attributes? Or is there .NET code to handle this?

There is no such document that I am aware of.

I don't think you want to try to do anything automatic with ACLs. You're unlikely to come up with a policy that will make everyone happy.