Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-04 Thread Laurent Bonnaud
On 04/04/2017 15:58, Michael Biebl wrote:

> Can you double check that all users from
> 
> grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/
> /usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u
> 
> are available in /etc/passwd and /etc/group

Here it is:

# grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/ 
/usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u
 user="root"
 user="systemd-network"
 user="systemd-resolve"

# grep systemd /etc/passwd
systemd-timesync:x:100:103:systemd Time 
Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:104:systemd Network 
Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false

-- 
Laurent.



Bug#859451: [Pkg-utopia-maintainers] Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-04 Thread Michael Biebl
Am 04.04.2017 um 13:53 schrieb Laurent Bonnaud:
> On 04/04/2017 13:29, Simon McVittie wrote:

>> Alternatively, your NSS configuration might be such that the NSS-backed
>> library calls that dbus-daemon uses during configuration loading (mainly
>> getpwuid_r() and getgrnam_r() I think) hit the network even if the
>> group is configured locally.
> 
> In /etc/nsswitch.conf LDAP is configured as follows:
> 
> passwd: files ldap
> group:  files ldap

Any idea why NSS tries to use ldap although, as you said, all system
users are local? Can you double check that all users from

grep -s -R -E "(user|group)=" /etc/dbus-1/system.d/
/usr/share/dbus-1/system.d/ | sed 's/.*/\1/' | sort -u

are available in /etc/passwd and /etc/group



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-04 Thread Laurent Bonnaud
On 04/04/2017 13:29, Simon McVittie wrote:

