all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: ruijie@netyu.xyz, 60460@debbugs.gnu.org
Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Mon, 2 Jan 2023 23:37:45 +0300	[thread overview]
Message-ID: <Y7NAmTMibDcDccdb@protected.localdomain> (raw)
In-Reply-To: <87ilhoeqlf.fsf@gmx.de>

* Michael Albinus <michael.albinus@gmx.de> [2023-01-02 21:31]:
> But there are other attack vectors then. Trash files from root user,
> located in the user's home directory, could have weak permissions.

Those are decisions of administrator and user. Permissions they put on
files is their decision and freedom. 

Any file owned by root and moved to user's home directory somewhere in
the Trash, will have how I tested it, same permission as in root
accessible directories. Let us say /etc or /usr and so on, those files
are anyway either visible by users or some of them in /etc protected
by permissions. Those are system decisions.

Who has sudo rights is system administrator, not necessarily main, but
then those people made decisions.

And moving into trash is useful, especially in case of files in /etc 

Let administrators decide what they want. 

Emacs is high level interface, not low level. On high level there is
almost nothing to be decided what people decided on low level.

For me is not logical to try to prevent people what they want.

Give them option, but don't try preventing them on that high level to
do this or that, what they otherwise can do in their system by using
different file manager.

If I can run other file manager with sudo and move to Trash anywhere
it is specified, then let it be for Emacs users too, as by trying to
"secure" something what otherwise was decided on low level, makes no
sense.

We can't say later "Emacs is more secure as file manager because it
does not allow you to move files managed with sudo to Trash" --
because it is not "more secure" as it is high level, not low level.

> > Settings in Emacs to delete by moving trash are explicit decisions of
> > user. Same with `sudo'. Administrator gives privilege to `sudoer',
> > and that sudoer may do what he thinks is right and good.
> >
> > I would personally prefer that sudo editing goes in trash.
> 
> You are free to configure respective connection-local variables.

Right now I use my function `system-move-file-to-trash' as recommended
by function `move-file-to-trash' and that is great option, I like that
configuration, so I can decide myself what get moved to Trash and what
not, so I will expand it to recognize sudo paths.

> > Anyway, when editing with sudo I see this file:
> >
> >   lrwxrwxrwx   1 root root       46 Jan  2 19:27 .#at.deny -> admin@protected.1904257840789327597
> >
> > which is dangling symlink, do you know about it? Is it bug?
> 
> No, it is a lock file. See (info "(elisp) File Locks")

Alright.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/





  reply	other threads:[~2023-01-02 20:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-31 16:34 bug#60460: 30.0.50; [FR] avoid putting remote files to local trash Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 16:41 ` Drew Adams
2023-01-01 16:47   ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-01 18:20     ` Drew Adams
2023-01-02  3:40     ` Jean Louis
2023-01-02  9:09 ` Michael Albinus
2023-01-02 10:35   ` Jean Louis
2023-01-02 10:47     ` Michael Albinus
2023-01-02 16:28       ` Jean Louis
2023-01-02 18:30         ` Michael Albinus
2023-01-02 20:37           ` Jean Louis [this message]
2023-01-03  8:47             ` Michael Albinus
2023-01-03 13:53               ` Jean Louis
2023-01-07  3:53               ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-07 12:48                 ` Michael Albinus
2023-01-08  0:37                   ` Jean Louis
2023-01-08  9:20                     ` Michael Albinus
2023-01-08 18:29               ` Michael Albinus
2023-02-02  8:56                 ` Michael Albinus
  -- strict thread matches above, loose matches on Subject: below --
2023-01-01 14:20 bug#60462: " Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-31 21:46 ` Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]   ` <handler.60462.D60462.16726054692608.notifdone@debbugs.gnu.org>
2023-01-02  9:16     ` bug#60460: " Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y7NAmTMibDcDccdb@protected.localdomain \
    --to=bugs@gnu.support \
    --cc=60460@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    --cc=ruijie@netyu.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.