Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support directory default access control list #378

Open
b10902118 opened this issue Nov 16, 2024 · 0 comments
Open

Support directory default access control list #378

b10902118 opened this issue Nov 16, 2024 · 0 comments

Comments

@b10902118
Copy link

b10902118 commented Nov 16, 2024

In modern unix-like system, a directory can have default access control list (acl) applied to newly created files under it (setfacl -d). To make acl effective, the corresponding group permission must be open. https://unix.stackexchange.com/questions/328806/acl-named-group-permissions-not-overriding-file-permissions-why

Current filelock implementation set permission by a fixed permission in open and fchmod. The default 644 is reasonable, but this also disables the default acl write.

fd = os.open(self.lock_file, open_flags, self._context.mode)
with suppress(PermissionError): # This locked is not owned by this UID
os.fchmod(fd, self._context.mode)

But this inconvenience won't happen when we create files normally, say using touch with umask 022. If there is default acl, the group write bit will still be on so the default acl is effective. Turns out the umask is handled by operating system with regard to default acl, but a specified 0 mode bit in open and fchmod are not.

Then why not let umask handle mode? I think the main reason is for multi-threading where each thread may change umask (#204). But this acl problem really cause great inconvenience when locks needed to be updated by different users (file locks are not removed after release). My case is sharing huggingface datasets under .cache with default acl, but now the user who creates the lock has to manually delete it or others cannot recreate it. I believe there are many scenarios like this and this is not those packages' fault.

Currently I haven't found any good solution. I thought of checking default acl to decide whether to turn on group perm but didn't find a python function that can check acl without executing command. Hope to get some help.

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

No branches or pull requests

1 participant