Bug#633526: vserver kernel breaks ssh public_key authentication on NFS
On Tue, Dec 13, 2011 at 07:03:45AM +0000, Ben Hutchings wrote:
> On Thu, 2011-12-01 at 14:52 +0100, Mirco Bauer wrote:
>> tags 633526 + patch
>> retitle 633526 NFS client uid/gid cache broken on VServer kernels
>> Herbert Poetzl wrote:
>>> we now understand the problem, and it was fixed for
>>> 3.0.4 with the following patch:
>> I can confirm that this patch is fixing the issue. I have
>> tested the patch on top of linux-2.6 2.6.32-37 on a production
>> server and we no longer experience the NFS uid/gid issue.
>> The issue can easily be tested by doing "ls -l $file" on a NFS
>> mount. The values will show up correctly. After "cat $file >
>> /dev/null; ls -l $file" it will suddenly show wrong uid/gid
>> values of: 4294967294/4294967294 (-2/-2) Waiting for about 20
>> seconds "ls -l $file" will show again correct values. So the
>> client cached values are clearly the problem.
>> I strongly recommend to include the patch into the next stable
>> point release as this is major NFS regression from Debian
> I'll update to vs18.104.22.168-vs22.214.171.124.29.8 which includes the
> above and one other NFS fix
> Herbert, if you could briefly explain what the two changes are
> doing that would be helpful.
well, the first one fixes a long outstanding bug, which
was caused by using the wrong macros INOTAG_* instead
of TAGINO_*, which, depending on the tagging and actual
uid/gid/tag will result in funny numbers ...
the second one doesn't fix any real issue, but it is a
more defensive solution for the potentially possible
case where NFS_ATTR_FATTR_OWNER is set but the group
nfs attribute is not (or the other way round)
> Ben Hutchings
> Computers are not intelligent. They only think they are.