Re: Problem with 2.6.33-rc1 and insecure flag

Re: Problem with 2.6.33-rc1 and insecure flag

[Michael Guntsche]

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

Re: Problem with 2.6.33-rc1 and insecure flag

[Michael Guntsche]

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",

RE: Problem with 2.6.33-rc1 and insecure flag

[Muntz, Daniel]

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/w@public.gmane.org] 
> Sent: Sunday, December 20, 2009 1:46 AM
> To: bfields@citi.umich.edu
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Problem with 2.6.33-rc1 and insecure flag

[J. Bruce Fields]

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/w@public.gmane.org] 
> > Sent: Sunday, December 20, 2009 1:46 AM
> > To: bfields@citi.umich.edu
> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> 

Re: Problem with 2.6.33-rc1 and insecure flag

[J. Bruce Fields]

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",
> 
> 
> 

Problem with 2.6.33-rc1 and insecure flag

[Michael Guntsche]

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