bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Mike Alexander]

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

Many standard programs will automatically use the UID (the number) of a
user instead of the USER (username) when the USER string is longer than
8 characters.  In my case the username assigned to me is 11 characters
long and cannot be changed.

Starting the emacs daemon with "emacs --daemon=$EMACS_DAEMON_NAME", where
the $EMACS_DAEMON_NAME matches the standard letter, number, underscore
requrements, ends up using
my UID in the socket creation since my username is longer than 8
characters ("/tmp/emacs$(id -u)/$EMACS_DAEMON_NAME").  However, running
"emacsclient -c -s $EMACS_DAEMON_NAME" fails with a refused connection
because it attempts to connect using my username instead of the UID and
fails to find the socket ("/tmp/emacs$USER/$EMACS_DAEMON_NAME").  These
behaviors should be consistent between the two since they're expected to
be used in tandem.




In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2014-12-18 on GOL-AP21-DV
Windowing system distributor `The Cygwin/X Project', version 11.0.11602000
System Description: Ubuntu 10.04.4 LTS

Configured using:
 `configure --prefix=/home/mtalexander/local/ --with-xpm=no
 --with-gif=no --with-tiff=no'

Important settings:
  locale-coding-system: nil

Major mode: Lisp Interaction

Minor modes in effect:
  global-visible-mark-mode: t
  visible-mark-mode: t
  helm-mode: t
  shell-dirtrack-mode: t
  helm-autoresize-mode: t
  projectile-global-mode: t
  projectile-mode: t
  global-company-mode: t
  company-mode: t
  global-semantic-mru-bookmark-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-completions-mode: t
  global-semantic-idle-scheduler-mode: t
  global-semantic-idle-local-symbol-highlight-mode: t
  global-semantic-idle-summary-mode: t
  winner-mode: t
  show-paren-mode: t
  global-semantic-highlight-func-mode: t
  global-semantic-stickyfunc-mode: t
  global-semantic-show-parser-state-mode: t
  semantic-mode: t
  global-linum-mode: t
  linum-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p r t <backspace> <backspace> o r t - e m a
c s - b u g <return>

