-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Directories created via pebble with requested permissions 0777 get created with 0775 instead #80
Comments
I ran into this too, and someone told me about umask. I suspect that's what's happening here too, as umask is often 2, which would cause 0777 to change to 0775. See also https://askubuntu.com/questions/44542/what-is-umask-and-how-does-it-work So this is not a Pebble issue, but a feature of how Linux handles file permissions with umask. |
I understand about umask, and yes, it's true this is the default behavior, but I want to challenge slightly that "this is not a Pebble issue". By having a permissions option, the API feels like it has chmod-like capabilities. If I run chmod as a normal user, I don't have to "umask 0" before being able to "chmod 777 $file" - the chmod command is enough and does the right thing. If permissions aren't supplied, fine, I'm OK with umask being applied - Pebble is (probably) creating a new file on its filesystem, and it makes sense for the purpose of applying default permissions. But when permissions are explicitly provided, applying umask to the requested permissions before doing the chmod seems counterintuitive per the example I listed above. |
I think I'm with @Vultaire here, feels odd to explicitly specify permissions and have them not respected. |
Makes sense -- reopening to consider further. |
+1 for seriously considering making pebble work a bit more like chmod. This got me when doing testing on round-tripping files with specific permissions through pebble. |
The underlying syscalls for opening the file are where the umask is applied (we don't control that code). We could put a chmod right in NewAtomicFile. Or we could add a Chmod method to it and only call it in the files API codepath (seems like this might be the better approach). Thoughts? |
I'm going to just use the AtomicWriteFlags for this. |
…#1363) canonical/pebble#80 is fixed (almost three years ago!) so we should enable this test again, as far as I can understand.
I've found that creating directories via the make-dirs action (POST @ /v1/files) may not respect the requested permissions. Specifically, during testing I found that if I tried to create a directory with 0777 permissions, it got created with 0775 permissions instead.
The text was updated successfully, but these errors were encountered: