[systemd-devel] Antw: Re: Antw: [EXT] Re: advice on how to address selinux-autorelabel issue with userdbd

[Ulrich Windl]

>>> Lennart Poettering <mzerqung at 0pointer.de> schrieb am 14.07.2020 um 11:35
in
Nachricht <20200714093554.GC181282 at gardel-login>:
> On Di, 14.07.20 11:02, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) 
> wrote:
> 
>> >>> Lennart Poettering <mzerqung at 0pointer.de> schrieb am 14.07.2020 um
09:50
>> in
>> Nachricht <20200714075029.GC180968 at gardel-login>:
>> > On Di, 14.07.20 09:10, Dac Override (dac.override at gmail.com) wrote:
>> >
>> >> selinux-autorelabel needs to be able to resolve users. Currently users
>> >> managed with systemd-serdbd are not resolvable in the
>> >> selinux-autorelabel.target..
>> >>
>> >> Should I be able to pull systemd.userdvd into the
>> >> selinux-autorelabel.target? Is there a better way to ensure that homed
>> >> users are resolvable when selinux-autorelabel.service runs?
>> >
>> > systemd-homed runs after /home, and the selinux relabel stuff runs
>> > much earlier, no?
>> >
>> > How does this work for LDAP/NIS/… users? They typically are late boot
>> > stuff too?
>>
>> Yes, it is a problem even at different places: You cannot use an LDAP user

> for
>> any tmpfiles, even if the directory is used only after LDAP us up.
> 
> We explicitly document that system users/groups cannot be served by
> LDAP, and if you do that you use systemd outside of its documented
> intended work environment:
> 
> https://systemd.io/UIDS-GIDS 
> 
> See last paragraph in the "Special Distribution UID ranges" section.
> 
> systemd-tmpfiles is a tool for creating system files/dirs, and runs
> very early. We explicitly don't support it being used for anything
> else, i.e. for creating files for regular users.
> 
>> Also the
>> password utilities refuse to add the same user locally that exists in
LDAP.
>> Typically I restart the tmpfiles unit again manually and then things are
OK.
>> (In this regard NFS "bg" mounts are much smarter than systemd's tmpfiles
>> unit.)
> 
> Don#t use tmpfiles for regular user stuff, do not use it for LDAP
> users. It's not for that. It's a usecase we explicitly do not cover. Sorry.

Hi!

I fully understand that you have no support for it, but when coming from a
system where those directories existed when booting, one needs to model it some
how.
Originally the directories required were created during package installation,
also setting the proper permissions. So you could verify that everything is
fine.
With systemd I tried to let it create the required directories at boot time
instead, because this is where they are needed. As there exists some mechanism
to create "tmpfiles". I used it.
As it seems to me this solution covers only part of the compatibility issue,
i.e.: the most essential services. For higher-level add-on services this is not
that nice.

The alternatives I see are:
a) Create another unit that creates files and directories _after_ the name
lookup services are up
b) Change each unit to re-create the required directories if they are missing

To me a) seems the more logical approach, while b) seems to be the more
modular approach.

I'm not 100% happy with any of those work-arounds. in a 100% clean concept
there would not be such issues.

Ulrich

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin