On 1/19/19 7:43 AM, Dominick Grift wrote:
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.
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@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?
--
Chris PeBenito
