From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.bugs
Subject: bug#67323: 30.0.50; [PATCH] Set a new desktop file to mode 0600
Date: Fri, 15 Dec 2023 10:37:32 +0200
Message-ID: <83a5qbq2sz.fsf@gnu.org>
References: <87il5v76bn.fsf@ledu-giraud.fr> <835y1vi92r.fsf@gnu.org>
 <87edgj6z2r.fsf@ledu-giraud.fr> <8334wzi7d3.fsf@gnu.org>
 <CADwFkmkOJTV0BesdhHyHWixh28u+ZvuROVgAGZnpqRZg=ut8Lw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="3398"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: 67323@debbugs.gnu.org, manuel@ledu-giraud.fr
To: Stefan Kangas <stefankangas@gmail.com>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 15 09:38:14 2023
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>)
	id 1rE3i1-0000e2-Sq
	for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Dec 2023 09:38:14 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <bug-gnu-emacs-bounces@gnu.org>)
	id 1rE3hr-0008Ba-W2; Fri, 15 Dec 2023 03:38:04 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1rE3hq-0008B5-LI
 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 03:38:02 -0500
Original-Received: from debbugs.gnu.org ([2001:470:142:5::43])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1rE3hq-0007ja-Cd
 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 03:38:02 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1rE3hp-0006Nj-Sc
 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 03:38:01 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Eli Zaretskii <eliz@gnu.org>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Fri, 15 Dec 2023 08:38:01 +0000
Resent-Message-ID: <handler.67323.B67323.170262946224503@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 67323
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
Original-Received: via spool by 67323-submit@debbugs.gnu.org id=B67323.170262946224503
 (code B ref 67323); Fri, 15 Dec 2023 08:38:01 +0000
Original-Received: (at 67323) by debbugs.gnu.org; 15 Dec 2023 08:37:42 +0000
Original-Received: from localhost ([127.0.0.1]:51576 helo=debbugs.gnu.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
 id 1rE3hV-0006N9-LM
 for submit@debbugs.gnu.org; Fri, 15 Dec 2023 03:37:42 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52032)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@gnu.org>) id 1rE3hS-0006Mv-W0
 for 67323@debbugs.gnu.org; Fri, 15 Dec 2023 03:37:40 -0500
Original-Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1rE3hN-00077F-K9; Fri, 15 Dec 2023 03:37:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=1Nsmm4xFTEEbk50FULijXJ95KiYFUYcR1ecwPE1ZADw=; b=dfqaxenT0jxoEYsX+7VQ
 qv/WDg5PaDrbezQPlDKU+5fsAxnH3AoUZfLHa9sBF+sc4d/CyXy6orAOWxadSTFxCqeZW2CDIQaAr
 jfdw+FSLqNgp9JrA+zulEfR9hvAyCAr5W6H3XpBvi+zI+rZd5hjYjcOUk8ZFswxgD2Ep4Q7Y0kfN8
 nJKJkDLYQyJz+GnPxi3LlAYsli3LvT03zpufelXgilPD8jjdFIw15bUNhlt/fnO/HnjGuLYoLoskk
 OrOglayJpG/nV4Lrt8EqHx9SZjNH4NKqCn8DFcIl3dnNs3wjW+XxoW3rVaE35G0KIsuEzWg7WmrR1
 V4OARKDGBKOgMg==;
In-Reply-To: <CADwFkmkOJTV0BesdhHyHWixh28u+ZvuROVgAGZnpqRZg=ut8Lw@mail.gmail.com>
 (message from Stefan Kangas on Thu, 14 Dec 2023 17:17:36 -0800)
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.bugs:276254
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/276254>

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 14 Dec 2023 17:17:36 -0800
> Cc: 67323@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Manuel Giraud <manuel@ledu-giraud.fr>
> >> Cc: 67323@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.