On Thu, Nov 30, 2023 at 09:40:47AM +0100, Martin Kletzander wrote: > On Wed, Nov 29, 2023 at 12:30:19PM -0600, Andrea Bolognani wrote: > > On Wed, Nov 29, 2023 at 10:49:23AM +0000, Richard W.M. Jones wrote: > > > On Wed, Nov 29, 2023 at 05:44:59AM -0500, Andrea Bolognani wrote: > > > > I assume you're running Fedora/RHEL on your laptop, and the policy > > > > there is that services (or sockets) should not be started right after > > > > a package is installed. Debian has the opposite policy. > > > > > > I think this is a very weird choice (for Fedora). Why would > > > installing the package not start the service, but then the service > > > would be started without further intervention after reboot? It's the > > > opposite of predictable behaviour. > > > > I believe that the rationale is that a newly-installed service might > > need to be configured before it can work correctly/securely. Not > > starting it right away provides a temporal window that can be used to > > perform the initial configuration, and which is entirely under the > > local admin's control. > > One could argue that the maintainer should be able to decide that based > on whether the service is configured with safe defaults from the get go. The maintainer's definition of "safe" might not match the local admin's. There might be additional constraints that are specific to the local environment and that upstream can't possibly know about. > Not to mention that your rationale is void once someone reboots. Rebooting is a pretty explicit choice by the admin, just like manually starting the service. That's what I meant when I said that the temporal window is entirely under the local admin's control. > On the > other hand when you start only the sockets you can still configure the > service before connecting to it. If you started the sockets, any user on the system would be able to trigger startup of the daemon by connecting to the read/only one, possibly at a time when the final configuration is not in place yet. Incidentally, "any user on the system can open a read/only connection to libvirt" is a perfect example of a configuration that the local admin might not like :) We have recently made it possible to conveniently disable the read/only (and admin) socket altogether to minimize the attack surface for the daemon, but again that requires explicit configuration by the local admin. > I feel like "enable but don't start" is a middle ground between seamless > user experience and safe defaults. It does none of that. I think > either default would be better than the current state, but that's > swaying from what we're trying to fix here. Yeah, as I said it's a distro-wide policy so we don't really have any control over it. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
