On Tue, Apr 14, 2015 at 3:37 PM, Gregory Boyce <gregory.boyce@xxxxxxxxx> wrote:
> On Fri, Apr 10, 2015 at 3:04 PM Gregory Boyce <gregory.boyce@xxxxxxxxx>
> wrote:
>>
>> On Fri, Apr 10, 2015 at 2:45 PM, Trond Myklebust
>> <trond.myklebust@xxxxxxxxxxxxxxx> wrote:
>>
>> > No. You are not supposed to be able to work around security issues,
>> > and it is indeed a security issue when a client gets a reply from an
>> > IP address that it does not recognise as being the same as the one it
>> > sent an RPC to.
>>
>> "Working around" security issues is a rather common and accepted
>> practice when there are mitigating controls in place. It's never a
>> black and white world.
>>
>
>
> The attached patch was able to work around the issue for us until we can get
> the filers working in a more expected manner. I'm sending it along in case
> anyone else can find a use for it, or if you want to apply it in order to
> give people an option for cases like this.
Re-sending since Google Inbox likes to default to HTML e-mail.
--
Greg
diff -ru nfs-utils-1.2.5.orig/utils/mount/stropts.c nfs-utils-1.2.5/utils/mount/stropts.c
--- nfs-utils-1.2.5.orig/utils/mount/stropts.c 2015-04-13 22:43:20.000000000 +0000
+++ nfs-utils-1.2.5/utils/mount/stropts.c 2015-04-13 22:47:30.000000000 +0000
@@ -497,6 +497,14 @@
struct pmap mnt_pmap;
/*
+ * "norewriteopts" option bypasses the options rewriting
+ */
+ if (po_contains(options, "norewriteopts") == PO_FOUND) {
+ po_remove_all(options, "norewriteopts");
+ return 1;
+ }
+
+ /*
* Version and transport negotiation is not required
* and does not work for RDMA mounts.
*/
