bug#1540: emacsclient -t fails under su

bug#1540: emacsclient -t fails under su

[Glenn Morris]

I'm logged into an X session as user1.
From the xterm associated with /dev/pts/12, I do:

user1> su - user2
user2> emacs -Q -nw

That works fine. Then I exit that Emacs and do:

user2> emacs -Q -f server-start &    # works fine
user2> emacsclient -c                # works fine
user2> emacsclient -t
*ERROR*: Could not open file: /dev/pts/12

(and indeed user2 does not have permissions for this file)

user2> emacsclient -t

This second attempt kills Emacs with a segfault.

bug#1540: emacsclient -t fails under su

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > I'm logged into an X session as user1.
  > From the xterm associated with /dev/pts/12, I do:
  > 
  > user1> su - user2
  > user2> emacs -Q -nw
  > 
  > That works fine. Then I exit that Emacs and do:

I analyzed this about a year ago, but forgot about it :-(

  > user2> emacs -Q -f server-start &    # works fine
  > user2> emacsclient -c                # works fine
  > user2> emacsclient -t
  > *ERROR*: Could not open file: /dev/pts/12
  > 
  > (and indeed user2 does not have permissions for this file)

One problem is here: when this happens the terminal data structure is
half created, so not complete, because of that when accessing the second
time...

  > user2> emacsclient -t
  > 
  > This second attempt kills Emacs with a segfault.

... we get a crash here.

Not sure what to do.  The quick way out would be for emacsclient to
check if the tty is writable, and refuse to try to connect in case it is
not.  But is that TRTD?

bug#1540: emacsclient -t fails under su

[Glenn Morris]

Dan Nicolaescu wrote:

> Not sure what to do.  The quick way out would be for emacsclient to
> check if the tty is writable, and refuse to try to connect in case it is
> not.  But is that TRTD?

Anything that stops the crash has to be an improvement.

I know nothing about how this all works, but my naive expectation was
that since emacs -nw works, emacsclient -t should too. But if that's
not possible, fine. If it's possible but difficult, just stopping the
crash and leaving the rest open as a wishlist is fine too.

bug#1540: emacsclient -t fails under su

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > Dan Nicolaescu wrote:
  > 
  > > Not sure what to do.  The quick way out would be for emacsclient to
  > > check if the tty is writable, and refuse to try to connect in case it is
  > > not.  But is that TRTD?
  > 
  > Anything that stops the crash has to be an improvement.

The crash should be gone now.

  > I know nothing about how this all works, but my naive expectation was
  > that since emacs -nw works, emacsclient -t should too. But if that's
  > not possible, fine. If it's possible but difficult, just stopping the
  > crash and leaving the rest open as a wishlist is fine too.

Not sure about the underlying problem. 
It would be interesting to know if this happens on all OSes.

bug#1540: emacsclient -t fails under su

[Glenn Morris]

severity 1540 wishlist
stop

Dan Nicolaescu wrote:

> The crash should be gone now.

Yes, thanks.

> Not sure about the underlying problem. 

I changed dealing with that to a wishlist item. If it turns out to be
insoluble, feel free to close or tag as wontfix

Processed: Re: bug#1540: emacsclient -t fails under su

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> severity 1540 wishlist
bug#1540: emacsclient -t fails under su
Severity set to `wishlist' from `normal'

> stop
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#1540: emacsclient -t fails under su

[Andreas Schwab]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Glenn Morris <rgm@gnu.org> writes:
>
>   > I know nothing about how this all works, but my naive expectation was
>   > that since emacs -nw works, emacsclient -t should too. But if that's
>   > not possible, fine. If it's possible but difficult, just stopping the
>   > crash and leaving the rest open as a wishlist is fine too.
>
> Not sure about the underlying problem. 

Doing it right would require passing a file descriptor instead of the
terminal name from emacsclient to emacs.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#1540: emacsclient -t fails under su

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > I know nothing about how this all works, but my naive expectation was
  > that since emacs -nw works, emacsclient -t should too.


A little explanation what is going on.  Given this example:

  > user1> su - user2
  > user2> emacs -Q -nw
  > user2> emacs -Q -f server-start &    # works fine
  > user2> emacsclient -c                # works fine
  > user2> emacsclient -t
  > *ERROR*: Could not open file: /dev/pts/12
  > 
  > (and indeed user2 does not have permissions for this file)

emacs tries to open the tty of the emacsclient process, which 
ttyname (fileno (stdout)) says it's /dev/pts/12
/dev/pts/12 is owned by user1, and user2 has no access to it

bug#1540: emacsclient -t fails under su

[Stefan Monnier]

> emacs tries to open the tty of the emacsclient process, which 
> ttyname (fileno (stdout)) says it's /dev/pts/12
> /dev/pts/12 is owned by user1, and user2 has no access to it

Indeed.  You can make it work by letting user2 create another pts for
Emacs to use and then transfer back&forth the commands on one pts to
the other.  E.g. user2 runs scren and then emacsclient -t in screen.
Or user2 does "ssh localhost" and then runs emacsclient -t in that
ssh session.  Or ...