>>> Lennart Poettering <mzerq...@0pointer.de> schrieb am 14.07.2020 um 11:35 in Nachricht <20200714093554.GC181282@gardel-login>: > On Di, 14.07.20 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) > wrote: > >> >>> Lennart Poettering <mzerq...@0pointer.de> schrieb am 14.07.2020 um 09:50 >> in >> Nachricht <20200714075029.GC180968@gardel-login>: >> > On Di, 14.07.20 09:10, Dac Override (dac.overr...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
