Apparently some other distributions out there automate security updates a little more than we currently can do, by restarting affected services when a security update is done. I am pretty sure it's not a good idea to do this automatically, but (1) listing related services in the GLSA xml (2) talking about services to restart in Resolution guidelines and (3) having an option (-F ?) in glsa-check to both upgrade and restart related services (that happen to be running) would probably be a good idea. I know some users are already waiting for this. I see at least one problem with that, which is sometimes we just don't know what the related services are (for example a library vulnerability). In this case we could have a wildcard attribute saying 'could be anything, better reboot' or have a tool to determine if possible the list of affected package and tell people in GSLA to run the tool. Comments welcome...
XML-wise the following should be fine: <metadata tag="affected-system-services">name-of-service</metadata> ... and /etc/init.d/name-of-service restart gets issued.
The following should be even saner: <metadata tag="affected-system-services"> <metadata tag="affected-service" action="restart">name-of-service-1</metadata> <metadata tag="affected-service" action="stop,cleanCache,start">name-of-service-2</metadata> </metadata> This allows for several actions to be executed for irregular services as in name-of-service2 if we happen to need such behaviour.
I'd rather avoid the introduction of xml unless it's needed... in this case, just specifying a matrix of scripts to fool with depending on the end result of the merge (eg, is it upgraded, umerged, etc). I'd poke the community to find out exactly what they need; I suspect any code that runs between/after detected upgrades they'll want to extend for their own packages (eg, you're upgrading mysql from v3 to v4, run this script)...
> I'd rather avoid the introduction of xml unless it's needed... Our GLSAs are XML-based and that's what glsa-check reads...
so any addition to the GLSA syntax is now specified as <metadata> or what?
Using <metadata> is the only way of adding information without changing the DTD, so it's an easier change. That said, given the range of implications of this change, I think a DTD modification is our smallest issue, and this deserves it's own tags in a glsa.xml.
so anyone up for it? As long as the DTD is backwards compatible I don't have any problems with a new optional <service-restart> tag or similar, just using <metadata> for real data strikes me as odd and should be avoided.
Hmm, if noone is interested in this anymore maybe the bug should be closed ...
I guess the bug was lost for us. Sounds like a very useful feature:) Security any further comments?
Some thoughts: * Shouldn't the user run etc-update in between emerge and init.d restart? How do we cope with that? * Shouldn't this be handled by the package manager itself? I mean, this issue comes up at every upgrade / useflag change there is, not only on security-related updates. Why is it different here? * What about other scripts necessary to run, like database converts, or references to update guides within the Gentoo docs?
(In reply to comment #10) > Some thoughts: > > * Shouldn't the user run etc-update in between emerge and init.d restart? > How do we cope with that? That's rather easy to check (which package owns the service, and does that package have any pending config updates), so we could complain about it. > * Shouldn't this be handled by the package manager itself? I mean, this > issue comes up at every upgrade / useflag change there is, not only > on security-related updates. Why is it different here? Impact I assume, but you're right that it's a more general issue. Thinking about it, the real issue would be to keep track which services have already been restarted (manually), without depending on baselayout/openrc internals. So currently I guess the best we could do is to have emerge spit out a generic (ewarn) message to restart services X, Y and Z after a package update, but then ebuilds can already do that on their own (and has nothing to do with security anyway), and this would be a dupe of #47336 > * What about other scripts necessary to run, like database converts, or > references to update guides within the Gentoo docs? postinst notices should cover those, not much to automate as those usually require customization by the user (or they could be run by the ebuild)
It isn't possible for security to advise which services have to restart. Well, if there's a vulnerability in a small package like net-ftp/vsftpd itself it would be easy to advise to restart any running vsftpd service. However what do you want to do when dev-libs/openssl was updated? It is impossible for us to list all possible application using dev-libs/openssl. But we already have a solution in the repository. See app-admin/needrestart or app-admin/restart_services. Bot application will detect services based on deleted files in use.
