Dbus and pam_group.so don't understand each other

[Dariem Pérez Herrera]

Oh, my mistake. I should said something like getgroups(), but receiving an user as argument. Well, maybe this function doesn't exist, but maybe there is some alternative way...

The problem of telling to dbus a specific policy for group domain users is that those users/groups are supplied by libnss_winbind.so, which provides an interface to winbind daemon (samba), which obtains groups information through network from Microsoft(R) Active Directory. Something similar should happen when using libnss_ldap.so for obtaining groups from an LDAP server. If network fails, it is impossible for NSS to obtain those groups. So, the solution is to assign to plugdev all those external users/groups, so network failures don't interrupt dbus/hal advantages (besides, it is the smarter and cleaner way, I think). This is done via pam_group.so during the authentication process. Using the alternative of putting domain users in dbus/hal configuration, it happens that when a group "disappears" (network failure), dbus doesn't recognize it anymore, still when the network is reestablished, so immediate action to take is to restart dbus (annoying and impractical).

By the way, all these problems are solved in Ubuntu dbus version. But now I'm using Gentoo. So I thing a solution is available somehow.




> 
> Hi Dariem,
> 
> The problem is that getgrent() doesn't know anything about pam_group.so,
> so
> it won't be able to help here.  pam_group.so is only used on session
> creation, which is the job of gdm (or whatever you use instead), not dbus.
> 
> What do you mean "this group is lost" on network failure?  Lost from
> where?
> 
> The suggestion of PolicyKit/ConsoleKit doesn't solve your problem right
> away, but the idea is access control without using unix groups at all,
> which
> avoids this problem (and maybe creates new ones).  Example:
> http://hal.freedesktop.org/docs/PolicyKit/intro-define-problem.html
> 
> Have fun,
> 
> Avery