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.