bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Eli Zaretskii]

On a system that supports symlinks, do this:

 emacs -Q
 C-x d RET

Go to any file and type

 S foobar RET

This creates a symlink named 'foobar' to the file on whose line you
were when you typed S.  Now go to the line of 'foobar' and type this:

 M 0444 RET

Emacs says "Redisplaying...done", but the mode bits of the target of
the symlink do not reflect the change.  Type 'g', and they will.

From a cursory look at the code (dired-do-redisplay), it sounds like
Dired assumes that the file to be refreshed is necessarily on the
current line (or marked).  This is false for symlinks and the 'M'
command (and probably a few others, like 'O'), because the file that
changes is the target of the symlink.

I think this bug was in Emacs since about forever; I tried as far back
as Emacs 22.1, and the problem was still there.


In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
 of 2012-06-11 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  diff-auto-refine-mode: t
  flyspell-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-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
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
n SPC t h e SPC n e t . <return> <right> <up> <C-left> 
<C-left> <C-right> SPC W i n d o w s M-q <down> <down> 
<up> <up> <up> <C-left> <C-left> <C-left> <C-left> 
l i b f f i SPC M-q <down> <down> <down> <C-home> C-c 
C-s <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <switch-frame> d <next> <next> <next> <prior> 
<next> <next> <next> <prior> <C-home> <C-end> <prior> 
<prior> <prior> <prior> <prior> d d <next> d d <next> 
d d d d d d <next> d d <next> d d d d d d d d d d d 
d <next> d <next> <next> d <next> d d d d d d d d d 
d d d SPC o <up> <up> <down> <return> d d d d d SPC 
d d C-z C-z C-z C-z C-z C-z C-z C-z C-z C-z <next> 
<next> SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
<prior> SPC SPC SPC SPC SPC SPC SPC SPC SPC <prior> 
<prior> <prior> <next> <next> <next> <next> <next> 
<next> <next> <next> <next> <next> <next> <next> <next> 
<next> <next> <next> <prior> <prior> <prior> <prior> 
<prior> C-r e g g e <M-left> <next> d d d d d SPC d 
SPC d d d d d SPC d d d d d n d SPC d d d d d d d d 
d n d d d d d d d d SPC d d d d <down> n SPC d d d 
d d d d d d d d d d d d d SPC d d SPC d SPC d d SPC 
d SPC d d d d d d d d C-z C-z C-z C-z C-z C-z C-z C-z 
C-z C-z d C-x C-s <switch-frame> M-x r e p o r t <tab> 
<return>

Recent messages:
Sending email done
Sending...done
Mark set [2 times]
Showing message 3132
Showing message 3132...done
Added to d:/usr/eli/rmail/TEXINFO.rmail
Mark saved where search started
No following nondeleted message
Saving file d:/usr/eli/rmail/INBOX...
Wrote d:/usr/eli/rmail/INBOX [2 times]

Load-path shadows:
None found.

Features:
(shadow emacsbug multi-isearch network-stream starttls tls smtpmail
auth-source eieio assoc gnus-util password-cache mailalias sendmail
rmailout tcl nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt
rng-util rng-pttrn nxml-ns nxml-mode nxml-outln nxml-rap nxml-util
nxml-glyph nxml-enc xmltok sgml-mode conf-mode newcomment parse-time
generic ld-script sh-script executable vc-git arc-mode archive-mode
diff-mode dired-x dired make-mode tar-mode vc-cvs face-remap org-wl
org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs
org-html org-exp ob-exp org-exp-blocks find-func org-agenda org-info
org-gnus org-docview org-bibtex bibtex org-bbdb org byte-opt warnings
bytecomp byte-compile cconv macroexp advice help-fns advice-preload
ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote org-src
ob-comint ob-keys ob ob-eval org-pcomplete pcomplete comint ansi-color
ring org-list org-faces org-compat org-entities org-macs noutline
outline easy-mmode cal-menu calendar cal-loaddefs flyspell texinfo
jka-compr autorevert info vc-bzr cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt qp
rmailsum rmailmm message format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231
rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils desktop
server filecache mairix cus-edit easymenu cus-start cus-load wid-edit
saveplace midnight ispell generic-x paren battery time time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table
ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty
emacs)

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Michalis V.]

