2009-12-20 01:58:57

by Michael Guntsche

[permalink] [raw]
Subject: Problem with 2.6.33-rc1 and insecure flag

Hi,

I am testing 2.6.33-rc1 on my nfs server here and I noticed a problem
with macosx clients.

Commit 12045a6ee9908b38b6d286530c7d816e39071346
nfsd: let "insecure" flag vary by pseudoflavor

seems to be the problem. For macosx clients you need to specify the
insecure flag since they try to mount with a high port per default. This
commit somehow turns the logic around. If I specify insecure I can ONLY
mount the export if I use a port <= 1023. Reverting the commit fixes the
problem for me.

Kind regards,
Michael Guntsche


2009-12-20 09:28:53

by Michael Guntsche

[permalink] [raw]
Subject: Re: Problem with 2.6.33-rc1 and insecure flag

Good morning

Some more info on this topic.

I tried mounting the same export from the server itself for testing.
Using the noresvport flag I got the same result as with the macosx
client.

mount -onoresvport gibson:/var/media /mnt
mount.nfs: Operation not permitted

The relevant part from my exports file.

/var/media 192.168.42.0/24(rw,async,no_subtree_check,insecure)
dreambox(rw,async,no_subtree_check,insecure,anonuid=1000)

Kind regards,
Michael

2009-12-20 09:46:33

by Michael Guntsche

[permalink] [raw]
Subject: Re: Problem with 2.6.33-rc1 and insecure flag

I think I figured out the problem.

Apparently the code checked if insecure was set, while it should check if it was NOT set.

Kind regards,
Michael

diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index 1c12177..55c8e63 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -89,7 +89,7 @@ static __be32 nfsd_setuser_and_check_port(struct svc_rqst *rqstp,
int flags = nfsexp_flags(rqstp, exp);

/* Check if the request originated from a secure port. */
- if (!rqstp->rq_secure && (flags & NFSEXP_INSECURE_PORT)) {
+ if (!rqstp->rq_secure && !(flags & NFSEXP_INSECURE_PORT)) {
RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
dprintk(KERN_WARNING
"nfsd: request from insecure port %s!\n",




2009-12-20 10:13:24

by Muntz, Daniel

[permalink] [raw]
Subject: RE: Problem with 2.6.33-rc1 and insecure flag

If one were to hit this bug with v4.x, would the error be something like
this in the RPC layer:

Reply State: denied (1)
Reject State: AUTH_ERROR (1)
Auth State: bad credential (seal broken) (1)

-Dan

> -----Original Message-----
> From: Michael Guntsche [mailto:mike-Z92qn3yYq0hWk0Htik3J/[email protected]]
> Sent: Sunday, December 20, 2009 1:46 AM
> To: [email protected]
> Cc: linux-nfs
> Subject: Re: Problem with 2.6.33-rc1 and insecure flag
>
> I think I figured out the problem.
>
> Apparently the code checked if insecure was set, while it
> should check if it was NOT set.
>
> Kind regards,
> Michael
>
> diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> index 1c12177..55c8e63 100644
> --- a/fs/nfsd/nfsfh.c
> +++ b/fs/nfsd/nfsfh.c
> @@ -89,7 +89,7 @@ static __be32
> nfsd_setuser_and_check_port(struct svc_rqst *rqstp,
> int flags = nfsexp_flags(rqstp, exp);
>
> /* Check if the request originated from a secure port. */
> - if (!rqstp->rq_secure && (flags & NFSEXP_INSECURE_PORT)) {
> + if (!rqstp->rq_secure && !(flags & NFSEXP_INSECURE_PORT)) {
> RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
> dprintk(KERN_WARNING
> "nfsd: request from insecure port %s!\n",
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

2009-12-20 15:41:10

by J.Bruce Fields

[permalink] [raw]
Subject: Re: Problem with 2.6.33-rc1 and insecure flag

On Sun, Dec 20, 2009 at 10:46:26AM +0100, Michael Guntsche wrote:
> I think I figured out the problem.
>
> Apparently the code checked if insecure was set, while it should check if it was NOT set.

Thanks! And apologies, I ran across this too a couple days ago, left it
in -next, and forgot to send it upstream.... I'll do that now.

--b.

>
> Kind regards,
> Michael
>
> diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> index 1c12177..55c8e63 100644
> --- a/fs/nfsd/nfsfh.c
> +++ b/fs/nfsd/nfsfh.c
> @@ -89,7 +89,7 @@ static __be32 nfsd_setuser_and_check_port(struct svc_rqst *rqstp,
> int flags = nfsexp_flags(rqstp, exp);
>
> /* Check if the request originated from a secure port. */
> - if (!rqstp->rq_secure && (flags & NFSEXP_INSECURE_PORT)) {
> + if (!rqstp->rq_secure && !(flags & NFSEXP_INSECURE_PORT)) {
> RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
> dprintk(KERN_WARNING
> "nfsd: request from insecure port %s!\n",
>
>
>

2009-12-20 15:46:15

by J.Bruce Fields

[permalink] [raw]
Subject: Re: Problem with 2.6.33-rc1 and insecure flag

On Sun, Dec 20, 2009 at 02:13:07AM -0800, Muntz, Daniel wrote:
> If one were to hit this bug with v4.x, would the error be something like
> this in the RPC layer:
>
> Reply State: denied (1)
> Reject State: AUTH_ERROR (1)
> Auth State: bad credential (seal broken) (1)

Since we let the "insecure" flag vary by filesystem, we don't catch this
until we decode filehandles, so return an nfs-level error.

--b.

>
> -Dan
>
> > -----Original Message-----
> > From: Michael Guntsche [mailto:mike-Z92qn3yYq0hWk0Htik3J/[email protected]]
> > Sent: Sunday, December 20, 2009 1:46 AM
> > To: [email protected]
> > Cc: linux-nfs
> > Subject: Re: Problem with 2.6.33-rc1 and insecure flag
> >
> > I think I figured out the problem.
> >
> > Apparently the code checked if insecure was set, while it
> > should check if it was NOT set.
> >
> > Kind regards,
> > Michael
> >
> > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > index 1c12177..55c8e63 100644
> > --- a/fs/nfsd/nfsfh.c
> > +++ b/fs/nfsd/nfsfh.c
> > @@ -89,7 +89,7 @@ static __be32
> > nfsd_setuser_and_check_port(struct svc_rqst *rqstp,
> > int flags = nfsexp_flags(rqstp, exp);
> >
> > /* Check if the request originated from a secure port. */
> > - if (!rqstp->rq_secure && (flags & NFSEXP_INSECURE_PORT)) {
> > + if (!rqstp->rq_secure && !(flags & NFSEXP_INSECURE_PORT)) {
> > RPC_IFDEBUG(char buf[RPC_MAX_ADDRBUFLEN]);
> > dprintk(KERN_WARNING
> > "nfsd: request from insecure port %s!\n",
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-nfs" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>