diff options
Diffstat (limited to 'debian/README.Debian')
| -rw-r--r-- | debian/README.Debian | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 0000000..ffd8b65 --- /dev/null +++ b/debian/README.Debian @@ -0,0 +1,182 @@ +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 |