Recent messages:
Loading /home/mtalexander/.emacs.d/smooth-scrolling.el (source)...done
Loading /home/mtalexander/.emacs.d/init-etags.el (source)...done
Loading /home/mtalexander/.emacs.d/grep-buffers.el (source)...done
Loading /home/mtalexander/.emacs.d/multi-term.el (source)...done
Loading /home/mtalexander/.emacs.d/linum.el (source)...done
ad-handle-definition: `tramp-read-passwd' got redefined
Helm completion enabled
Loading
/home/mtalexander/.emacs.d/elpa/helm-20150319.1356/helm-autoloads.el
(source)...done
[sml] sml/theme set to respectful
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils company-files
company-oddmuse company-keywords company-etags etags company-gtags
company-dabbrev-code company-dabbrev company-capf company-cmake
company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company-c-headers
visible-mark lk-file-search xcscope smart-mode-line-respectful-theme
smart-mode-line rich-minority helm-swoop helm-projectile helm-config
async-bytecomp async helm-aliases helm-mode helm-files rx image-dired
tramp tramp-compat tramp-loaddefs trampver shell dired-x dired-aux ffap
helm-buffers helm-elscreen helm-tags helm-bookmark helm-adaptive
helm-info bookmark pp helm-locate helm-help helm-org org org-macro
org-footnote org-pcomplete pcomplete org-list org-faces org-entities
noutline outline org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs helm-match-plugin helm-grep helm-regexp helm-plugin grep
helm-external helm-net browse-url xml url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source gnus-util mm-util mail-prsvr password-cache
url-vars mailcap helm-utils compile comint ansi-color helm helm-source
projectile ibuf-ext ibuffer dash thingatpt company easy-mmode multi-term
cl-macs cl term disp-table ehelp grep-buffers mule-util elscreen dired
init-etags smooth-scrolling advice help-fns+ info wid-edit help-fns
help-mode+ help-mode edmacro kmacro cl-loaddefs cl-lib package
epg-config semantic/mru-bookmark semantic/db-mode semantic/db gv
eieio-base semantic/idle semantic/format ezimage semantic/ctxt
semantic/decorate/mode semantic/tag-ls semantic/find semantic/decorate
pulse winner ring paren semantic/util-modes easymenu semantic/util
semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp
byte-compile cconv eieio-core mode-local cedet linum cus-start cus-load
time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind gfilenotify dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 325520 172357)
 (symbols 48 41544 5)
 (miscs 40 563 1081)
 (strings 32 105861 99545)
 (string-bytes 1 3546932)
 (vectors 16 32991)
 (vector-slots 8 629990 41331)
 (floats 8 197 223)
 (intervals 56 504 3080)
 (buffers 960 13)
 (heap 1024 35991 15990))

[-- Attachment #2: Type: text/html, Size: 8072 bytes --]

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Glenn Morris]

Mike Alexander wrote:

> Starting the emacs daemon with "emacs --daemon=$EMACS_DAEMON_NAME", where
> the $EMACS_DAEMON_NAME matches the standard letter, number, underscore
> requrements, ends up using
> my UID in the socket creation since my username is longer than 8
> characters ("/tmp/emacs$(id -u)/$EMACS_DAEMON_NAME").

I've never seen this use anything BUT the UID, no matter how long your
username is. That's what it has always used for me, with a two character
username, and emacsclient works fine.

Nevertheless, I tried with a username with more than 8 chars, and that
too worked fine.

> However, running "emacsclient -c -s $EMACS_DAEMON_NAME" fails with a
> refused connection because it attempts to connect using my username
> instead of the UID and fails to find the socket
> ("/tmp/emacs$USER/$EMACS_DAEMON_NAME").

How did you conclude that it was trying to use your username?

I don't suppose you have a huge UID?

Are you sure your version of emacsclient matches your version of emacs?

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Mike Alexander]

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

emacs --version gives 24.4.2, while emacsclient --version gives 24.4.
Furthermore, both are the version installed automatically with the make
install target after building from source (using the config script).

I guess I don't _know_ it's using my username instead of UID, but I get a
connection refused from the command "emacsclient -c -s $EMACS_DAEMON_NAME"
after starting and confirming the daemon is running via the command "emacs
--daemon=$EMACS_DAEMON_NAME".  To be safe, I replaced the environment
variable with the direct text and saw the exact same issue. A " sudo
netstat -xaupen | grep emac" shows the correct socket (using the UID) for
the server, but the client still refuses the connection. I saw a hit on a
blog talking about a similar problem and needing to specify the fullly
pathed socket name to the client so I tried that and found it worked. Maybe
it's not really a username versus UID issue, but the construction method
between the two is clearly different somehow.

Incidentally I'm working on a corporate server that integrates with a
company wide user base, so I do have a huge UID. In my case the username is
mtalexander and the UID is 1073796907.

-Mike

On Tue, Jul 7, 2015, 08:48 Glenn Morris <rgm@gnu.org> wrote:

> Mike Alexander wrote:
>
> > Starting the emacs daemon with "emacs --daemon=$EMACS_DAEMON_NAME", where
> > the $EMACS_DAEMON_NAME matches the standard letter, number, underscore
> > requrements, ends up using
> > my UID in the socket creation since my username is longer than 8
> > characters ("/tmp/emacs$(id -u)/$EMACS_DAEMON_NAME").
>
> I've never seen this use anything BUT the UID, no matter how long your
> username is. That's what it has always used for me, with a two character
> username, and emacsclient works fine.
>
> Nevertheless, I tried with a username with more than 8 chars, and that
> too worked fine.
>
> > However, running "emacsclient -c -s $EMACS_DAEMON_NAME" fails with a
> > refused connection because it attempts to connect using my username
> > instead of the UID and fails to find the socket
> > ("/tmp/emacs$USER/$EMACS_DAEMON_NAME").
>
> How did you conclude that it was trying to use your username?
>
> I don't suppose you have a huge UID?
>
> Are you sure your version of emacsclient matches your version of emacs?
>

[-- Attachment #2: Type: text/html, Size: 2793 bytes --]

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Wolfgang Jenkner]

On Tue, Jul 07 2015, Mike Alexander wrote:

> I get a
> connection refused from the command "emacsclient -c -s $EMACS_DAEMON_NAME"
> after starting and confirming the daemon is running via the command "emacs
> --daemon=$EMACS_DAEMON_NAME".  

Since connect() is a syscall you could run emacsclient under strace to
easily find out with which arguments it is called.  In my case (using
truss under FreeBSD) I see the following syscalls leading up to the
connect() call

socket(PF_LOCAL,SOCK_STREAM,0)                  = 3 (0x3)
geteuid()                                       = 1002 (0x3ea)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34380709888 (0x801400000)
stat("/tmp/emacs1002/foobar",{ mode=srwx------ ,inode=23,size=0,blksize=4096 }) = 0 (0x0)
geteuid()                                       = 1002 (0x3ea)
madvise(0x801406000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x801400030,0x800de29e0) = 0 (0x0)
connect(3,{ AF_UNIX "/tmp/emacs1002/foobar" },23) = 0 (0x0)

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Glenn Morris]

Wolfgang Jenkner wrote:

> Since connect() is a syscall you could run emacsclient under strace to
> easily find out with which arguments it is called. 

(Perhaps emacsclient should get a --debug argument that prints such things.)

Please also post the result of

emacs -Q -l server
C-h v server-socket-dir

bug#20999: 24.4; Inconsistent UID vs USER resolution between emacsclient and emacs daemon

[Glenn Morris]

Glenn Morris wrote:

> Wolfgang Jenkner wrote:
>
>> Since connect() is a syscall you could run emacsclient under strace to
>> easily find out with which arguments it is called. 
>
> (Perhaps emacsclient should get a --debug argument that prints such things.)
>
> Please also post the result of
>
> emacs -Q -l server
> C-h v server-socket-dir


More than a year has passed with no further information, so I'm closing this.