> Sorry, I meant /etc/dbus-1/system.d/*.conf 

No problem!  This system has only standard unmodified stuff:

# ls -l /etc/dbus-1/system.d/
total 48
-rw-r--r-- 1 root root   947 May 26  2015 org.freedesktop.hostname1.conf
-rw-r--r-- 1 root root   937 May 26  2015 org.freedesktop.locale1.conf
-rw-r--r-- 1 root root 12499 Jul 28  2016 org.freedesktop.login1.conf
-rw-r--r-- 1 root root  1604 Jul 28  2016 org.freedesktop.network1.conf
-rw-r--r-- 1 root root   953 Jul 28  2016 org.freedesktop.resolve1.conf
-rw-r--r-- 1 root root 11898 Mar  2 09:21 org.freedesktop.systemd1.conf
-rw-r--r-- 1 root root   947 May 26  2015 org.freedesktop.timedate1.conf

> For completeness, several other paths could potentially
> mention users and groups, including /etc/dbus-1/system-local.conf
> and /usr/share/dbus-1/system.d/*.conf.

Those do not exist on this system.

> The bus configuration often also references group names and identities -
> are those all local? (I suspect not.)

In fact dbus is only installed as a dependency for libpam-systemd and I did not 
touch anything.

> Alternatively, your NSS configuration might be such that the NSS-backed
> library calls that dbus-daemon uses during configuration loading (mainly
> getpwuid_r() and getgrnam_r() I think) hit the network even if the
> group is configured locally.

In /etc/nsswitch.conf LDAP is configured as follows:

passwd: files ldap
group:  files ldap

and I use the following packages:

ii  libnss-ldapd:amd64 0.9.7-2amd64 
   NSS module for using LDAP as a naming service
ii  libpam-ldapd:amd64 0.9.7-2amd64 
   PAM module for using LDAP as an authentication service

> I'd rather not: this is very much an "at own risk, if you are absolutely
> sure you know what you are doing" option that can easily cause circular
> dependencies. (Much like getting your user and group information from
> the network, in fact...)

The suggestion in README.Debian could be preceded with a big warning such as: 

  "Warning, the following only applies to systems that use 
/etc/network/interfaces for network configuration and not daemons that use dbus 
such as NetworkManager, ConnMan, wicd, ..."

-- 
Laurent.



Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-04 Thread Simon McVittie
On Tue, 04 Apr 2017 at 12:36:35 +0200, Laurent Bonnaud wrote:
> On 03/04/2017 20:21, Simon McVittie wrote:
> 
> > Yes: if any user or group mentioned in /etc/dbus/system.d/
> > comes from LDAP, then it needs to know who they are.
> 
> This directory does not exist on this system.

Sorry, I meant /etc/dbus-1/system.d/*.conf (my earlier mail was missing
the -1). For completeness, several other paths could potentially
mention users and groups, including /etc/dbus-1/system-local.conf
and /usr/share/dbus-1/system.d/*.conf.

> > and doubly so if system users are in LDAP.
> 
> System users are all local in /etc/passwd.

That's good - it's very easy to get circular dependencies otherwise.
The bus configuration often also references group names and identities -
are those all local? (I suspect not.)

Alternatively, your NSS configuration might be such that the NSS-backed
library calls that dbus-daemon uses during configuration loading (mainly
getpwuid_r() and getgrnam_r() I think) hit the network even if the
group is configured locally.

> >>  - would it be possible to order the dbus start after network is available?
> > In general no, because some ways to get on the network require D-Bus
> > (NetworkManager, ConnMan, wicd), so you would have a circular
> > dependency.
> 
> This system is minimal and uses plain old /etc/network/interfaces

Right, so this works *for you*, but it cannot be applied in general.

> > # /etc/systemd/system/dbus.service.d/local.conf
> > [Unit]
> > Wants=network-online.target
> > After=network-online.target
> 
> How about suggesting this solution in /usr/share/doc/dbus/README.Debian?

I'd rather not: this is very much an "at own risk, if you are absolutely
sure you know what you are doing" option that can easily cause circular
dependencies. (Much like getting your user and group information from
the network, in fact...)

S



Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-04 Thread Laurent Bonnaud
On 03/04/2017 20:21, Simon McVittie wrote:

> Yes: if any user or group mentioned in /etc/dbus/system.d/
> comes from LDAP, then it needs to know who they are.

This directory does not exist on this system.

> I would not recommend using non-local NSS without some sort of cache
> (unscd, nss-updatedb or sssd), 

This system has nslcd but I think it only has RAM cache and I guess that a 
cache on persistent storage would be needed.

> and doubly so if system users are in LDAP.

System users are all local in /etc/passwd.

>>  - would it be possible to order the dbus start after network is available?
> In general no, because some ways to get on the network require D-Bus
> (NetworkManager, ConnMan, wicd), so you would have a circular
> dependency.

This system is minimal and uses plain old /etc/network/interfaces

> If you don't use any of those, then you can configure this locally
> by creating /etc/systemd/system/dbus.service.d/local.conf containing
> something like this (untested and quite possibly wrong, see systemd
> documentation):
> 
> [Unit]
> Wants=network-online.target
> After=network-online.target

Thanks for this solution!  I tried it and after a limited number of boots I 
have not seen the problem again.  Since boots are non deterministic it is not a 
perfect test, and I'll let you know if I see the error messages again.

How about suggesting this solution in /usr/share/doc/dbus/README.Debian?

-- 
Laurent.



Bug#859451: dbus: error messages on boot for systems with NSS LDAP

2017-04-03 Thread Simon McVittie
Control: tags -1 + wontfix

On Mon, 03 Apr 2017 at 19:35:36 +0200, Laurent Bonnaud wrote:
>  - does dbus really need to query the NSS databases on boot?

Yes: if any user or group mentioned in /etc/dbus/system.d/
comes from LDAP, then it needs to know who they are.

I would not recommend using non-local NSS without some sort of cache
(unscd, nss-updatedb or sssd), and doubly so if system users are in LDAP.

Unfortunately, many commonly-used packages (e.g. BlueZ) still use the
firewall-style policies found in /etc/dbus/system.d/ for group-based
access control, instead of letting all users communicate with the
service and then doing their own authorization via polkit (like
NetworkManager does).

>  - would it be possible to order the dbus start after network is available?

In general no, because some ways to get on the network require D-Bus
(NetworkManager, ConnMan, wicd), so you would have a circular
dependency.

If you don't use any of those, then you can configure this locally
by creating /etc/systemd/system/dbus.service.d/local.conf containing
something like this (untested and quite possibly wrong, see systemd
documentation):

[Unit]
Wants=network-online.target
After=network-online.target

Regards,
S