On 07/26/2013 05:36 AM, Anton Starikov wrote:
> Hey,
>
> I don't know how to proceed with this, as clearly thus must be patched 
> upstream, but I don't use upstream so I submit here.
>
> 1) there is parameter in "nfs" module called "nfs4_disable_idmapping", to 
> disable mapping on a client-side when AUTH_SYS. It was introduced, for 
> support of NFS4-root. But NFS4-root can work smoothly only when on both 
> sides, client and server, idmapping is disabled. It was fixed for "nfsd" in 
> fresh kernels (commit 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e9541ce8efc22c233a045f091c2b969923709038 
> ).
>
> I attach here backported patch for current 2.6.32-358 kernels. I set default 
> value of nfs4_disable_idmapping to FALSE in this patch, in order to mimic 
> behaviour of unpatched kernel. (this differs from modern kernels, where it 
> is TRUE by default).
>
>
> 2) with NFS4 mounted filesystems there is and issue with execution of files 
> which has execute-only mode (111). (Typical example: sudo will not work on 
> nfs4-root). This was also fixed relatively recently in fresh kernels. Here I 
> attach patch, which fixes that (it affects both, "nfs" and "nfsd" modules). 
> It is backported from 3.1.x.
>
>
> Without this patches, NFS4-root will never function as it really should. 
> With this patches everything works like a charm.
>
> In my setups I have this patched modules in dkms, but having them in the 
> upstream will be nice simplification of life :)
>
> Sometimes I am curious, is it really the case that nobody from EL6 users 
> uses nfs4-root, but me? :)
>
> Anton.
>

Thanks for taking the time to research, write, and send this to Scientific 
Linux!  The best way to get this patch included in a new version of Scientific 
Linux is to get the fix included further up stream.[1]  That way groups other 
than this one can benefit from your work on this issue.  From our side we try 
not to deviate very much from what our upstream provider is doing.  Our hope 
is that by following them closely we reduce the possible problems our users 
encounter.  But this can lead to some tension in the application of patches, 
particularly patches that fix problems.

One of the best ways we can give back to our upstream providers is fixes like 
this one.  I hope that you can open a bug with them so that everyone can 
benefit from this.  As a point of etiquette, they prefer not to have mention 
of SL on their bug tracker.  Our source, for any package they provide, is 
their source.  Any patches we apply are noted in the changelog with 
justifications and generally attributed to Connie, Troy (who has left us), 
myself, or the Scientific Linux Development list.

Right now our commitment to improving SL, assisting upstream in fixes, and 
generally trying to give back to the linux community at large gives us pause 
before applying any patch for upstream packages which doesn't have an 
associated bugzilla number.  They've given us so much, we want to try and give 
back where we can and help encourage others to do so in the spirit of the open 
source movement.

Again, thank you for your efforts here!  Please feel free to continue to 
contribute regularly to [log in to unmask]

Pat


[1] http://bugzilla.redhat.com/

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/