Re: 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
>> thanks

>> Herbert Poetzl wrote:

>>> we now understand the problem, and it was fixed for 
>>> 3.0.4 with the following patch: 

>>> http://vserver.13thfloor.at/ExperimentalT/delta-nfs-fix02.diff

>> 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
>> Lenny.

> I'll update to vs2.6.32.48-vs2.3.0.36.29.8 which includes the
> above and one other NFS fix
> <http://vserver.13thfloor.at/ExperimentalT/delta-nfs-fix01.diff>.

> 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)

HTH,
Herbert

> Ben.

> -- 
> Ben Hutchings
> Computers are not intelligent.	They only think they are.