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