Eli Zaretskii <eliz@gnu.org> writes:

> On a system that supports symlinks, do this:
>
>  emacs -Q
>  C-x d RET
>
> Go to any file and type
>
>  S foobar RET
>
> This creates a symlink named 'foobar' to the file on whose line you
> were when you typed S.  Now go to the line of 'foobar' and type this:
>
>  M 0444 RET
>
> Emacs says "Redisplaying...done", but the mode bits of the target of
> the symlink do not reflect the change.  Type 'g', and they will.
>
>>From a cursory look at the code (dired-do-redisplay), it sounds like
> Dired assumes that the file to be refreshed is necessarily on the
> current line (or marked).  This is false for symlinks and the 'M'
> command (and probably a few others, like 'O'), because the file that
> changes is the target of the symlink.
>
> I think this bug was in Emacs since about forever; I tried as far back
> as Emacs 22.1, and the problem was still there.


hi,

I can reproduce this in 27.1 but in 28.0.50 i get the following message:

Doing chmod: Operation not supported, /tmp/foobar

chmod on the symlinked file itself works ("Redisplaying..." too)

perhaps this functionality was disabled/removed for symlinks on purpose?
or is it a new bug?


Michalis

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Lars Ingebrigtsen]

"Michalis V." <mvar.40k@gmail.com> writes:

> I can reproduce this in 27.1 but in 28.0.50 i get the following message:
>
> Doing chmod: Operation not supported, /tmp/foobar
>
> chmod on the symlinked file itself works ("Redisplaying..." too)
>
> perhaps this functionality was disabled/removed for symlinks on purpose?
> or is it a new bug?

In Linux you can't change the permissions on a symlink (they're always
777):

       chmod never changes the permissions of symbolic links; the chmod system
       call cannot change their permissions.  This is not a problem since  the
       permissions  of  symbolic links are never used. 

So I'm surprised that the `M' command even tries to do the chmod on the
symlink.  This was apparently done as part of a security audit:

