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

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

[rabite]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

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@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.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-allow-sockets-with-different-uid-if-set-explicitly.patch~ --]
[-- Type: text/x-diff; name=0001-allow-sockets-with-different-uid-if-set-explicitly.patch~, Size: 684 bytes --]

From f4d1bfd4112e49270c4887485620b71376ae2c30 Mon Sep 17 00:00:00 2001
From: rabite <rabite@posteo.de>
Date: Sun, 31 May 2020 14:48:47 +0200
Subject: [PATCH] allow sockets with different uid if set explicitly

---
 lib-src/emacsclient.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 380be95222..ccef9085e4 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -1157,7 +1157,7 @@ socket_status (const char *name, uid_t uid)
   if (stat (name, &statbfr) != 0)
     return errno;
 
-  if (statbfr.st_uid != uid)
+  if (statbfr.st_uid != uid && !socket_name)
     return -1;
 
   return 0;
-- 
2.26.2

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

[Eli Zaretskii]

> Date: Sun, 31 May 2020 15:51:02 +0200
> From: rabite <rabite@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@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

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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@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