[Debian GNUstep maintainers] Bug#939119: gnustep-base-runtime: Upgrading to Debian 10 causes gdomap network service to become enabled

[Alan Jenkins]

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