summaryrefslogtreecommitdiffstats
path: root/debian/README.Debian
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 12:46:01 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-27 12:46:01 +0000
commitf99ae3f90a40cab5ac45a299e82a8987b7264eab (patch)
tree46554594be2eb10da0f510e9135526d680637f6f /debian/README.Debian
parentAdding upstream version 4.8.0. (diff)
downloadscreen-debian.tar.xz
screen-debian.zip
Adding debian version 4.8.0-6.debian/4.8.0-6debian
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'debian/README.Debian')
-rw-r--r--debian/README.Debian182
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