Russell Coker <russell@xxxxxxxxxxxx> writes: > Thanks for that! Should we change auth_use_nsswitch()? Yes but theres another thread on this maillist that is used to discus this matter, as adding support for this (and support for other systemd nss modules (like myhostname and mymachines etc) is very intrusive as it gives nss users access to dbus. So i think refpolicy is still weighing its options here. > > On 19 January 2019 11:30:25 pm AEDT, Dominick Grift <dac.override@xxxxxxxxx> wrote: >>Russell Coker <russell@xxxxxxxxxxxx> writes: >> >>It is kind of like a mcstrans thingy except this is baked into glibc >>nss >>via the nss-systemd module. it translates dymamic user id's to >>something >>that is human readable. >> >>dynamic users are temporary users identities that can be created by >>systemd >>on the fly for your service. Theres only a limeted range of system user >>identities (<1000) available and this allows one to just create an >>identity on the >>fly for a service via the systemd service unit. >> >>This is a pretty intrusive feature. Consider the following: >> >>you have a service with a dynamicuser (say "myservice") this service >>creates files for example a log file in /var/log. When the service >>exits >>the uid no longer exists and so you have a file in /var/log with a >>userid that does not exist eny longer. >> >>This is why you see the "private" dirs in /var/lib, /var/cache and >>/var/log. the services see the private dirs are the root for these >>respective dirs. (its using a symlink: example: /var/lib -> >>/var/lib/private) So the files that might end up with orphaned >>identities are atleast kept separate on the filesystem. >> >>So myservice maintains the log file in /var/log/private instead of >>/var/log "transparently" (this all needs to be configured though in the >>service unit) >> >>There can also be a file in /etc/systemd called something like >>"dont-synthesize-nobody" users of nss-systemd will look for that file >>(just a get attributes) So you might see these processes atleast >>traverse /etc/systemd, looking to see if the flag-file exists) >> >>So yes fully implementing support for dynamic users is far-reaching (i >>did this in dssp2-standard) >> >>You can play with this feature with `systemd-run --system -p ... [...] >>-t` >>To see how it behaves >> >>But anyway back to your GetDynamicUsers question: users of >>auth_use_nsswitch() (nss-systemd) need to potentially be able to >>resolve these dynamic >>user id's , for example if they read state on a system with processes >>that are associated with dynamic uids or if they need to stat files >>associated with dynamic uids. >> >>I hope this helps >> >>> # msgtype=method_call interface=org.freedesktop.systemd1.Manager >>> member=GetDynamicUsers dest=org.freedesktop.systemd1 >>> init_dbus_chat(postfix_showq_t) >>> dbus_system_bus_client(postfix_showq_t) >>> >>> # msgtype=method_call interface=org.freedesktop.systemd1.Manager >>> member=GetDynamicUsers dest=org.freedesktop.systemd1 >>> init_dbus_chat(dictd_t) >>> >>> The above is from my policy that hasn't yet seemed good enough for my >>Debian >>> tree. What is this GetDynamicUsers about and why do programs like >>dictd >>> (dictionary server) and postfix showq need it? -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
