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) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141224005935.20173.96569.report...@celidon.lan
