Bug in NFSV3 ACCESS Procedure reply

Bug in NFSV3 ACCESS Procedure reply

[Dilip Kumar]

Hi all,

I noticed a bug in the access rights of a NFSV3 ACCESS Reply. If a
directory was created with only write permissions for the owner (chmod
200 directory), we expect the modify, extend and delete bits (access =
0x1C) to be set for this directory in the reply to an ACCESS RPC call
with access = 0x1F send by the owner. Instead the NFS server on Linux
returns an ACCESS Reply with access set to 0x0 (none of the bits were
set). I tried checking this against Solaris server and it returns the
expected access rights 0x1C. The Linux server I was using for testing
was 2.6.9-1.667smp and the Solaris server was SunOS 5.8
Generic_108528-22 Ultra Sparc-IIi.

Please let me know if you need further details regarding this issue.

Thanks
Dilip Kumar

Re: Bug in NFSV3 ACCESS Procedure reply

[J. Bruce Fields]

On Wed, Aug 27, 2008 at 12:41:34PM -0700, Dilip Kumar wrote:
> Hi all,
> 
> I noticed a bug in the access rights of a NFSV3 ACCESS Reply. If a
> directory was created with only write permissions for the owner (chmod
> 200 directory), we expect the modify, extend and delete bits (access =
> 0x1C) to be set for this directory in the reply to an ACCESS RPC call
> with access = 0x1F send by the owner. Instead the NFS server on Linux
> returns an ACCESS Reply with access set to 0x0 (none of the bits were
> set). I tried checking this against Solaris server and it returns the
> expected access rights 0x1C. The Linux server I was using for testing
> was 2.6.9-1.667smp and the Solaris server was SunOS 5.8
> Generic_108528-22 Ultra Sparc-IIi.

What user are you performing the access call as, and who owns the
directory?  What does exportfs -v say?   (Do you have root_squash or
no_root_squash set?)

--b.

> 
> Please let me know if you need further details regarding this issue.
> 
> Thanks
> Dilip Kumar
> --
> 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: Bug in NFSV3 ACCESS Procedure reply

[Dilip Kumar]

The directory was created by a local user (not root) with access mode
200 (Write only for owner). When I perform the ACCESS call as a owner
(who created that directory), I see that the ACCESS reply has access
set to 0x0. My /etc/exports just has just this one line :"/nfsshare
*(rw,sync)"

Thanks
Dilip Kumar

On Thu, Aug 28, 2008 at 10:34 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Wed, Aug 27, 2008 at 12:41:34PM -0700, Dilip Kumar wrote:
>> Hi all,
>>
>> I noticed a bug in the access rights of a NFSV3 ACCESS Reply. If a
>> directory was created with only write permissions for the owner (chmod
>> 200 directory), we expect the modify, extend and delete bits (access =
>> 0x1C) to be set for this directory in the reply to an ACCESS RPC call
>> with access = 0x1F send by the owner. Instead the NFS server on Linux
>> returns an ACCESS Reply with access set to 0x0 (none of the bits were
>> set). I tried checking this against Solaris server and it returns the
>> expected access rights 0x1C. The Linux server I was using for testing
>> was 2.6.9-1.667smp and the Solaris server was SunOS 5.8
>> Generic_108528-22 Ultra Sparc-IIi.
>
> What user are you performing the access call as, and who owns the
> directory?  What does exportfs -v say?   (Do you have root_squash or
> no_root_squash set?)
>
> --b.
>
>>
>> Please let me know if you need further details regarding this issue.
>>
>> Thanks
>> Dilip Kumar
>> --
>> 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: Bug in NFSV3 ACCESS Procedure reply

[J. Bruce Fields]

On Thu, Aug 28, 2008 at 10:41:24AM -0700, Dilip Kumar wrote:
> The directory was created by a local user (not root) with access mode
> 200 (Write only for owner). When I perform the ACCESS call as a owner
> (who created that directory), I see that the ACCESS reply has access
> set to 0x0. My /etc/exports just has just this one line :"/nfsshare
> *(rw,sync)"