commit 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66
Author:     Paul Eggert <eggert@cs.ucla.edu>
AuthorDate: Sun Feb 23 16:19:42 2020 -0800

    Add 'nofollow' flag to set-file-modes etc.
    
    This avoids some race conditions (Bug#39683).  E.g., if some other
    program changes a file to a symlink between the time Emacs creates
    the file and the time it changes the file’s permissions, using the
    new flag prevents Emacs from inadvertently changing the
    permissions of a victim in some completely unrelated directory.

Hm.  I'm not sure why this should affect the `M' command in dired, though...

I've added Paul to the CCs; perhaps he has some comments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Paul Eggert]

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

On 8/24/21 8:40 AM, Lars Ingebrigtsen wrote:

> I'm surprised that the `M' command even tries to do the chmod on the
> symlink.

Unfortunately the M command doesn't know in advance whether chmod will 
work on the symlink, as that is platform and filesystem dependent (this 
is in addition to the usual race-condition problem). So as a practical 
matter the M command must try the chmod and report the failure somehow. 
(Perhaps the reporting could be improved; I expect that's low priority.)

A few things:

* I neglected to document this behavior change, so I just now installed 
the attached to fix that oversight.

* Because of this behavior change, the example Eli gives at the start of 
Bug#11912 is now obsolete, as the bug has been fixed in a different way. 
However, as Eli mentioned, there are other commands (like 'O') where the 
bug is still present.

* And this suggests that some longstanding security and other bugs 
remain in this area. I plan to file more bug reports that will cite 
Bug#11912. If the other bugs are fixed, then Bug#11912 should be 
completely obsolete and can be closed.

[-- Attachment #2: 0001-Doc-that-dired-do-chmod-no-longer-follows-symlinks.patch --]
[-- Type: text/x-patch, Size: 1764 bytes --]

From 2c8657f4f63e6d2b6e1d0866dd597bc85b422430 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 24 Aug 2021 10:15:43 -0700
Subject: [PATCH] Doc that dired-do-chmod no longer follows symlinks

* doc/emacs/dired.texi (Operating on Files):
* etc/NEWS: Document this security precaution.
---
 doc/emacs/dired.texi | 4 +++-
 etc/NEWS             | 6 ++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/doc/emacs/dired.texi b/doc/emacs/dired.texi
index 680b20c593..e84ed0f7b6 100644
--- a/doc/emacs/dired.texi
+++ b/doc/emacs/dired.texi
@@ -823,7 +823,9 @@ Operating on Files
 Change the mode (also called @dfn{permission bits}) of the specified
 files (@code{dired-do-chmod}).  @var{modespec} can be in octal or
 symbolic notation, like arguments handled by the @command{chmod}
-program.
+program.  This command does not follow symbolic links, so it reports
+an error if you try to change the mode of a symbolic link on a
+platform where such modes are immutable.
 
 @findex dired-do-chgrp
 @kindex G @r{(Dired)}
diff --git a/etc/NEWS b/etc/NEWS
index 588290f433..07a78216b8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -909,6 +909,12 @@ time zones will use a form like "+0100" instead of "CET".
 If non-nil, Dired will kill the current buffer when selecting a new
 directory to display.
 
++++
+*** Behavior change on 'dired-do-chmod'.
+As a security precaution, Dired's M command no longer follows symbolic
+links.  Instead, it changes the symbolic link's own mode; this always
+fails on platforms where such modes are immutable.
+
 ---
 *** Behavior change on 'dired-clean-confirm-killing-deleted-buffers'.
 Previously, if 'dired-clean-up-buffers-too' was non-nil, and
-- 
2.30.2

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Michalis V.]

Lars Ingebrigtsen <larsi@gnus.org> writes:
> In Linux you can't change the permissions on a symlink (they're always
> 777):
>
>        chmod never changes the permissions of symbolic links; the chmod system
>        call cannot change their permissions.  This is not a problem since  the
>        permissions  of  symbolic links are never used. 
>
> So I'm surprised that the `M' command even tries to do the chmod on the
> symlink.  This was apparently done as part of a security audit:
>
> commit 9d626dffc6ba62c0d7a1a5c712f576ed8684fd66
> Author:     Paul Eggert <eggert@cs.ucla.edu>
> AuthorDate: Sun Feb 23 16:19:42 2020 -0800
>
>     Add 'nofollow' flag to set-file-modes etc.
>     
>     This avoids some race conditions (Bug#39683).  E.g., if some other
>     program changes a file to a symlink between the time Emacs creates
>     the file and the time it changes the file’s permissions, using the
>     new flag prevents Emacs from inadvertently changing the
>     permissions of a victim in some completely unrelated directory.
>
> Hm.  I'm not sure why this should affect the `M' command in dired, though...
>
> I've added Paul to the CCs; perhaps he has some comments.

that's true; but doing chmod on the symlink from bash will actually
have effect on the symlinked file itself, so from a user perspective
i'd expect dired to behave similarly (that is, M to resolve the symlink
and apply the chmod mask to the actual file). But i never thought of
race conditions and potential security problems so the current behavior
looks like the best one.

thanks,
Michalis

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> * I neglected to document this behavior change, so I just now
>   installed the attached to fix that oversight.

I understand the security-related reasons for changing the `M' command,
but I'm wondering whether they are weighty enough to make it more
inconvenient for the user to use symlinks in Emacs.

The reasoning is that an attacker may control a symlink and make it
point to somewhere else.  So I may have 

  lrwxrwxrwx  1 evil      evil         17 Aug 25 12:52 foosym -> /tmp/IMG_4475.JPG

in my dired buffer, and then "evil" changes the link to point to
somewhere else, and then I say `M' on the link, and then I operated on
the wrong file.

However, on the command line, chmod is fine with following symlinks, so
the user can just `! chmod 0444' instead, and the same will happen.

So is inconveniencing people who are using the `M' command worth it?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Paul Eggert]

On 8/25/21 3:57 AM, Lars Ingebrigtsen wrote:
> on the command line, chmod is fine with following symlinks

Yes, that's what POSIX requires. However, Dired is different from the 
POSIX shell, because a Dired user sees the permissions on a symbolic 
link while typing the command to the edit permissions, and the natural 
assumption is that one is editing what one is seeing. This is even more 
true of Wdired (Bug#50189); and it's also quite true for Dired.

That is why G, O, T should also be fixed (see Bug#50191). The Dired 
users sees the group, ownership, and timestamp of the symlink while 
typing the "change the group" (or whatever) command, so the natural 
assumption is that one is changing what one is seeing.

This assumption is so hardwired that it is the original motivation for 
the coding error that prompted Bug#11912.

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understand the security-related reasons for changing the `M' command,
  > but I'm wondering whether they are weighty enough to make it more
  > inconvenient for the user to use symlinks in Emacs.

It's not just for the sake of security.  Dired commands generally
operate on the files you see in the Dired buffer.  If what you see in
the dired buffer is a symlink, it is still surprising for a Dired command
to alter the file that the symlink points to.

I wouldn't assume that a user who uses M on a symlink in Dired wants
to alter the file it points to.  I think it is more likely that the
user did not realize it might do that.  Suppose you operate on 10
files and one is a symlink -- you might not even have noticed that one
is as symlink.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Yes, that's what POSIX requires. However, Dired is different from the
> POSIX shell, because a Dired user sees the permissions on a symbolic
> link while typing the command to the edit permissions, and the natural
> assumption is that one is editing what one is seeing. This is even
> more true of Wdired (Bug#50189); and it's also quite true for Dired.

Yeah, that's a good point.

> That is why G, O, T should also be fixed (see Bug#50191). The Dired
> users sees the group, ownership, and timestamp of the symlink while
> typing the "change the group" (or whatever) command, so the natural
> assumption is that one is changing what one is seeing.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I wouldn't assume that a user who uses M on a symlink in Dired wants
> to alter the file it points to.  I think it is more likely that the
> user did not realize it might do that.  Suppose you operate on 10
> files and one is a symlink -- you might not even have noticed that one
> is as symlink.

Yes, that's a good point.  It's always ambiguous what the user really
wants to do when doing operations on symlinks, and making Dired always
"edit what's actually in the buffer" (i.e., the symlink itself) makes it
less ambiguous (even if it might surprise people who expected Posix
semantics).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Andreas Schwab]

On Aug 26 2021, Lars Ingebrigtsen wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>> I wouldn't assume that a user who uses M on a symlink in Dired wants
>> to alter the file it points to.  I think it is more likely that the
>> user did not realize it might do that.  Suppose you operate on 10
>> files and one is a symlink -- you might not even have noticed that one
>> is as symlink.
>
> Yes, that's a good point.  It's always ambiguous what the user really
> wants to do when doing operations on symlinks, and making Dired always
> "edit what's actually in the buffer" (i.e., the symlink itself) makes it
> less ambiguous (even if it might surprise people who expected Posix
> semantics).

But if the dired buffer was created with ls -L, shouldn't M follow
links?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Paul Eggert]

On 8/26/21 7:07 AM, Andreas Schwab wrote:
> But if the dired buffer was created with ls -L, shouldn't M follow
> links?

Yes, in that case I suppose M should do so (and similarly for G, O, T).

This raises the issue of what to do with output like the following from 
GNU 'ls' when 'c' is a dangling symlink:

   $ ls -lL
   ls: cannot access 'c': No such file or directory
   total 0
   -rw-rw-r-- 1 eggert eggert 0 Aug 26 09:46 b
   l????????? ? ?      ?      ?            ? c


However, these are rare cases; typically dired buffers are created 
without -L and we need to handle the typical cases better.

bug#11912: 24.1; 'M' in Dired on a symlink does not refresh the display

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But if the dired buffer was created with ls -L, shouldn't M follow
  > links?

My first thought is that that is right.  But I am not confident of that
conclusion.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)