Comment 7 for bug 75602

I don't know of any progress. The situation last I knew remained that with /etc/group it is absurdly expensive not to cache the info from libc; with nscd, I'm not sure any profiling has been done. I don't know how the common distributions configure by default in recent versions.

By hacking the dbus code you can trivially disable the caching of group information, but the question is just whether that will slow performance to a crawl. Remember the stuff dbus is doing happens for *every message* - it has to check what groups the user sending the message is in. Opening a file or making a blocking network request for every message will be too expensive.

This may or may not be hard to fix, or may or may not even be a real problem with "normal" configurations shipped by distributions these days. All I really know for sure is that when originally implementing this feature (on some years-old Fedora or Red Hat flavor), the caching was necessary to avoid parsing /etc/groups over and over.

So, what we need is research first of all.

If it is still too slow to turn off the cache, perhaps a fix would be to expire the cache after some period of time. However I would not spend time on that without first just documenting the situation (what libc is doing, and how fast it is, in typical configurations).