Fix default permissions in UnixFileStream#6797
Conversation
We currently have UnixFileStream create new files with the permissions 700. This doesn't map to what's commonly expected on Unix, where most utilities default instead to 666. This commit changes the default to be 766, which attempts to map to what's commonly expected on Unix, while also factoring in the default on Windows, where a new file can be executed by default. All of these permissions are of course subject to the system's umask, such that the actual permissions applied will likely be less than what's specified. The commit also fixes up some code in X509Certificates, which was coded to rely on the more limited permissions being applied.
|
@blowdart does this make you happy, sad, or indifferent? 😄 |
|
When am I ever happy? :D So what are you writing that needs execute permission on them? I suggest making the FileStream on windows more restrictive by default, to match 666 |
I didn't know that NTFS had a no-execute mode... but that'd probably come as quite a shock to people if we used it :). |
|
@stephentoub The change LGTM, in that it matches our offline discussion. Since it's the same as the default for redirection, mkdir, etc, I think we're probably good here; given the X509 lockdown you did for me. |
|
Damnit I was happy. And yea, I figured Traverse Folder / Execute File would be it, but it doesn't do what I expect. It only disables running in explorer for bats, exes and other things. Darn it. |
|
Thanks, guys. |
Fix default permissions in UnixFileStream
|
|
||
| // If the file gets created a new, we'll select the permissions for it. Most utilities by default use 666 (read and | ||
| // write for all). However, on Windows it's possible to write out a file and then execute it. To maintain that similarity, | ||
| // we use 766, so that in additoin the user has execute privileges. No matter what we choose, it'll be subject to the umask |
There was a problem hiding this comment.
NIT: "additoin" (Sorry, but when I catch a spelling error, I feel obligated to point it out...)
Fix default permissions in UnixFileStream Commit migrated from dotnet/corefx@529bc34
6 participants
We currently have UnixFileStream create new files with the permissions 700. This doesn't map to what's commonly expected on Unix, where most utilities default instead to at least 666.
This commit changes the default to be 766, which attempts to map to what's commonly expected on Unix, while also factoring in the default on Windows, where a new FileStream's output can be executed by default. All of these permissions are of course subject to the system's umask, such that the actual permissions applied will likely be less than what's specified.
The commit also fixes up some code in X509Certificates, which was coded to rely on the more limited permissions being applied.
cc: @bartonjs, @ianhays