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

[Yavor Doganov]

Control: severity -1 important

On Sun, 01 Sep 2019 14:24:05 +0300,
Alan Jenkins wrote:
> Package: gnustep-base-runtime
> Version: 1.26.0-4
> Severity: grave
> Tags: security
> Justification: user security hole

Many thanks for the report but like Michael Biebl I disagree with the
severity.  This is an unfortunate regression that I'd like to fix in
buster but I don't think it has anything to do with security.  If the
gdomap daemon is vulnerable that is a separate issue which may or may
not be RC.

Starting the daemon has been the default in Debian for many years;
people rightfully complained about it since 99.5% of the users won't
need it.

> "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.

Indeed, thanks for the analysis.  I thought I have followed Policy to
the letter but apparently missed this, and my tests on a sid system
back then were somehow successful which has misleaded me, apparently.
 
Michael Biebl wrote:
> On 01.09.19 13:52, Michael Biebl wrote:
> > 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"
> 
> But since /etc/default/gdomap could have been upgraded in the mean time,
> not finding ENABLED=NO in /etc/default/gdomap probably also means that
> you want to remove the /etc/rc?.d/???gdomap symlinks.
> 
> That on the other hand could blow away the changes for a system where
> gdomap was explicity enable via "update-rc.d enable gdomap", so you need
> to handle that case as well (i.e. don't remove the symlinks if there is
> no ENABLED= key but a /etc/rc2.d/S??gdomap symlink)

IOW, something like this snippet:

if [ ! -h /etc/rc2.d/S*gdomap ]; then
    find /etc/rc?.d -name \*gdomap -delete
fi

Seems a bit brutal to me but it looks like there is no other way.