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