On Суб, 05 кас 2024, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Oct 04, 2024 at 12:17:14PM -0400, David Cantrell wrote:
The common use case for this is the Fedora laptop user which in nearly every
case is going to have one local user account.
I have always split /home from the rest of the system and I know others do
as well. I would rather see anaconda modified so that if I am creating a
user account at install time, check for /home/USERNAME and if USERNAME
matches and the UID and GID matches, just don't create the home directory.
That is, -M on useradd(8).
Yeah, that's the other possible approach. But I think it's actually
quite complicated to make this work reliably. Traditional UNIX accounts
spread the information about the user over a bunch of files. Consistency
must be maintained, UIDs and GIDs on disk must match, etc. We _could_
add the smarts to cover all that in Anaconda, but Anaconda developers
are trying to simplify it, not add new complicated code.
OTOH, homed was created with the idea of self-contained "homes" from
the beginning, and systemd upstream is dedicating resources to make it
work. (E.g., currently, a full-time developer working on integration
of systemd-homed and GNOME on a grant from German STF.)
So I think it's much more maintainable to just make use of this and
let systemd upstream help with any bugs that we discover.
The homed approach would make other things possible too. For example,
sharing of /home in dual-boot scenarios. Right now a manual setup
needs to be done, and login details need to be propagated each time,
but with homed, dual-boot and reinstall are very similar scenarios,
so if we get one to work, we get the other one for free.
Can we move systemd-homed configuration and activation into something
that could be explicitly enabled by the administrators? Whether this is
done during installation or post, it still would need to be a concious
step made by admins.
Right now systemd-homed is activated on each system without ask for it,
even on systems that do not benefit from its use (see parallel
discussion by Neal). I also see it as a sole contributor to SELinux AVCs
in OpenQA tests we run for FreeIPA use cases.
It would be best to have it explicitly enabled by admins, similarly how
authselect handles various authentication methods.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
