Does xrootd-multiuser require local /etc/passwd entries, or should NSS/SSSD-only users work?

[bellarandu]

Hi,

We are testing xrootd-multiuser in a containerized deployment and would like to clarify whether it is expected to work with users that are available only through NSS/SSSD (LDAP), without a local static entry in /etc/passwd.

Environment

• xrootd-multiuser enabled
• XRootD server version: 5.9.1
• containerized deployment
• authentication via krb5
• identity lookup via sssd/LDAP
• inside the XRootD container, both getent passwd duran and id duran succeed

Observed behavior

When the user is not present in local /etc/passwd, XRootD denies access with:

Multiuser denying access: XRootD mapped request to username that does not exist: duran

However, after we explicitly append the user and primary group into the container’s local /etc/passwd and /etc/group, xrootd-multiuser works correctly and file operations succeed. ## Relevant log excerpt

Without local passwd/group entry:

XrootdXeq: ... login as duran
multiuser_UserSentry: Multiuser denying access: XRootD mapped request to username that does not exist: duran

With local passwd/group entry:

XrootdXeq: ... login as duran
multiuser_UserSentry: Switching FS uid for user duran

Questions

1. Is it expected that xrootd-multiuser requires the mapped user to exist in local /etc/passwd and /etc/group?
2. Or should NSS/SSSD-resolved users work without local static passwd/group entries?
3. If NSS/SSSD-only users are supposed to work, is there any specific configuration needed? ## Why we are asking

The same general user environment worked previously when XRootD was deployed directly on a physical host. We only ran into this behavior after moving XRootD into a container, where NSS/SSSD resolution still works, but xrootd-multiuser appears to reject users unless they are also present in local passwd/group files.

Current workaround: at container startup, we resolve an allowlist of users through SSSD and materialize them into local /etc/passwd and /etc/group before starting XRootD.

Thanks!

[bellarandu]

We have an update from further testing.

Based on our current results, xrootd-multiuser can work without local static /etc/passwd entries for the target user, as long as the container reuses the host's SSSD/NSS responder environment.

What we tested

Initially, we ran a separate sssd instance inside the XRootD container. In that setup:

• getent passwd duran could succeed
• but xrootd-multiuser still rejected the user unless we explicitly materialized the user into local /etc/passwd and /etc/group

Later, we changed the setup so that the XRootD container no longer runs its own sssd, and instead reuses the host-side SSSD/NSS responder environment by bind-mounting:

• /var/lib/sss/pipes
• /var/lib/sss/mc
• /run/sssd

With this setup:

• getent passwd duran succeeds inside the container
• /etc/passwd inside the container does not contain a local duran entry
• job submission through xrootd-multiuser succeeds
• repeated submissions are fast and stable

Current conclusion

So, from our testing, xrootd-multiuser does appear able to work with LDAP/SSSD-resolved users without local static passwd entries, provided that the container is connected to the host's real SSSD/NSS responder environment.

In contrast, simply running a separate sssd inside the container was not sufficient in our case.

Remaining note

One thing we still observe is that user lookup works correctly, but group-name lookup is not fully resolved in the container (for example, getent group hepsbl is still empty, while user lookup and job submission succeed).

So our current understanding is:

• local static /etc/passwd entries are not strictly required
• but the runtime NSS/SSSD environment seen by xrootd-multiuser matters a lot
• in our case, reusing the host responder environment makes the behavior much closer to the physical-machine deployment

[bbockelm]

@bellarandu - you got it right!

This plugin works at the glibc NSSwitch level, not with /etc/passwd directly. So, if it works from within the container with your standard glibc tools (id is a lovely way to test), the plugin should work!