Path('example.toml').permissions() == Permissions(owner=(READ, WRITE, EXECUTE), group=(READ), other=(,))

A word of warning: os.access() is not a good and sufficient permission check. It only checks DAC (discrete access control) permissions and suffers from TOCTOU issues. Operating systems have additional permission checks and security policies, for example  mandatory access control (AppArmor, SELinux, Smack) and seccomp.

> os.access() is not a good and sufficient permission check. It 
> only checks DAC (discrete access control) permissions 

That's interesting. In Linux, for example, I would expect the access() and faccessat() system calls to also check mandatory permissions. I know from experience that at least the [i]mmutable file attribute is checked.

That said, the Linux faccessat() system call doesn't support the flags parameter. So, 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.

For Windows, note that the current implementation of os.access() doesn't check the process/thread security context against mandatory and discretionary file security. Manually checking access is usually a discouraged practice, so there hasn't been any pressure to provide a real implementation.

Regarding the example in msg381940, this seems confused. The title mentions os.access(), i.e. a result that checks F_OK or some combination of R_OK, W_OK, and X_OK. In theory, this can be supported in Windows. But the example shows POSIX owner-group-other permissions, which are not supported in Windows. 

As currently 'supported' by os.chmod() and st_mode in the os.stat() result, POSIX permissions in Windows are a fantasy that's based on a category error (that readonly is a granted permission, when it's actually a file attribute, similar to the POSIX immutable attribute) and assumptions (e.g. all files are readable, all directories are executable, all files with .com, .exe, .bat, and .cmd extensions are executable, and only these files are executable).

> That's interesting. In Linux, for example, I would expect the access()
> and faccessat() system calls to also check mandatory permissions. I 
> know from experience that at least the [i]mmutable file attribute is 
> checked.

access(2) takes extended file attributes like immutable bit and CAPS into account. For example it returns True for access("testfile", R_OK) for testfile with DAC permission 0o000 and process context with CAP_DAC_OVERRIDE. I would also bet that it handles POSIX ACLs correcty.

But LSM and seccomp are not evaluated by access() -- at least SELinux is not. A seccomp syscall filter can have a BPF program attached to. It's a powerful feature that allows filtering and blocking by syscall argument.

$ python3
>>> os.access("testfile", os.R_OK)
True
>>> open("testfile")
Traceback (most recent call last):
...
PermissionError: [Errno 13] Permission denied: 'testfile'

# ausearch -m AVC
...
time->Fri Nov 27 16:14:31 2020
type=AVC msg=audit(1606490071.292:4204): avc:  denied  { read } for  pid=293015 comm="httpd" name="testfile" dev="dm-0" ino=399163 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:testcontext_t:s0 tclass=file permissive=0

> 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