182 lines
6.8 KiB
Text
182 lines
6.8 KiB
Text
Screen Information
|
|
==================
|
|
|
|
See the copyright file for information about where to get screen,
|
|
licensing, and other assorted information.
|
|
|
|
|
|
Debian Modifications
|
|
--------------------
|
|
* added Debian package maintenance files
|
|
* Use /run/screen as socket directory
|
|
* udeb only: Use setgid "utmp" instead of setuid root or
|
|
libutempter.
|
|
|
|
|
|
Debian Screen Q&A
|
|
-----------------
|
|
|
|
Q: screen always complains about the permissions of /run/screen.
|
|
What's wrong?
|
|
|
|
A: Simplified, the binary ensures that $SCREENDIR has just enough
|
|
permission bits enabled so that each user can create and access his
|
|
socket directory. This means:
|
|
|
|
/usr/bin/screen setuid root -> /run/screen 0755
|
|
/usr/bin/screen setgid utmp -> /run/screen 0775
|
|
/usr/bin/screen without setid bits -> /run/screen 0777
|
|
|
|
These cases are all handled by the init script or by the tmpfiles.d
|
|
configuration documented later in this file. However, the actual
|
|
test is a bit more complicated. And as the variable names are all
|
|
quite self-explanatory, just have a look at the C code itself:
|
|
|
|
] n = (eff_uid == 0 && (real_uid || (st.st_mode & 0775) != 0775)) ? 0755 :
|
|
] (eff_gid == (int)st.st_gid && eff_gid != real_gid) ? 0775 :
|
|
] 0777;
|
|
] if (((int)st.st_mode & 0777) != n)
|
|
] Panic(0, "Directory '%s' must have mode %03o.", SockDir, n);
|
|
|
|
If the invoking user has primary group utmp, the above assumption
|
|
will fail. The same holds if the underlying file system is mounted
|
|
'nosuid'. In these cases you have to adapt the init script or
|
|
tmpfiles.d configuration yourself.
|
|
|
|
|
|
Q: shift+page up in xterm/gnome-terminal/konsole used to let me scroll
|
|
back a bit, but now it doesn't. How can I make it work with
|
|
scrollback?
|
|
|
|
A: It doesn't scrollback consistently because screen (the program)
|
|
displays in xterm's alternate screen buffer.
|
|
|
|
To have screen use xterm's normal screen buffer (which includes
|
|
scrollback), you can add the following to your .screenrc:
|
|
|
|
termcapinfo xterm|xterms|xs|rxvt ti@:te@
|
|
|
|
|
|
Q: Screen sets my xterm titlebar. I don't like this, how do I make it
|
|
stop?
|
|
|
|
A: The titlebar setting is set in the /etc/screenrc by telling screen
|
|
that some of the GUI terminals have a hardstatus line and that it
|
|
can be set by sending the xterm escape sequences that set the
|
|
title/icon.
|
|
|
|
# Set the hardstatus prop on gui terms to set the titlebar/icon title
|
|
termcapinfo xterm*|rxvt*|kterm*|Eterm* hs:ts=\E]0;:fs=\007:ds=\E]0;\007
|
|
|
|
You can override this on a system wide basis by commenting out this
|
|
line in the /etc/screenrc or you can override it in your personal
|
|
screenrc by adding the following line:
|
|
|
|
hardstatus alwaysmessage
|
|
|
|
|
|
Q: Why do I get #!$@#$@!% trailing spaces when I cut and paste from
|
|
mutt running within screen?
|
|
Q: Why does the statusbar in my irc client extend to the end of the
|
|
screen in xterm but not in screen?
|
|
|
|
A: This has to do with handling of the bce terminal attribute, or lack
|
|
thereof by default in screen. You can enable bce on a per-user
|
|
basis by adding the following to your .screenrc:
|
|
|
|
defbce on
|
|
term screen-bce
|
|
|
|
NOTE: if you do this your TERM will be screen-bce. When you login
|
|
to other machines they may not have a screen-bce terminal
|
|
type, so you will see errors. To fix this you must put the
|
|
terminfo for screen-bce on that remote machine. The screen
|
|
terminfo is found in
|
|
/usr/share/doc/screen/terminfo/screeninfo.src and you can
|
|
compile it on the remote machine using tic(1).
|
|
|
|
|
|
Q: Screen doesn't notice when I resize the term - what's wrong?
|
|
|
|
A: Firstly look for the same question in FAQ.gz. If the problem
|
|
persists: There have been reports of sshd instances blocking
|
|
SIGWINCH (presumably restarted from aptitude and thus inheriting
|
|
its signal mask) which therefore also prohibit remote screen
|
|
sessions from ever seeing the signal. Have a look at the old
|
|
bugreport <https://bugs.debian.org/392302> for means to determine
|
|
whether you are affected. (You might have to restart sshd with a
|
|
crontab entry or similar magic if ssh is your only way to access
|
|
the box.)
|
|
|
|
|
|
Q: Multiuser mode is not working - how can I enable it?
|
|
|
|
A: Screen has to be setuid root to accomplish this. (Note the security
|
|
implications this has! See e.g. https://bugs.debian.org/852484 for
|
|
a bug which becomes a root exploit with this. Also bear in mind
|
|
that setuid programs remove some variables from their environment
|
|
for exactly this reason - see ld.so(1).) If you still want to
|
|
enable the feature, you may do so with the following commands:
|
|
|
|
] dpkg-statoverride --update --add root root 4755 /usr/bin/screen
|
|
] chmod 0755 /run/screen
|
|
] echo 'd /run/screen 0755 root utmp' > /etc/tmpfiles.d/screen-cleanup.conf
|
|
|
|
dpkg-statoverride will make sure that the modified permissions
|
|
remain in effect even if a new version of the screen package is
|
|
installed. /run/screen will be automatically recreated with the
|
|
proper permissions if the directory lives on volatile storage
|
|
(doesn't persist between subsequent reboots).
|
|
|
|
|
|
Q: I've configured screen with different permissions, but I want to go
|
|
back to the default setgid configuration - how can I do that?
|
|
|
|
A:
|
|
|
|
] dpkg-statoverride --remove /usr/bin/screen
|
|
] chmod 1777 /run/screen
|
|
] rm /etc/tmpfiles.d/screen-cleanup.conf
|
|
|
|
|
|
Q: When I'm using ssh from inside screen, I get the error message
|
|
"Error opening terminal: screen.xterm-256color." or similar.
|
|
|
|
A: The TERM variable inside a screen session (which is then passed to
|
|
the remote shell by ssh) depends on two things:
|
|
|
|
1. Availability of specific termcap entries locally.
|
|
2. Value of the TERM variable when the session was started.
|
|
|
|
To avoid this error message, the best way is to start a new screen
|
|
session under different terminal settings, but there are also ways
|
|
without starting a new sessions. You have several options:
|
|
|
|
Without starting a new screen session:
|
|
|
|
* Start ssh with "env TERM=screen-256color ssh".
|
|
|
|
* Install ncurses-term on the remote machine and then start a new
|
|
ssh session. (Might help, depending on the remote distribution.)
|
|
|
|
Exiting the current screen session, change one of the following and
|
|
start a new screen session:
|
|
|
|
* Add "term screen-256color" to ~/.screenrc or /etc/screenrc on
|
|
your local machine.
|
|
|
|
* Start the new screen session with "env TERM=xterm screen".
|
|
|
|
* Start the new screen session with "screen -T screen-256color".
|
|
|
|
* Uninstall ncurses-term locally and then start a new screen
|
|
session. (Might help, depending on the remote distribution.)
|
|
|
|
If "screen-256color" is not available on the remote distribution
|
|
either, especially if it's not a recent release, try just "screen"
|
|
instead of "screen-256color".
|
|
|
|
See https://bugs.debian.org/854414 for a thorough discussion on
|
|
this topic.
|
|
|
|
-- Axel Beckert <abe@debian.org>, Thu, 20 Jul 2017 23:54:05 +0200
|