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

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

[Michael Hoffman]

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

1. Start elevated Powershell (Win+X,A) and create file C:\foo.txt owned by
the Administrators group

PS C:\> $null > C:\foo.txt
PS C:\> takeown /A /F C:\foo.txt

SUCCESS: The file (or folder): "C:\foo.txt" now owned by the administrators
group.

2. Open `emacs -Q`

3. C-x C-f C:/foo.txt

4. Type `(file-writable-p "foo.txt")` C-x C-e
t

5. C-x C-s
Saving file c:/foo.txt...
Cannot write backup file; backing up in ~/.emacs.d/%backup%~
Error: (file-error "Setting ACL" "Operation not permitted"
"c:/Users/mhoffman/.emacs.d/%backup%~")
basic-save-buffer-2: Opening output file: Permission denied, c:/foo.txt

Expected that `(file-writable-p "foo.txt")` would return nil.


In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark activated

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 97495 11932)
 (symbols 48 20211 1)
 (miscs 40 42 143)
 (strings 32 29766 1358)
 (string-bytes 1 773975)
 (vectors 16 13889)
 (vector-slots 8 494823 7634)
 (floats 8 51 193)
 (intervals 56 251 11)
 (buffers 992 11))

[-- Attachment #2: Type: text/html, Size: 4004 bytes --]

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]

severity 41218 wishlist
thanks

> From: "Michael Hoffman" <emacs-hoffman@snkmail.com>
> Date: Tue, 12 May 2020 16:30:48 -0400
> 
> 1. Start elevated Powershell (Win+X,A) and create file C:\foo.txt owned by the Administrators group
> 
> PS C:\> $null > C:\foo.txt
> PS C:\> takeown /A /F C:\foo.txt
> 
> SUCCESS: The file (or folder): "C:\foo.txt" now owned by the administrators group.
> 
> 2. Open `emacs -Q`
> 
> 3. C-x C-f C:/foo.txt
> 
> 4. Type `(file-writable-p "foo.txt")` C-x C-e
> t
> 
> 5. C-x C-s
> Saving file c:/foo.txt...
> Cannot write backup file; backing up in ~/.emacs.d/%backup%~
> Error: (file-error "Setting ACL" "Operation not permitted" "c:/Users/mhoffman/.emacs.d/%backup%~")
> basic-save-buffer-2: Opening output file: Permission denied, c:/foo.txt
> 
> Expected that `(file-writable-p "foo.txt")` would return nil.

Emacs on MS-Windows doesn't check the ACLs when it determines whether
a file is writable.  The reason is that there doesn't seem to be a
general reliable way of doing so, given that access rights on Windows
are many times implicitly given because the user belongs to some group
that is granted access.  Basically, the only reliable way of making
sure the file is writable is to try writing to it; any other kind of
test I know of is plagued with false negatives, i.e. they frequently
tell the file is not writable when in fact it is, which I consider a
greater evil than the kind of problem you report.  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.

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

Thanks.

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

[Michael Hoffman]

[-- Attachment #1: Type: text/plain, Size: 2152 bytes --]

 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:

https://docs.microsoft.com/en-us/windows/win32/api/authz/nf-authz-authzaccesscheck
https://docs.microsoft.com/en-us/windows/win32/secauthz/how-dacls-control-access-to-an-object

Michael

[-- Attachment #2: Type: text/html, Size: 3205 bytes --]

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]

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