OK, hm, confirmed here on 2.6.27-rc4 (+ some local patches).  Not sure
yet why it's doing that, though.

--b.

> 
> Thanks
> Dilip Kumar
> 
> On Thu, Aug 28, 2008 at 10:34 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, Aug 27, 2008 at 12:41:34PM -0700, Dilip Kumar wrote:
> >> Hi all,
> >>
> >> I noticed a bug in the access rights of a NFSV3 ACCESS Reply. If a
> >> directory was created with only write permissions for the owner (chmod
> >> 200 directory), we expect the modify, extend and delete bits (access =
> >> 0x1C) to be set for this directory in the reply to an ACCESS RPC call
> >> with access = 0x1F send by the owner. Instead the NFS server on Linux
> >> returns an ACCESS Reply with access set to 0x0 (none of the bits were
> >> set). I tried checking this against Solaris server and it returns the
> >> expected access rights 0x1C. The Linux server I was using for testing
> >> was 2.6.9-1.667smp and the Solaris server was SunOS 5.8
> >> Generic_108528-22 Ultra Sparc-IIi.
> >
> > What user are you performing the access call as, and who owns the
> > directory?  What does exportfs -v say?   (Do you have root_squash or
> > no_root_squash set?)
> >
> > --b.
> >
> >>
> >> Please let me know if you need further details regarding this issue.
> >>
> >> Thanks
> >> Dilip Kumar
> >> --
> >> 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
> >
> --
> 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: Bug in NFSV3 ACCESS Procedure reply

[Dilip Kumar]

Do you see this issue on your version too? Not sure if there is a
patch already addressing this issue.

Thanks
Dilip Kumar

On Thu, Aug 28, 2008 at 10:49 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Thu, Aug 28, 2008 at 10:41:24AM -0700, Dilip Kumar wrote:
>> The directory was created by a local user (not root) with access mode
>> 200 (Write only for owner). When I perform the ACCESS call as a owner
>> (who created that directory), I see that the ACCESS reply has access
>> set to 0x0. My /etc/exports just has just this one line :"/nfsshare
>> *(rw,sync)"
>
> OK, hm, confirmed here on 2.6.27-rc4 (+ some local patches).  Not sure
> yet why it's doing that, though.
>
> --b.
>
>>
>> Thanks
>> Dilip Kumar
>>
>> On Thu, Aug 28, 2008 at 10:34 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
>> > On Wed, Aug 27, 2008 at 12:41:34PM -0700, Dilip Kumar wrote:
>> >> Hi all,
>> >>
>> >> I noticed a bug in the access rights of a NFSV3 ACCESS Reply. If a
>> >> directory was created with only write permissions for the owner (chmod
>> >> 200 directory), we expect the modify, extend and delete bits (access =
>> >> 0x1C) to be set for this directory in the reply to an ACCESS RPC call
>> >> with access = 0x1F send by the owner. Instead the NFS server on Linux
>> >> returns an ACCESS Reply with access set to 0x0 (none of the bits were
>> >> set). I tried checking this against Solaris server and it returns the
>> >> expected access rights 0x1C. The Linux server I was using for testing
>> >> was 2.6.9-1.667smp and the Solaris server was SunOS 5.8
>> >> Generic_108528-22 Ultra Sparc-IIi.
>> >
>> > What user are you performing the access call as, and who owns the
>> > directory?  What does exportfs -v say?   (Do you have root_squash or
>> > no_root_squash set?)
>> >
>> > --b.
>> >
>> >>
>> >> Please let me know if you need further details regarding this issue.
>> >>
>> >> Thanks
>> >> Dilip Kumar
>> >> --
>> >> 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
>> >
>> --
>> 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: Bug in NFSV3 ACCESS Procedure reply

[J. Bruce Fields]

On Thu, Aug 28, 2008 at 10:52:07AM -0700, Dilip Kumar wrote:
> Do you see this issue on your version too? Not sure if there is a
> patch already addressing this issue.

