GNU bug report logs - #67323
30.0.50; [PATCH] Set a new desktop file to mode 0600

Previous Next

Full log

Message #20 received at 67323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 67323 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#67323: 30.0.50; [PATCH] Set a new desktop file to mode 0600
Date: Fri, 15 Dec 2023 10:37:32 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 14 Dec 2023 17:17:36 -0800
> Cc: 67323 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> >> Cc: 67323 <at> debbugs.gnu.org
> >> Date: Tue, 21 Nov 2023 14:00:28 +0100
> >>
> >> I had this idea while browsing savehist.el.  It have
> >> 'savehist-file-modes' set to #o600 by default.  Since desktop.el could
> >> also contain histories or others "secrets", I thought that it may a good
> >> idea to have more strict default.
> >>
> >> > The users can make this file unreadable by others if they want.
> >>
> >> Yes and it is what I have done previously for my own desktop file.  The
> >> idea here is to have saner default.  And as I said, it also works the
> >> other way around ;-)
> >>
> >> > It's a backward-incompatible change in any case.
> >>
> >> You are saying that it might surprise users who rely on the "readable
> >> for all" nature of one desktop file by default?  I'd have a hard time to
> >> figure out such a scenario…  But anyway, if you think this patch does
> >> not worth it, say it and I'll close this report.
> >
> > I'll wait a bit for others to chime in, if anyone has an opinion.
> 
> I think the patch makes sense.
> 
> Having defaults that protect users security and privacy better, even if
> only slightly, is not a bad thing, not unless there are cases where it
> hurts.  And I can't think of any such cases here.

desktop.el can create desktop files in any directory, not just under
the user's HOME directory.  (In fact, I use this feature a lot: I have
different desktop files in different directories, which allows me to
restore the last session on a per-project basis.)  While making the
desktop file unreadable/unwritable by others is probably okay under
HOME, doing that in other directories is not necessarily TRT,
especially if those desktop files can later be used from other users'
sessions.

So, if we install this, I think we need:

  . have a defcustom to control this behavior
  . the default is changed, possibly limit the new behavior to desktop
    files under the HOME directory, leaving the behavior in other
    directories as it is now
  . call out the change in NEWS; if the default changes, we should
    call it out in "Incompatible changes" section

There's also a (probably rare) scenario where the fact that the
desktop file doesn't exist does not necessarily mean it didn't exist
in that same directory.  Consider the following sequence:

  . start Emacs and restore desktop from an existing file
  . delete the desktop file
  . save desktop in the same directory

This could happen, for example, if the original desktop file was
faulty or incorrect in some way, and the user wants to "make it
right".  Completely legitimate (I think I did it myself a few times),
though probably rare.  In this case, the user won't expect the desktop
file to be treated as "new", and will certainly not expect to see its
access bits change in such a drastic way.

Bottom line: I think we should install this as optional behavior, by
default off, if at all.  If many people turn it on in their
customizations, we can later revisit the default value.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.