1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
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
|
