On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
> The abstraction is meant to cover the client, not systemd internal
> specifics. A client simply accessing that DBus API won't need it and a
> client simply accessing those sockets won't need it. It very well might
> be that a profiled application is using some *ctl command from systemd
> that would need it, but in that case said command would need to be added
> to the policy and the boot-id could be added at that time.
I don't know as squid, named and samba (to name a few) generate many
denials trying to read /proc/sys/kernel/random/boot_id. None of those
are explicitly trying to use the DynamicUser feature. Could it be just a
side effect of how nsswitch.conf is setup by default?
On 2020-04-10 1:16 p.m., Jamie Strandboge wrote:
> The abstraction is meant to cover the client, not systemd internal
> specifics. A client simply accessing that DBus API won't need it and a
> client simply accessing those sockets won't need it. It very well might
> be that a profiled application is using some *ctl command from systemd
> that would need it, but in that case said command would need to be added
> to the policy and the boot-id could be added at that time.
I don't know as squid, named and samba (to name a few) generate many kernel/ random/ boot_id. None of those
denials trying to read /proc/sys/
are explicitly trying to use the DynamicUser feature. Could it be just a
side effect of how nsswitch.conf is setup by default?
$ grep systemd /etc/nsswitch.conf
passwd: files systemd
group: files systemd
Maybe you'd prefer this to be reported/discussed in a separated LP?
Regards,
Simon