Re: What is this GetDynamicUsers about?

[Chris PeBenito <pebenito@ieee.org>]

On 1/19/19 7:43 AM, Dominick Grift wrote:
> Russell Coker <russell@coker.com.au> 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.

It still requires further thought, but it might end up being more 
tunables and/or interfaces.  I want to make sure it's possible to split 
out the network access and dbus access (thinking ahead to the above nss 
modules).


>> On 19 January 2019 11:30:25 pm AEDT, Dominick Grift <dac.override@gmail.com> wrote:
>>> Russell Coker <russell@coker.com.au> 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?
> 


-- 
Chris PeBenito