Eryk Sun <[email protected]> added the comment:
> takes extended file attributes like immutable bit
Just to clarify, immutable isn't an extended attribute. It's one of the flag
values in a Linux inode, which is supported by some filesystems such as ext4.
It's in the API as STATX_ATTR_IMMUTABLE from the statx() stx_attributes field.
> according to the man page, AT_EACCESS (effective_ids=True) and
> AT_SYMLINK_NOFOLLOW (follow_symlinks=False) are implemented in
> the glibc wrapper by calling fstatat() instead. I presume
> that's limited to the discretionary st_mode permissions
Apparently this is the case. For example, given 'spam.txt' is an immutable file:
>>> os.access('spam.txt', os.W_OK)
False
>>> os.access('spam.txt', os.W_OK, follow_symlinks=False)
True
The AT_EACCESS flag has the same limitations in Linux, when it's not ignored.
This issue with AT_SYMLINK_NOFOLLOW and AT_EACCESS will be resolved with the
next release of glibc [1] on Linux systems running kernel 5.8+, which has a new
faccessat2 system call that supports the flags parameter. Maybe initially a
pathlib.Path method that implements an access check doesn't need to support the
follow_symlinks and effective_ids parameters.
---
[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=3d3ab573a5f3071992cbc4f57d50d1d29d55bde2
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue42481>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
