Summary: | RFC: Specifying services to restart in GLSAs (and handling them in glsa-check) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Thierry Carrez (RETIRED) <koon> |
Component: | GLSA Errors | Assignee: | Gentoo Security <security> |
Status: | RESOLVED CANTFIX | ||
Severity: | enhancement | CC: | bertrand, genone, radek, wschlich |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Thierry Carrez (RETIRED)
2004-12-21 02:17:01 UTC
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. |