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.