Re: [PATCH 2/2] Report better error message in remoteGetUNIXSocket
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