Thanks for looking into this.
On Wed, May 13, 2020 at 10:25 AM Eli Zaretskii wrote:
And the fact that one normally needs to jump through hoops (elevating your session, using tools that make the file explicitly owned by a privileged group, etc.) to create such a situation on Windows is one more reason not to bother about this too much. IOW, the situation is rare.
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.
When I view the definition of a function that is part of the Lisp code that comes with Emacs `describe-function`, Emacs visits the installed `.el` file, which I cannot write to. Emacs thinks I can write to it though, which causes two annoyances:
1. It is easy to make accidental changes to a file that is not writable (and then I cannot save the file).
2. Flycheck immediately gives me an error message because it tries to open a file in a place it shouldn't. For example:
Error while checking syntax automatically: (file-error "Opening output file" "Permission denied" "c:/Program Files/Emacs/emacs-26.2/share/emacs/26.2/lisp/flycheck_help-fns.el")
Whether installed via Chocolatey or some other manner, I think having the site Emacs owned by Administrators without direct write access without elevation is a good practice and keeps one from accidentally changing things.
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: