Skip to content
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

Closed
Vultaire opened this issue Oct 29, 2021 · 7 comments · Fixed by #111

Comments

@Vultaire
Copy link

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.

@benhoyt
Copy link
Contributor

benhoyt commented Oct 31, 2021

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.

@benhoyt benhoyt closed this as completed Oct 31, 2021
@Vultaire
Copy link
Author

Vultaire commented Nov 1, 2021

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.

@jnsgruk
Copy link
Member

jnsgruk commented Nov 1, 2021

I think I'm with @Vultaire here, feels odd to explicitly specify permissions and have them not respected.

@benhoyt
Copy link
Contributor

benhoyt commented Nov 1, 2021

Makes sense -- reopening to consider further.

@benhoyt benhoyt reopened this Nov 1, 2021
@rwcarlsen
Copy link
Contributor

+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.

@rwcarlsen
Copy link
Contributor

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?

@rwcarlsen
Copy link
Contributor

I'm going to just use the AtomicWriteFlags for this.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants