Based on common/Mapping.cc · master · dss / eos · GitLab it looks like only the local password file (or NIS/LDAP) can be used. This is an unfortunate complication for a container-based deployment, where the containers should be stateless and local user accounts don’t have much significance.
I found that if I did the local account creation first, then eos vid map, the VID mappings show a user name:
but the local user name is still not used in the final output, and also not relevant in the context of grid computing. So it would be nice if local user account management and synchronization could be avoided altogether, so only numeric UIDs and GIDs would be needed.
Hi Ryan,
I understand your idea, but at CERN it is a security risk if people can authenticate with non existent accounts. We can make a flag to not enforce existing user accounts. Still also from a practical point of view, do you really want to see arbitrary numbers as owners of directories and files? The only requirement is, that on MGMs there is uid=>name entry, that’s all. This is very convenient in general.
If you still want this, it is not a big deal to add it.
Certainly, as I understand EOS is used in different contexts, e.g. on a private network where local clients/accounts are trusted and unix/kerberos authn is used, or a public network where remote clients are not trusted and certificates or tokens are needed.
@apeters if you don’t mind, a flag to skip the check for a local account would be a big help! It would avoid some unpleasant hacks as there is not a very good solution in this situation for run-time configuration of local accounts in pre-built container images.
I’m already used to just dealing with UIDs/GIDs because dcache can do its own internal UID-name mapping (the storage-authzdb file) and we wanted to phase out the LDAP dependency that it had. There are only ~ 3-5 identities anyway.
For an HA MGM scenario this option could avoid the need to use LDAP or do local account management/synchronization across the MGM servers.
Just to make sure of the security implications, if I understand correctly the potential risk is only related to unix authentication, right?
If so I would especially want to figure out Sec.protbind config for EOS to prevent remote clients from using unix authn, but I am not sure how to proceed on that, the only remaining possibility I can think of is an xrootd-level bug (or possibly misleading/misinterpreted documentation).
If I understand correctly, we will have to use name_mapfile and/or default_user in the /etc/xrootd/scitokens.cfg config file, to map tokens to user names, not just UIDs. If so , I guess we wouldn’t be able to get around local user account management in the container images , so I will have to come up with a different workaround.
There are only ~ 3-5 identities anyway.