dir_create() alters umask

[wch]

Example:

Sys.umask()
#> [1] "22"
fs::dir_create('foo')
Sys.umask()
#> [1] "0"

Any files created after this point will be world readable and writable. For example:

writeLines('abc', 'temp.txt')
file.mode('temp.txt')
#> [1] "666"

[jimhester]

Is this a duplicate of #284?

[wch]

I think it was created by the fix for that issue, and the problem is this line:

fs/src/dir.cc

Line 18 in 93e70a9

process_umask = umask(0);

[jimhester]

Yeah I see the issue from the man page now https://man7.org/linux/man-pages/man2/umask.2.html

It is impossible to use umask() to fetch a process's umask without at
the same time changing it. A second call to umask() would then be
needed to restore the umask.

So we need to reset it after the fact.

[wch]

That's such a weird interface, and it sounds like it could cause problems when there are multiple threads.

(I mean the way that umask() works -- there's no way to check it without also setting it.)

[jimhester]

Yes I agree, but I don't think there is any other way we can do it. I tweaked when we do this and added a test in 857a814

[wch]

Sorry to keep pressing on this, but as long as the global umask is being altered, I think it would be safer to:

• Call umask() with a more restrictive value (instead of less restrictive)
• Immediately set it back to the original value
• Call chmod on the directory after creating it

The way things currently work, if there's a networked filesystem, the time between the two umask() calls could be significant, and it would be best to be as safe as possible.

[jimhester]

If we are calling chmod then we might as well forget about umask entirely.

[wch]

I was thinking you'd still set the mode based on INTEGER(mode_sxp)[0] & ~process_umask.

I figured the umask stuff was there so you would respect the process umask (and not just set the permissions to whatever the user has requested) but I might not be fully understanding how this all works.