Bug#758870: linux: /sbin/request-key not called
Source: linux
Version: 3.16.0-4
Followup-For: Bug #758870
I have investigated further and determined that /sbin/request-key never gets called
(I intercepted calls to /sbin/request-key which a program which first logs and it didn't
even get triggered once despite using NFSv4, in this with sec=sys). As you might guess,
in my case ls -al of the offending nfs dirs fails to translate the uid/gid into local
username and group and instead, for e.g. remote id #1000 uses local uid #1000's
username instead of translating into the also present #1012 local uid (remote #1000)
It appears there is also some issue with rpc.idmapd since that is supposed to be the
fallback in case request-key fails (however I suspect what is happening is that
request_key is returning 'nothing to do here' not 'failure'.
Between the mentioned 3.8 and 3.12 versions there are several new conditions added
in linux/security/keys/request_key.c that could potentially jointly or severally
be responsible for the bad behaviour.
It looks like a clearly upstream issue.
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Reply to: