Bug#471763: /var/run/screens permissions inconsistency causes screen to refuse to start up
Ambrose Li
Version: 4.0.3-7
Severity: important
The /etc/init.d/screen-cleanup script, provided by package screen,
chmod's /var/run/screen to a mode that will cause the screen command
itself, also provided by the same package, to refuse to start up.
This is after a system reboot:
{acli@tea:~}$ screen
Directory '/var/run/screen' must have mode 777.
{acli@tea:~}$ grep screen /etc/init.d/*
/etc/init.d/console-screen.sh:# Provides: console-screen
/etc/init.d/console-screen.sh:# Description: Set console screen modes and fonts
/etc/init.d/console-screen.sh:# default screen-font, screen font-map, and application charset-map,
/etc/init.d/console-screen.sh: # screensaver stuff
/etc/init.d/console-screen.sh: log_action_msg "Setting console screen modes and fonts"
/etc/init.d/gdm:# Should-Start: console-screen acpid
/etc/init.d/screen-cleanup:# Script to remove stale screen named pipes on bootup.
/etc/init.d/screen-cleanup:# Provides: screen-cleanup
/etc/init.d/screen-cleanup:# Short-Description: screen sessions cleaning
/etc/init.d/screen-cleanup:SCREENDIR=/var/run/screen
/etc/init.d/screen-cleanup:# If the local admin has used dpkg-statoverride to install screen setuid,
/etc/init.d/screen-cleanup: if [ `stat -c%a /usr/bin/screen` -ge 4000 ]; then
{acli@tea:~}$ grep chmod /etc/init.d/screen-cleanup
chmod 0755 $SCREENDIR
chmod 0775 $SCREENDIR
{acli@tea:~}$ dpkg -S /etc/init.d/screen-cleanup
screen: /etc/init.d/screen-cleanup
{acli@tea:~}$
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.16.2
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (charmap=BIG5)
Shell: /bin/sh linked to /bin/bash
Versions of packages screen depends on:
ii libc6 2.7-8 GNU C Library: Shared libraries
ii libncursesw5 5.6+20080203-1 Shared libraries for terminal hand
ii libpam0g 0.99.7.1-5 Pluggable Authentication Modules l
screen recommends no packages.
-- debconf information:
screen/old_upgrade_prompt: false
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jan Christoph Nordholz
> The /etc/init.d/screen-cleanup script, provided by package screen,
> chmod's /var/run/screen to a mode that will cause the screen command
> itself, also provided by the same package, to refuse to start up.
would you please show me the current permissions of both /usr/bin/screen
and /var/run/screen? screen wants the access bits on its fifo directory
to be as permissive as necessary and as restrictive as possible. Deviations
in either direction will evoke that warning.
+--------------------+----------------------+
| Permission Bits | Expected permissions |
| on /usr/bin/screen | of /var/run/screen |
+--------------------+----------------------+
| 0755 | 0777 |
| 2755 | 0775 | <- package default
| 4755 | 0755 |
+--------------------+----------------------+
(both owned by user root, group utmp)
Regards,
Jan
Ambrose Li
>
> would you please show me the current permissions of both /usr/bin/screen
> and /var/run/screen? screen wants the access bits on its fifo directory
> to be as permissive as necessary and as restrictive as possible. Deviations
> in either direction will evoke that warning.
The "current" permissions of /var/run/screen would be useless, because I
have changed it manually to the correct permissions already; otherwise I
can't run screen at all, and I use it every day and I only reboot this
machine for equipment upgrades or kernel upgrades.
The current permissions of /usr/bin/screen is as follows:
-rwxr-sr-x 1 root utmp 303808 2007-09-26 17:57 /usr/bin/screen
> +--------------------+----------------------+
> | Permission Bits | Expected permissions |
> | on /usr/bin/screen | of /var/run/screen |
> +--------------------+----------------------+
> | 0755 | 0777 |
> | 2755 | 0775 | <- package default
> | 4755 | 0755 |
> +--------------------+----------------------+
> (both owned by user root, group utmp)
>
>
> Regards,
>
> Jan
--
Ambrose Li <ambro...@cccgt.org>
Webmaster & de-facto in-house graphic artist
Chinese Cultural Centre of Greater Toronto / http://www.cccgt.org/
5183-5193 Sheppard Avenue East, Toronto, Ontario, Canada M1B 5Z5
+1 416 292 9293 / FAX +1 416 292 9215
Jan Christoph Nordholz
> The "current" permissions of /var/run/screen would be useless, because I
> have changed it manually to the correct permissions already; otherwise I
> can't run screen at all, and I use it every day and I only reboot this
> machine for equipment upgrades or kernel upgrades.
>
> The current permissions of /usr/bin/screen is as follows:
>
> -rwxr-sr-x 1 root utmp 303808 2007-09-26 17:57 /usr/bin/screen
this is the code in question:
[screen.c:1014]
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 screen insists on mode 0777 for the fifo socket directory, we only have
two possibilities:
1) eff_gid != st.st_gid
Could mean that either /var/run/screen is not group utmp, or the setgid bit
of the binary is being ignored (is the underlying filesystem mounted 'nosuid'?).
2) eff_gid == real_gid
Again setgid not working, or the calling user actually has utmp as his primary group.
Could you check these? If all looks ok, could you send me an strace of a screen
invocation? The last 100 lines before the error message should be enough if you
don't want to append the whole thing.
(Note that you'll have to do that as root using 'strace -u', otherwise setgid
won't work.)
Regards,
Jan
Ambrose Li
sorry, I forgot about this.
On Sun, Apr 20, 2008 at 01:15:30AM +0200, Jan Christoph Nordholz wrote:
>
> 1) eff_gid != st.st_gid
> Could mean that either /var/run/screen is not group utmp, or the setgid bit
> of the binary is being ignored (is the underlying filesystem mounted 'nosuid'?).
I checked /var/run/screen and it is owned by user root group root,
so it is not group utmp. Since this used to work, maybe the pre-
install script should enforce the group?
Regards,
Jan Christoph Nordholz
> I checked /var/run/screen and it is owned by user root group root,
> so it is not group utmp. Since this used to work, maybe the pre-
> install script should enforce the group?
so changing the group to utmp fixed the problem?
I'm at a loss how that directory has ended up with group root on your
system - the initscript creates it with the correct group if it doesn't
exist. Maybe you could extract your screen upgrade path from
/var/log/dpkg.log?
Regards,
Jan
Ambrose Li
> Hi,
>
> > I checked /var/run/screen and it is owned by user root group root,
> > so it is not group utmp. Since this used to work, maybe the pre-
> > install script should enforce the group?
>
> so changing the group to utmp fixed the problem?
I think so, if I change the group to utmp, then screen seem to work fine.
> I'm at a loss how that directory has ended up with group root on your
> system - the initscript creates it with the correct group if it doesn't
> exist. Maybe you could extract your screen upgrade path from
> /var/log/dpkg.log?
$ zgrep -w screen /var/log/dpkg.log*gz
/var/log/dpkg.log.11.gz:2007-08-21 17:57:46 upgrade screen 4.0.3-0.3+b1 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 17:57:46 status half-configured screen 4.0.3-0.3+b1
/var/log/dpkg.log.11.gz:2007-08-21 17:57:47 status unpacked screen 4.0.3-0.3+b1
/var/log/dpkg.log.11.gz:2007-08-21 17:57:47 status half-installed screen 4.0.3-0.3+b1
/var/log/dpkg.log.11.gz:2007-08-21 17:57:47 status half-installed screen 4.0.3-0.3+b1
/var/log/dpkg.log.11.gz:2007-08-21 17:57:48 status unpacked screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 17:57:48 status unpacked screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 18:24:49 status unpacked screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 18:24:49 status unpacked screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 18:24:49 status unpacked screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 18:24:49 status half-configured screen 4.0.3-3
/var/log/dpkg.log.11.gz:2007-08-21 18:24:50 status installed screen 4.0.3-3
/var/log/dpkg.log.7.gz:2007-12-07 11:33:40 upgrade screen 4.0.3-3 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:33:40 status half-configured screen 4.0.3-3
/var/log/dpkg.log.7.gz:2007-12-07 11:33:40 status unpacked screen 4.0.3-3
/var/log/dpkg.log.7.gz:2007-12-07 11:33:40 status half-installed screen 4.0.3-3
/var/log/dpkg.log.7.gz:2007-12-07 11:33:41 status half-installed screen 4.0.3-3
/var/log/dpkg.log.7.gz:2007-12-07 11:33:41 status unpacked screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:33:41 status unpacked screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:53:47 status unpacked screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:53:47 status unpacked screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:53:47 status unpacked screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:53:47 status half-configured screen 4.0.3-7
/var/log/dpkg.log.7.gz:2007-12-07 11:53:47 status installed screen 4.0.3-7
> Regards,
>
> Jan
Jan Christoph Nordholz
I'm still looking for an upgrade path that reproduces this bug.
Up to 4.0.3-0.3 /var/run/screen was part of the package tarball
(and mode 0775 root:utmp), then it got moved out of it and its
creation postponed to the initscript (for volatile /var/run mounts)
or postinst - also root:utmp and with permissions in accordance
to the setid bits on the binary.
It would be great if you could show me a way to see this happen
myself. Until then I don't want to change the lines in the initscript
and probably "cover" the bug.
Regards,
Jan
Ambrose Li
Sorry, I don't have an "upgrade path". I only do the sporadic "apt-get
upgrade" and an "apt-get dist-upgrade" once in a blue moon. Sometimes
things don't work out and when I report that they just say "upgrading
from xxx to yyy is not supported" even though I have no intention to
nor would I have know that my apt-get upgrade would have resulted in
something unsupported.
Basically I feel that this points to a design flaw in the apt system,
but I have said that before and people had not agreed with me, though
I cannot understand why.
>
>
> Regards,
>
> Jan
Regards,
Jan Christoph Nordholz
> Sorry, I don't have an "upgrade path". I only do the sporadic "apt-get
> upgrade" and an "apt-get dist-upgrade" once in a blue moon. Sometimes
> things don't work out and when I report that they just say "upgrading
> from xxx to yyy is not supported" even though I have no intention to
> nor would I have know that my apt-get upgrade would have resulted in
> something unsupported.
well, as long as you don't do upgrades between versions that are more than
a whole release apart (i.e. something pre-etch to something post-lenny),
there should be no problem. Could you email me (without CCing the BTS,
if you want) those lines of your /var/log/dpkg.log that pertain to screen
package upgrades? Then I can try to reproduce that sequence and see
whether the problem appears...
Regards,
Jan