Hm.  It looks like it may just be this:

static struct accessmap nfs3_diraccess[] = {
    {   NFS3_ACCESS_READ,       MAY_READ                        },
    {   NFS3_ACCESS_LOOKUP,     MAY_EXEC                        },
    {   NFS3_ACCESS_MODIFY,     MAY_EXEC|MAY_WRITE|MAY_TRUNC    },
    {   NFS3_ACCESS_EXTEND,     MAY_EXEC|MAY_WRITE              },
    {   NFS3_ACCESS_DELETE,     MAY_REMOVE                      },

    {   0,                      0                               }
};

So it doesn't claim write is allowed unless exec is also allowed.

I think that's actually how the local filesystem behaves--is there
any operation you can do locally with only write permissions?

Why is this behavior a problem for you, anyway?

--b.

Re: Bug in NFSV3 ACCESS Procedure reply

[Dilip Kumar]

I was writing some scripts to map the Unix access modes to the access
flags in the NFS ACCESS Reply. I have run these scripts on Linux and
Solaris machines and the results were not the same. If I have some C
program which opens this directory in a write mode exported by an NFS
server it succeeds, if the server is Solaris, but fails if the server
is Linux. If I have write access on the directory, I would expect to
see write bit set for that directory in the ACCESS reply. Programs
like mkdir or cd require execute and write access to complete their
operations, but a normal open with write mode should succeed in either
case. I was more concerned about the differences in the implementation
of ACCESS in two different servers.

Thanks
Dilip Kumar

On Thu, Aug 28, 2008 at 11:54 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Thu, Aug 28, 2008 at 10:52:07AM -0700, Dilip Kumar wrote:
>> Do you see this issue on your version too? Not sure if there is a
>> patch already addressing this issue.
>
> Hm.  It looks like it may just be this:
>
> static struct accessmap nfs3_diraccess[] = {
>    {   NFS3_ACCESS_READ,       MAY_READ                        },
>    {   NFS3_ACCESS_LOOKUP,     MAY_EXEC                        },
>    {   NFS3_ACCESS_MODIFY,     MAY_EXEC|MAY_WRITE|MAY_TRUNC    },
>    {   NFS3_ACCESS_EXTEND,     MAY_EXEC|MAY_WRITE              },
>    {   NFS3_ACCESS_DELETE,     MAY_REMOVE                      },
>
>    {   0,                      0                               }
> };
>
> So it doesn't claim write is allowed unless exec is also allowed.
>
> I think that's actually how the local filesystem behaves--is there
> any operation you can do locally with only write permissions?
>
> Why is this behavior a problem for you, anyway?
>
> --b.
>

Re: Bug in NFSV3 ACCESS Procedure reply

[J. Bruce Fields]

On Thu, Aug 28, 2008 at 02:22:35PM -0700, Dilip Kumar wrote:
> I was writing some scripts to map the Unix access modes to the access
> flags in the NFS ACCESS Reply. I have run these scripts on Linux and
> Solaris machines and the results were not the same. If I have some C
> program which opens this directory in a write mode exported by an NFS
> server it succeeds, if the server is Solaris, but fails if the server
> is Linux. If I have write access on the directory, I would expect to
> see write bit set for that directory in the ACCESS reply. Programs
> like mkdir or cd require execute and write access to complete their
> operations, but a normal open with write mode should succeed in either
> case. I was more concerned about the differences in the implementation
> of ACCESS in two different servers.

Behavior that's different from Solaris probably merits investigation,
but on its own that's not justification for making a change.

It sounds like this isn't a real problem for you, just a result you
observed in some tests, so for now I'm not inclined to worry about it
very much.  If you want to pursue it, you're welcome to make a patch
(it's probably just a matter of adjusting those accessmap arrays in
fs/nfsd/vfs.c), and you may well be correct to do so, but the patch will
need to come with a more persuasive argument.

--b.