# 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?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> 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
Thanks for that! Should we change auth_use_nsswitch()?
On 19 January 2019 11:30:25 pm AEDT, Dominick Grift <[email protected]> wrote:
>Russell Coker <[email protected]> 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?
--
Sent from my Huawei Mate 9 with K-9 Mail.
Russell Coker <[email protected]> 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 <[email protected]> wrote:
>>Russell Coker <[email protected]> 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
Also this whole idea of dynamic users is wacky. There are something like 2^31 UIDs, they can spare more than 1000 for daemons.
--
Sent from my Huawei Mate 9 with K-9 Mail.
Russell Coker <[email protected]> writes:
> Also this whole idea of dynamic users is wacky. There are something like 2^31 UIDs, they can spare more than 1000 for daemons.
please read this: http://0pointer.net/blog/dynamic-users-with-systemd.html
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On 1/19/19 7:43 AM, Dominick Grift wrote:
> Russell Coker <[email protected]> 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 <[email protected]> wrote:
>>> Russell Coker <[email protected]> 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