nscd gives undefined preference with identical names (passwd)
Hi,
simple test system.
order for passwd db in nsswitch.conf is compat ldap.
Vast majority of uids/gids are on the system so "compat" (or files) must
have precedence, and normally it does.
Now when a username from /etc/passwd and from LDAP are identical (in
name) (but not in UID) whichever gets returned by NSCD depends on which
have been cached.
On resume:
journalctl enable nscd
service nscd start
getent passwd paola
paola:x:1000:1000:Paola,,,:/home/paola:/bin/bash
Go to location with LDAP file:
cd /wherever
vdir
drwxrwxrwx 1 paola chica 0 Jul 13 17:22 paola <-- paola:chica are
LDAP names
getent passwd paola
paola:x:1000001:1000001:paola:/home/paola:/bin/sh
disable nscd for now:
service nscd stop
getent passwd paola
paola:x:1000:1000:Paola,,,:/home/paola:/bin/bash
So basically you get reversed behaviour between cached and no-cached:
- cached will give preference to reverse order apparently
- no-cached will give preference to order defined in /etc/nsswitch.conf.
LDAP is not configured for auth but now when I try to login, I get user
1000001 and won't have access to my own home directory (or that
person's).
Only way for me to solve it while retaining cache, is to:
- set positive cache to very low
- set negative cache to very long.
This is in case LDAP might not be available but files with unknown IDs
might be present on the filesystem. This might result from e.g. some tar
unpack. I don't know how to selectively use LDAP when it is/is not
available (results from VPN here) so any lookup when LDAP is not
available incurs a timeout and delay. In case the LDAP-ID-ed files are
not supposed to end up on the local filesystem (network share) they can
also not be looked-up when LDAP is not available. Therefore, any files
that end up in the negative cache are okay with being there for a very
long time. Hence positive lookups are okay with having a short cache
(enough for short-term operation somewhere) while in this scenario
negative lookups are okay with staying around for a long time.
There is an option to not forward or propagate lookups by name to the
by-uid and by-gid tables. However lookups by uid and lookups by gid are
much more common and there is no way to turn them off. There is no way
to turn propagation off from by-uid to by-name.
That would instantly solve my problem because currently lookups by name
are only done for logins and other like operations.
Saying I only really need a UID cache (UID->name) not the other way
around.
In that scenario, lookups by name would follow nsswitch order and work
fine.
Now I know you can say "having multiple ids with the same name is not
advisable" but unlike the reverse situation (multiple names per id) the
actual identifiers are unique if you count service information and/or
LDAP domain suffix (e.g. @ds, or @domain.net). Basically the names are
unique but by default Linux treats them as belonging to the same
namespace.
Which is convenient, but not if they if they become indeterministic in
disregard of the order defined in nsswitch.conf.
I ask whether the ldap>files was by design, or whether it just returns
the last element that was cached (probably).
It just overwrites the cache with the new name.
I wonder and suggest if a new option would not be needed here:
"auto-propagate-reverse" or "auto-propage-ids" in retrospect to
"auto-propagate" that only deals with id->name forwarding.
Hence I would suggest to add:
auto-propagate-name to mean the current behaviour for
auto-propagate
to deprecate auto-propagate, and to add
auto-propagate-id to do the reverse of the current option.
And maybe even just split it further
- auto-propagate-user-name
- auto-propagate-group-name
- auto-propagate-user-id
- auto-propagate-group-id
But a separation between name and ID would be fine for most purposes:
- auto-propagate-name
- auto-propagate-id
Would this be such a terrible idea?
Maybe this is not the best place to suggest this, but I thought I'd try.
Regards.
Reply to: