FS#70468 - Home-assistant 2021.4.4-2 fails with integrations like Roomba

Attached to Project: Community Packages
Opened by Joel Sevilleja (jsevilleja) - Friday, 16 April 2021, 08:44 GMT
Last edited by Maxime Gauduin (Alucryd) - Friday, 13 August 2021, 14:17 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Home-assistant fails with integrations like Roomba


Additional info:
* package version(s): 2021.4.4-2
* config and/or log files etc: Attached

Steps to reproduce: When trying to start the service, the integration can't be setup because async_dns tries to write into /.config (which doesn't exist, and doesn't have permission to).

Fix: edit systemd unit file, and add:

Environment=HOME=/var/lib/hass
WorkingDirectory=/var/lib/hass (maybe this one is unnecessary).

Kind regards,

This task depends upon

Closed by  Maxime Gauduin (Alucryd)
Friday, 13 August 2021, 14:17 GMT
Reason for closing:  Fixed
Additional comments about closing:  2021.7.4-2
Comment by Maxime Gauduin (Alucryd) - Sunday, 18 April 2021, 07:10 GMT
Is systemd listed in passwd and group in your /etc/nsswitch.conf?
Comment by Andrew West (namtabmai) - Sunday, 16 May 2021, 15:20 GMT
Yes.

/etc/passwd has the users systemd-journal-remote, systemd-network, systemd-resolve, systemd-timesync, systemd-coredump, systemd-oom
/etc/group has the groups systemd-journal, systemd-journal-remote, systemd-network, systemd-resolve, systemd-timesync, systemd-coredump, systemd-oom
/etc/nsswitch.conf has
passwd: files systemd
group: files [SUCCESS=merge] systemd
Comment by Darrell (denns) - Thursday, 15 July 2021, 00:13 GMT
I think the home-assistant package is making improper use of systemd dynamic users. Some things fail due to the home directory being "/" (the "dhcp" integration is another one that fails). However, a more serious issue is that the files in /var/lib/hass are owned by the dynamic user. As per the systemd docs, this should not be done:

"UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around"
(https://www.freedesktop.org/software/systemd/man/systemd.exec.html)

It systems that systemd dynamic users are inappropriate for services that need to store any kind of state files across restarts. I think home-assistant should be migrated to a real user instead (with it's home directory set to /var/lib/hass).
Comment by Maxime Gauduin (Alucryd) - Wednesday, 28 July 2021, 06:40 GMT
The HOME environment variable was added a while back, but it's being held back by an sqlalchemy rebuild unfortunately, will try to speed things up.

As for dynamic users, we are using them properly, I think you misunderstand what you quoted, care should be taken to not leave files _outside_ of specific directories. The StateDirectory stanza is designed to work alongside dynamic users and is chowned with every restart (and uid/gid reassigning).

Quoting systemd.exec as well: "Use StateDirectory=, CacheDirectory= and LogsDirectory= in order to assign a set of writable directories for specific purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see below)."
Comment by Maxime Gauduin (Alucryd) - Wednesday, 28 July 2021, 07:52 GMT
@jsevilleja 2021.7.4-2 is up, please give it a try.
Comment by Darrell (denns) - Tuesday, 10 August 2021, 16:54 GMT
@Alucryd

Thanks for clarifying the dynamic users. I missed the StateDirectory information when skimming the docs.

The newer releases with the HOME environment variable set have resolved the issues.

Loading...