Overriding can now happen using module options, which is preferred
because it is more discoverable and doesn't require knowledge of
overrides in the first place.
While the documentation said to set this to null, in case an imperative
config was supposed to be used, this was not possible with the typing in
place.
Database provisioning was shown to be racy since adding a recorder test
using PostgreSQL. There is no harm in waiting for these services,
because if they're not available they will be ignored.
It simply should not be required to override the package for such a
common use case, especially since the module usually adds another
override on top to inherit extraComponents.
After this change users with non-declarative configs need to set
`services.home-assistant.config` to an `null`, or their
`configuration.yaml` will be overwritten.
The reason for this is that with rfc42 style defaults the config
attribute set will never be empty by default.
If people take the time to setup network-online.target correctly we
should wait for it. If they don't it's basically the same as
network.target anyway, so no harm done.
Over time I've seen multiple integrations that have dealt badly with
missing network connectivity at startup, this should alleviate further
pains.
The given example is now closer to a sane default people will want to
start with. It also displays the existance of extraComponents, a feature
that will receive more usage with home-assistant warning about
components that have completely migrated away from YAML configuration.
Previously the extraComponents added to an overriden package would not
have been considered in hardening measures enforced by the module.
Home Assistant is warning the user about component definitions having
moved away from YAML, so using an override to include support for a
component might become the better way moving forward.
Trying to steer NixOS users away from reporting bugs to the upstream,
when they don't have the capacity to support bugs that could be the
result of our downstreaming setup.
Since v2021.5.0 home-assistant uses the ifaddr library in the zeroconf
component to enumerate network interfaces via netlink. Since discovery
is all over the place lets allow AF_NETLINK unconditionally.
It also relies on pyroute2 now, which additionally tries to access files
in /proc/net, so we relax ProtectProc a bit by default as well.
This leaves us with these options unsecured:
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets 0.3
✗ DeviceAllow= Service has a device ACL with some special devices 0.1
✗ IPAddressDeny= Service does not define an IP address allow list 0.2
✗ PrivateDevices= Service potentially has access to hardware devices 0.2
✗ PrivateUsers= Service has access to other users 0.2
✗ SystemCallFilter=~@resources System call allow list defined for service, and @resources is included (e.g. ioprio_set is allowed) 0.2
✗ RestrictAddressFamilies=~AF_NETLINK Service may allocate netlink sockets 0.1
✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1
✗ SupplementaryGroups= Service runs with supplementary groups 0.1
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
✗ ProcSubset= Service has full access to non-process /proc files (/proc subset=) 0.1
→ Overall exposure level for home-assistant.service: 1.6 OK 🙂
Home-assistant through its `--runner` commandline flag supports sending
exit code 100 when the `homeassistant.restart` service is called.
With `RestartForceExitStatus` we can listen for that specific exit code
and restart the whole systemd unit, providing an actual clean restart
with fresh processes. Additional treat exit code 100 as a successful
termination.
This is what is still exposed, and it should still allow things to work
as usual.
✗ PrivateNetwork= Service has access to the host's … 0.5
✗ RestrictAddressFamilies=~AF_(INET… Service may allocate Internet soc… 0.3
✗ DeviceAllow= Service has a device ACL with som… 0.1
✗ IPAddressDeny= Service does not define an IP add… 0.2
✗ PrivateDevices= Service potentially has access to… 0.2
✗ PrivateUsers= Service has access to other users 0.2
✗ SystemCallFilter=~@resources System call allow list defined fo… 0.2
✗ RootDirectory=/RootImage= Service runs within the host's ro… 0.1
✗ SupplementaryGroups= Service runs with supplementary g… 0.1
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets 0.1
→ Overall exposure level for home-assistant.service: 1.6 OK :-)
This can grow to as much as ~1.9 if you use one of the bluetooth or nmap
trackers or the emulated_hue component, all of which required elevated
permisssions.
We are running over 6000 tests by now and they take around 5 minutes
on faster machines and tests alot of components that endusers will not
actually be using. It is sufficient if we run them on package upgrades
and in the passthrough test.
This reverts commit f19b7b03a0, reversing
changes made to 572a864d02.
Sorry. I pushed the wrong staging-next (the one that had my master
merged in). This was not intended.
Robert Schütz