Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled
On 01/09/2019 12:52, Michael Biebl wrote:
On 01.09.19 13:24, Alan Jenkins wrote:
Package: gnustep-base-runtime
Version: 1.26.0-4
Severity: grave
Tags: security
Justification: user security hole
Dear Maintainer,
I had "gnustep-base-runtime" installed on my system, probably as a
dependency of "unar".
When I upgrade from Debian 9 to Debian 10 (and reboot), there is a
network server "gdomap". I did not see this server on Debian 9.
"gdomap" is not wanted. It is supposed to be disabled by default
since 2013, i.e. in Debian 8.[1]
[1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773
The problem is due to this code change:
"Disable gdomap via defaults-disabled as per Policy 9.3.3.1."
https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f
Salvatore Bonaccorso analyzed this for me:
Install a fresh stretch installation and install gnustep-base-runtime
in it. gdomap is not started by default, because gdomap init honours
the ENABLED=no setting in /etc/default/gdomap. Now update the host to
buster.
During this update /etc/default/gdomap is updated according to the
above. Unless the admin has modified it, where then it will be
noticed and admin asked for a decision. As formerly the init was
enabled, and the code to handle the ENABLED setting is removed this
might be the problem. The postinst calls update-rc.d gdomap
defaults-disabled [...]
"update-rc.d" does not do anything in this case. The man page says
If any files named /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing. The program was written this way so that
it will never change an existing configuration, which may have been
customized by the system administrator. The program will only
install links if none are present, i.e., if it appears that the
service has never been installed before.
I guess gnustep-base-runtime explicitly needs to remove the existing
/etc/rc?.d/???gdomap symlinks on upgrades in preinst (possibly guarded
by a check which reads the old /etc/default/gdomap and tests if
ENABLED=NO) so they can be properly re-created (and disabled) by
"update-rc.d defaults-disabled"
That said, I find the severity vastly exagerated, but that's just me.
Thanks. In general I don't know what to do with the severity field
:-). I maybe used it once before, and that's it.
IMO this bug is release-relevant. Then it should be "serious" or above.
#717773 points out that "unar" was installed by default, e.g. in Debian
7 Desktop. "unar" is not removed on upgrade, even after "apt
autoremove". Because "file-roller" still has "Suggests: unar".
#717773 was tagged "security", but the severity was "normal". The
current issue is slightly different to #717773, in the sense that it is
a regression.
The above is post-hoc. At the time, I just noticed that "reportbug
--mode=standard" didn't offer me the "security" tag if I filed at
severity "normal". And gdomap doesn't run as root, so it's not a root
bug ("critical").
Alan
Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled
Package: gnustep-base-runtime Version: 1.26.0-4 Severity: grave Tags: security Justification: user security hole Dear Maintainer, I had "gnustep-base-runtime" installed on my system, probably as a dependency of "unar". When I upgrade from Debian 9 to Debian 10 (and reboot), there is a network server "gdomap". I did not see this server on Debian 9. "gdomap" is not wanted. It is supposed to be disabled by default since 2013, i.e. in Debian 8.[1] [1] #717773 "/usr/bin/gdomap: please split out gdomap or disable it by default" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717773 The problem is due to this code change: "Disable gdomap via defaults-disabled as per Policy 9.3.3.1." https://salsa.debian.org/gnustep-team/gnustep-base/commit/e0da63fa9e341a38a9a493a615c2c36b8f9d418f Salvatore Bonaccorso analyzed this for me: > Install a fresh stretch installation and install gnustep-base-runtime > in it. gdomap is not started by default, because gdomap init honours > the ENABLED=no setting in /etc/default/gdomap. Now update the host to > buster. > > During this update /etc/default/gdomap is updated according to the > above. Unless the admin has modified it, where then it will be > noticed and admin asked for a decision. As formerly the init was > enabled, and the code to handle the ENABLED setting is removed this > might be the problem. The postinst calls update-rc.d gdomap > defaults-disabled [...] "update-rc.d" does not do anything in this case. The man page says > If any files named /etc/rcrunlevel.d/[SK]??name already exist then > update-rc.d does nothing. The program was written this way so that > it will never change an existing configuration, which may have been > customized by the system administrator. The program will only > install links if none are present, i.e., if it appears that the > service has never been installed before. It is unfortunate that "Policy 9.3.3.1" does not have an explicit warning about this potential security problem. So this is a problem with upgrades. It does not happen on a fresh install of Debian 10. Salvatore also suggested > I think it's best handled though in a bugreport accordngly, and once > fixed in unstable, to schedule a fix as well via a buster point > release. $ sudo netstat -l -p Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name ... udp0 0 0.0.0.0:gdomap 0.0.0.0:* 57/gdomap $ ps aux | grep gdomap nobody 57 0.0 0.0 2736 2052 ?Ss 11:16 0:00 /usr/bin/gdomap -I /var/run/gdomap.pid -p -j /var/run/gdomap $ dpkg-query -S gdomap gnustep-base-runtime: /usr/share/man/man8/gdomap.8.gz gnustep-base-runtime: /etc/default/gdomap gnustep-base-runtime: /usr/bin/gdomap gnustep-base-runtime: /etc/init.d/gdomap [Report sent from a systemd-nspawn container, which I used to reproduce the issue] -- System Information: Debian Release: 10.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.2.9-200.fc30.x86_64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnustep-base-runtime depends on: ii gnustep-base-common 1.26.0-4 ii init-system-helpers 1.56+nmu1 ii libc62.28-10 ii libgcc1 1:8.3.0-6 ii libgnustep-base1.26 1.26.0-4 ii libobjc4 8.3.0-6 ii lsb-base 10.2019051400 gnustep-base-runtime recommends no packages. gnustep-base-runtime suggests no packages. -- no debconf information
Bug#559578: [Debian-eeepc-devel] Bug#559578: 702 also
On 12/15/09, jida...@jidanni.org jida...@jidanni.org wrote: By the way, I was using a 702 8G, not a 701. Right, someone did report that. You might check what this command says: cat /sys/class/dmi/id/product_name The kernel patch I submitted will check for a product name of either 701 or 702. Thanks Alan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559578: Fwd: Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting
Hi Corentin It looks like it's not just my 701 which has problems with SHE. Given that Asus don't support it on the pre-installed OS, I think we should disable it for the 701. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578. Thanks Alan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559578: [Debian-eeepc-devel] Bug#559578: Fwd: Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting
On 12/9/09, Ben Armstrong sy...@sanctuary.nslug.ns.ca wrote: On Wed, 9 Dec 2009 11:54:54 + Alan Jenkins sourcejedi.l...@googlemail.com wrote: Hi Corentin It looks like it's not just my 701 which has problems with SHE. Given that Asus don't support it on the pre-installed OS, I think we should disable it for the 701. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578. If by we, you mean Debian, and by disable you mean disable by default, then I agree. However, I don't believe it should be disabled upstream. I have used SHE successfully on the 4G for several weeks. Although SHE became suspect when I experienced some lockups, after running for a few days with SHE disabled, I still get occasional lockups, so I don't no longer think SHE is the cause. Users ought to be given the option of re-enabling it on the 4G, but be given an appropriate caution about lack of vendor support for this configuration. Ben I think the kernel should disable SHE by default on the 701 models. I don't mind if it provides a force_cpufv option with an appropriate warning. The 701 models aren't shipped with any way to control the SHE. It is a form of overclocking which is not supported by the vendor. On the other models, SHE is a marketed feature which users will expect to work reliably. We should treat these cases differently in the kernel. I don't think it should be left to userspace to get this right. There are other distributions than debian :-). I've seen at least one desktop applet which controls SHE. I expect it has a similar option to toggle SHE automatically when switching between mains and battery power. If we change the kernel, it will affect everyone. The ABI doc for eeepc-laptop doesn't say writing to cpufv may break, so we need _some_ change to the kernel sources :). I think it's better to fix this in the code and not just add disclaimers in the documentation. Alan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting
On 12/9/09, Corentin Chary corentin.ch...@gmail.com wrote: On Wed, Dec 9, 2009 at 12:54 PM, Alan Jenkins sourcejedi.l...@googlemail.com wrote: Hi Corentin It looks like it's not just my 701 which has problems with SHE. Given that Asus don't support it on the pre-installed OS, I think we should disable it for the 701. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578. Thanks Alan But if I remember correctly, it worked fine on my 701 (only two modes, but no freeze). To trigger the bug, I have to echo 0 /sys/devices/platform/eeepc/cpufv ? Reportedly http://groups.google.com/group/linux.debian.bugs.dist/msg/9805f22bc6b8bbda. Another report says it happens only when booting in single user mode, and not every time. I can't reproduce it myself, even though it's happened to me in the past, both from writing to that file manually, and from the default configuration of eeepc-acpi-scripts. I _can_ still reproduce the strange hissing noise in performance mode. If I repeatedly plug and unplug the power adaptor with eeepc-acpi-scripts installed (triggering the switch between performance and normal), I see various kernel messages. These are the kernel init messages for the webcam and cardreader, suggesting that they are disappearing and re-appearing. I wasn't able to reproduce it without eeepc-acpi-scripts (either by plugging / unplugging repeatedly, or by toggling the value of cpufv in a scripted loop, or by both at the same time). I don't have my 701 right now, so I can't test, is there anything in dmesg or is it only a bad hardware freeze ? Apparently it's just a freeze: Indeed it sounds like 559578, and before proceeding further, though garbled, I have compared the blurred lines to a regular boot, and it turns out the final words before freezing are: Wed Dec 9 09:34:02 2009: Loading EeePC support modules...done. Wed Dec 9 09:34:02 2009: Setting super hybrid engine according to configuration...(AC)...done. http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/d3f0716684bbadd8 Anyway, if we disable it for 701, how can we detect that this is a 701 ? using dmi matching ? when only 2 modes are available ? Thanks, I would use a DMI match (product name 701). Hopefully that is distinct from the 701SD, which is marketed with SHE. I know the 900A has a distinct product name, so it seems likely. Thanks Alan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522319: assumes swapfiles are directly accessible
/var/swap is there but uswsusp runs from inside a chroot. It shouldn't assume swap is going to be directly accessible when it is a file (for a dev I guess it's fine since /dev has to be bind-mounted anyway). S'està configurant uswsusp (0.8-1.1+b1) ... stat: ha fallat stat() sobre /var/swap: El fitxer o directori no existeix dpkg: s'ha produït un error en processar uswsusp (--configure): el subprocés post-installation script retornà el codi d'eixida d'error 1 S'han trobat errors en processar: uswsusp Do you have any more specific suggestions as to how this would work, or a pointer on why this is a grave issue? It seems reasonable to expect that the swapfile can be accessed as listed in /etc/fstab. The problem isn't really unique to uswsusp; e.g. swapoff -a; swapon -a isn't going to work either. You already have to do a bit of namespace manipulation and careful thinking. You can bind mount individual files. What's wrong with adding /var/swap to the list of things you have to bind-mount? Regards Alan
