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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]> 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 [email protected]
> >> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]> 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 <[email protected]> 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 [email protected]
>> >> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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.
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 <[email protected]> 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.
>
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.