gplazma2-ldap: MAP phase throws NoSuchElementException for accounts with no secondary groups

[ArturAkh]

Summary

The gplazma2-ldap MAP plugin treats a legitimate empty secondary-group lookup as a hard exception. Authentication of any account that has no supplementary group memberships fails with an uncaught java.util.NoSuchElementException, which the door reports as Bug in plugin: and the corresponding WebDAV request is rejected (HTTP 403 Permission denied).

This breaks the common case of a service account that belongs to no secondary groups — including monitoring/service identities used for WebDAV PUT.

Environment

• dCache 12.0.3 (source checked; behavior identical on master).
• gplazma LDAP plugin in simple bind mode against an LDAP directory that (correctly) returns zero group matches for accounts with no memberUid-based group membership.

Failure mechanism

During the map phase, the plugin unconditionally performs a supplementary-group search and adds the results to the subject's GIDs:

modules/gplazma2-ldap/src/main/java/org/dcache/gplazma/plugins/Ldap.java

principals.addAll(getGroupsByUid.searchGroup(ctx, usernamePrincipal, peopleOU, groupOU)); // Ldap.java:464

The group search collects gidNumber values via extractAttributes, which throws when the result set is empty:

private static <T> Set<T> extractAttributes(...) {
    ...
    while (sre.hasMore()) { ... }
    if (attrs.isEmpty()) {
        throw new NoSuchElementException(); // Ldap.java:644-646
    }
    return attrs;
}

When the account has no matching groups, attrs.isEmpty() is true and NoSuchElementException is thrown. It propagates out of the map chain instead of being handled as "no groups", and gPlazma reports it as a plugin bug:

java.util.NoSuchElementException: null
        at org.dcache.gplazma.plugins.Ldap.extractAttributes(Ldap.java:645)
        at org.dcache.gplazma.plugins.Ldap.lambda$static$3(Ldap.java:197)
        at org.dcache.gplazma.plugins.Ldap.map(Ldap.java:464)
        ...
(gPlazma) [WebDAV-... Login MAP ldap] Bug in plugin: ...

Result: the WebDAV request is unauthorized and rejected (observed as 403 Permission denied for PUT), even though the account's primary uid/gid resolve correctly.

Note: introspection endpoints that only report an already-created Subject (e.g. the frontend .../api/v1/user resource, which reads Subject.current() via RequestUser.getSubject() and lists the primary uid/gid) can still succeed for the same account, because they do not trigger a fresh login / do not exercise the LDAP group lookup. The failure only occurs on the login path that runs the supplementary-group search (the WebDAV door's map ldap).

Reproduction

1. Provide a bind-capable LDAP account; configure gPlazma LDAP as usual (gplazma.ldap.auth=simple, base DNs for users and groups, gplazma.ldap.group-member=memberUid).
2. Create an LDAP user with only a primary gidNumber and no group membership (no memberUid entry pointing to it from any group under the group base).
3. Attempt a WebDAV login / PUT with that identity.

Expected: account authenticates and maps to its primary uid/gid (possibly with no supplementary groups).

Actual: NoSuchElementException escapes as Bug in plugin:, and the request is rejected.

Suggested fix(es)

1. Treat an empty group result as "no supplementary groups" instead of an error:
   • In extractAttributes (and the single-value extractAttribute), return an empty set / throw a catchable signal rather than NoSuchElementException; in map/reverseMap, handle the empty case and simply skip adding groups.
2. Alternatively/additionally, make the supplementary-group search optional for the LDAP plugin (config-controlled), since it is currently hard-wired and cannot be disabled (only the memberUid/uniqueMember schema is selectable).

---

This report was generated with the assistance of an LLM and checked by a human.

[nManger]

Update

After some additional investigation and adding information only I had, we have tracked down that the issue here was not dCache, but the fact that the group of the service user account that experienced the error was accidentally missing in LDAP (due to filter settings introduced to hide other secondary groups of users that are irrelevant to the service).

During this investigation we however discovered that there really is something strange going on in the LDAP MAP plugin:
The account having the error was the second account of this type we introduced to the system, after having done successful tests with the first one. The only difference between those two accounts is that the first account has three additional secondary group memberships, while the second has none. For both accounts the primary group is not defined in LDAP. This means that the Map plugin finished successfully for an account with secondary group memberships where the primary group listed in the user entry doesn't exist, which should not happen according to the usual unix world rules.

Steps to reproduce:

• Create a user account and give it a primary and a secondary group. Then hide/delete the primary group.
  The user should still be able to log in and write files (caveat: only verified for the case that the folder written to belongs to the secondary group and has the sgid bit set).

• Remove the user from the secondary group. Then the user should be denied and the error reported above should appear.

Suggested fix:
Add an additional test during the group lookup that the primary group principal discovered during the user lookup is one of the groups found, otherwise deny with something like "primary group does not exist" or "primary group is invalid".