bug#41218: 26.3; Windows: file-writable-p returns t for a file owned by the Administrators group but not writable by the user, a member of the Administrators group

[Eli Zaretskii <eliz@gnu.org>]

> From: "Michael Hoffman" <emacs-hoffman@snkmail.com>
> Date: Wed, 13 May 2020 12:05:51 -0400
> 
> The situation arises for me when viewing files within `%ProgramFiles%` which are often set by installers or
> similar systems to be owned by Administrators when installed for all users.
> 
> Specifically, it most often comes up when I am using Emacs, as installed by Chocolatey. Chocolatey installs
> Emacs to be owned by the Administrators group.

That has a simple solution: take ownership of all the files in the
Emacs distribution, so that they are owned by your Windows user and
not by Administrators.

(It is generally not a good idea to install stuff under
%ProgramFiles%, because taking ownership there requires elevation, but
since you evidently don't have a problem with elevation, you should be
able to take ownership on that directory and all of its
subdirectories.)

>  Of course, if someone can explain how to perform this test in a way that takes ACLs into account and
>  would be reliable, we could consider implementing it (assuming it isn't too expensive, since such a
>  test will have to be performed each time a user saves a buffer to its file).
> 
> The `AuthzAccessCheck()` function from the Authz API might be able to do this:

No, it doesn't, not AFAIK.  That's exactly one of those APIs which
it's tempting to use, but which produce false negatives.  This API
only checks the ACLs against your user and your main group's
permissions.  But on Windows many users are members of several groups,
especially if they are developers, and access granted via those other
groups, and also through inheritance of access rights from group to
other groups, is not tested.

At least that's what I know.  If someone can write code to solve this
issue, I'm sure it will be welcome.