GNU bug report logs - #41628
[PATCH] Allow emacsclient to connect to other user's socket when using -s

Previous Next

Package: emacs;

Reported by: rabite <at> posteo.de

Date: Sun, 31 May 2020 15:30:02 UTC

Severity: normal

Tags: patch, wontfix

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41628 in the body.
You can then email your comments to 41628 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#41628; Package emacs. (Sun, 31 May 2020 15:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to rabite <at> posteo.de:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 31 May 2020 15:30:02 GMT) Full text and rfc822 format available.

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

From: rabite <rabite <at> posteo.de>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Allow emacsclient to connect to other user's socket when
 using -s
Date: Sun, 31 May 2020 15:51:02 +0200
[Message part 1 (text/plain, inline)]
Since commit 5c0d8bb95bbd5354e6b2cd2e56a91afe4e780759 emacsclient won't 
connect to my usual emacs session when run as root. I use this all the 
time to edit files, combined with "-T /sudo:root <at> localhost" to handle 
permissions. Using a separate emacs process would be unpractical as it 
would require setting up a whole new emacs configuration and keeping it 
in sync with my main one. I think this is a common use-case for those 
who have an emacs-server running all the time and supporting it makes a 
lot of sense. In principle I see no reason emacsclient should refuse a 
connection that is possible in theory.

It looks like this "feature" has been explicitly disabled, maybe because 
it might triggered unintentionally if running su doesn't set USER or 
something?. So I propose a new approach to allow root emacsclient to 
connect to non-root emacs servers: If the user sets a socket file 
explicitly using the -s switch, the socket_status() function skips the 
uid check and returns without error as long as the call to stat was 
successful. Generally, this would allow any user to connect to any emacs 
server as long as the permissions allow it. If not, it shows the 
"connect: Permission denied" message, if the socket file is reachable at 
all, that is.

I added a tiny patch that implements this change. If necessary, I'd be 
willing to expand on it, or even implement a different approach 
depending on how much work/complicated it would be.
[0001-allow-sockets-with-different-uid-if-set-explicitly.patch~ (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#41628; Package emacs. (Sun, 31 May 2020 15:45:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: rabite <at> posteo.de
Cc: 41628 <at> debbugs.gnu.org
Subject: Re: bug#41628: [PATCH] Allow emacsclient to connect to other user's
 socket when using -s
Date: Sun, 31 May 2020 18:44:50 +0300
> Date: Sun, 31 May 2020 15:51:02 +0200
> From: rabite <rabite <at> posteo.de>
> 
> Since commit 5c0d8bb95bbd5354e6b2cd2e56a91afe4e780759 emacsclient won't 
> connect to my usual emacs session when run as root. I use this all the 
> time to edit files, combined with "-T /sudo:root <at> localhost" to handle 
> permissions. Using a separate emacs process would be unpractical as it 
> would require setting up a whole new emacs configuration and keeping it 
> in sync with my main one. I think this is a common use-case for those 
> who have an emacs-server running all the time and supporting it makes a 
> lot of sense. In principle I see no reason emacsclient should refuse a 
> connection that is possible in theory.
> 
> It looks like this "feature" has been explicitly disabled, maybe because 
> it might triggered unintentionally if running su doesn't set USER or 
> something?

The discussion which led to that change is here:

  https://lists.gnu.org/r/emacs-devel/2018-11/msg00019.html




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#41628; Package emacs. (Wed, 05 Aug 2020 17:33:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41628 <at> debbugs.gnu.org, rabite <at> posteo.de
Subject: Re: bug#41628: [PATCH] Allow emacsclient to connect to other user's
 socket when using -s
Date: Wed, 05 Aug 2020 19:32:38 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Since commit 5c0d8bb95bbd5354e6b2cd2e56a91afe4e780759 emacsclient won't 
>> connect to my usual emacs session when run as root. I use this all the 
>> time to edit files, combined with "-T /sudo:root <at> localhost" to handle 
>> permissions. Using a separate emacs process would be unpractical as it 
>> would require setting up a whole new emacs configuration and keeping it 
>> in sync with my main one. I think this is a common use-case for those 
>> who have an emacs-server running all the time and supporting it makes a 
>> lot of sense. In principle I see no reason emacsclient should refuse a 
>> connection that is possible in theory.
>> 
>> It looks like this "feature" has been explicitly disabled, maybe because 
>> it might triggered unintentionally if running su doesn't set USER or 
>> something?
>
> The discussion which led to that change is here:
>
>   https://lists.gnu.org/r/emacs-devel/2018-11/msg00019.html

So unless I understand something here, this is not something we want to
allow (because of security concerns), so I'm closing this bug report.

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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 05 Aug 2020 17:33:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 41628 <at> debbugs.gnu.org and rabite <at> posteo.de Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 05 Aug 2020 17:33:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 03 Sep 2020 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 207 days ago.

Previous Next


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