--mirror does not work with non-local users & groups

[grawity]

I am trying to use the --mirror option with LDAP (Active Directory) users and groups. However, this doesn't work at all with the way bindfs currently builds its gid cache:

• The system's LDAP client does not allow remote users to be enumerated, so they do not show up in getpwent().
• Likewise, LDAP groups does not show up in getgrent() enumeration, and their member list cannot be obtained using getgr{nam,uid}().
• (This was done for performance reasons. I already tried allowing enumeration, and bindfs spent several minutes doing nothing else but building its cache. That's not going to work.)

To cope with such environments, bindfs needs to query user information on demand via getpwuid() and initgroups(). (Or even better: if FUSE allows it, it should just use the current credentials of the process accessing it...)

[mpartel]

Thanks for reporting, I'll try to look into this in a week or two.

[mpartel]

Alright, could you see if https://github.com/mpartel/bindfs/pull/63 works for you? It adds an option --no-user-group-precaching, which makes the cache on-demand.

[grawity]

Thanks. Now --mirror-only=@domain_users successfully matches the users' primary group.

It still doesn't work if I try to specify one of the users' additional groups (although they're shown by id $user or getent initgroups $user), but I can live with that.

[grawity]

(It seems I didn't need to use --no-user-group-precaching, since bindfs now seems to perform on-demand lookups in any case. That's good.)

[mpartel]

Ok, good to hear.

I'll need to take another look at my code. Without the new flag, it should still read through the entire user database at startup, and additional groups should of course work.

[grawity]

Without the new flag, it should still read through the entire user database at startup

Well, that's only the local accounts – as I mentioned, the system itself does not expose LDAP/AD users to enumeration by default, and neither does it expose the member list when calling getgrnam/getgruid...

As far as I know, the only way to reliably retrieve those additional groups for a user is initgroups(uid).

[mpartel]

Whoops, you're right.

neither does it expose the member list when calling getgrnam/getgruid

That explains why the supplementary groups don't work.

Did you mean getgrouplist (which I only discovered now)? initgroups seems to be about setting the active groups of the calling process. I'll change the code to optionally use getgrouplist when I have a few moments to work on this again (busy month).

[mpartel]

Or if you'd like to try it sooner, see userinfo.c:258 in the PR.

[grawity]

Ah yes, I completely forgot about getgrouplist() and just went with how the getent utility calls it...