Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: On Oct 9, 2008, at Oct 9, 2008, 11:48 AM, Steve Dickson wrote: Unfortunately, I'm failing miserably on reproducing this... Here is what I've done: Chuck Lever wrote: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22. I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed the nfs-utils-1.1.3 (F-10) package along with supporting packages (libgssglue, librpcsecgss and libnfsidmap). I did both mount commands mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home and was able to write to both mount points. bcwong's patch changes the server side too. Have you tried mounting a server running an old version of nfs-utils? Well it turns out bcwong's patch was rewritten by the following patch: commit 603017f2c1587d760e2649b889b581ca267ffee7 Author: J. Bruce Fields [EMAIL PROTECTED] Date: Thu Aug 28 11:23:05 2008 -0400 Determine supported pseudoflavors from export Instead of using a static list of supported flavors, we should be taking the list from the export. Signed-off-by: J. Bruce Fields [EMAIL PROTECTED] So this might be the problem... but To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). If this the case, we need a legacy mount command, then how can it be a bug in nfs-utils-1.1.3? Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by you need to force the use of the legacy mount command is that you need to force the use of the legacy binary mount interface. I have tried a legacy FC-5 mount binary (util-linux 2.13-pre7) on both a 2.6.21 kernel (FC-7) and a 2.6.25.14 kernel (F-9) mounting a F-10 server running nfs-utils-1.1.3 with out a problem. One oddity the mount binary fails when I used the '-o sec=none' flag with: Warning: Unrecognized security flavor none. Bad nfs mount parameter: sec So something else has to be going on here steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by you need to force the use of the legacy mount command is that you need to force the use of the legacy binary mount interface. I have tried a legacy FC-5 mount binary (util-linux 2.13-pre7) on both a 2.6.21 kernel (FC-7) and a 2.6.25.14 kernel (F-9) mounting a F-10 server running nfs-utils-1.1.3 with out a problem. Right, the old mount binaries don't have bcwong's fix, so they are not broken. The combination you need is an nfs-utils 1.1.3 mount command on an old kernel (or just wire the new mount command to use the legacy interface all the time). Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? One oddity the mount binary fails when I used the '-o sec=none' flag with: Warning: Unrecognized security flavor none. Try null maybe? I did... but its probably a red herring at this point... tia. steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? 'touch /mnt/home/tmp/foo rm /mnt/home/tmp/foo' works as expected... steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Oct 15, 2008, at 2:18 PM, Steve Dickson wrote: Chuck Lever wrote: Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? 'touch /mnt/home/tmp/foo rm /mnt/home/tmp/foo' works as expected... I'm out of ideas then. The problem was with the mount command in nfs-utils 1.1.3 on older kernels doing automatic security flavor negotiation incorrectly. Maybe your exports file is set up differently? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever wrote: So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? 'touch /mnt/home/tmp/foo rm /mnt/home/tmp/foo' works as expected... I'm out of ideas then. Me too... :( The problem was with the mount command in nfs-utils 1.1.3 on older kernels doing automatic security flavor negotiation incorrectly. I believe you... Its just a bit frustrating I can reproduce it Maybe your exports file is set up differently? Maybe... thanks for your help! steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Oct 15, 2008, at 12:57 PM, Steve Dickson wrote: Chuck Lever wrote: Easy... the mount.nfs subcommand in nfs-utils-1.1.3 switches to legacy mode on old kernels (pre 2.6.23). What I meant by you need to force the use of the legacy mount command is that you need to force the use of the legacy binary mount interface. I have tried a legacy FC-5 mount binary (util-linux 2.13-pre7) on both a 2.6.21 kernel (FC-7) and a 2.6.25.14 kernel (F-9) mounting a F-10 server running nfs-utils-1.1.3 with out a problem. Right, the old mount binaries don't have bcwong's fix, so they are not broken. The combination you need is an nfs-utils 1.1.3 mount command on an old kernel (or just wire the new mount command to use the legacy interface all the time). Ok... The client has the nfs-utils-1.1.3 mount.nfs binary using an FC-7 (2.6.21) kernel. New text mount interface with old binary kernel interface. I have two servers: ServerA has the nfs-utils-1.1.3 rpc.mountd binary using an F-9 2.6.26 kernel ServerB has the nfs-utils-1.1.2 rpc.mountd binary using an F-10 2.6.27 kernel. The following mount command work (meaning the mount was successful and I'm able to write the mount point): mount -o sec=sys ServerA:/home /mnt/home mount -o sec=none ServerA:/home /mnt/home mount -o sec=sys ServerB:/home /mnt/home The only mount that didn't work (meaning the actual mount failed) was: mount -o sec=none ServerB:/home /mnt/home Due to the fact the 1.1.2 server failed it with: mount.nfs: madhat.boston.devel.redhat.com:/home failed, security flavor not supported Which makes sense since this was the reason for bcwong's patch... So where have I gone wrong in reproducing this? What happens when you don't specify a sec= option at all? One oddity the mount binary fails when I used the '-o sec=none' flag with: Warning: Unrecognized security flavor none. Try null maybe? I did... but its probably a red herring at this point... tia. steved. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Thu, Oct 09, 2008 at 11:48:08AM -0400, Steve Dickson wrote: Unfortunately, I'm failing miserably on reproducing this... Here is what I've done: Chuck Lever wrote: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22. I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed the nfs-utils-1.1.3 (F-10) package along with supporting packages (libgssglue, librpcsecgss and libnfsidmap). I did both mount commands mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home and was able to write to both mount points. To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). I've built util-linux using util-linux-ng-2.14.1.tar.bz2 which was taken from util-linux-ng-2.14.1-2.fc10.src.rpm In a chroot I run './configure; make; make install' and then I used the resulting /bin/mount to mount a file system from a server running 1.1.2 (kogi) on a client running 1.1.3 (hopi) and I still have the following error: [EMAIL PROTECTED]:/mnt/kogi/anibal$ echo hola a bash: a: Permission denied If this the case, we need a legacy mount command, then how can it be a bug in nfs-utils-1.1.3? I've tried mount/umount from various packages: util-linux-ng-2.14.1-2.fc10.src.rpm util-linux_2.13.1.1-1 util-linux_2.14~rc2-0 util-linux_2.14-1ubuntu2 At this point, this issue is the only one holding up the 1.1.4 release, so I would like to address it... one way or the other... tia, steved. signature.asc Description: Digital signature
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Unfortunately, I'm failing miserably on reproducing this... Here is what I've done: Chuck Lever wrote: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22. I created a Fedora 7 KVM guest that runs a 2.6.21 kernel. I installed the nfs-utils-1.1.3 (F-10) package along with supporting packages (libgssglue, librpcsecgss and libnfsidmap). I did both mount commands mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home and was able to write to both mount points. To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). If this the case, we need a legacy mount command, then how can it be a bug in nfs-utils-1.1.3? At this point, this issue is the only one holding up the 1.1.4 release, so I would like to address it... one way or the other... tia, steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Chuck Lever skrev: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22 (ie the problem is with the legacy mount command, not with the in-kernel mount parser, which has a different, less harmful bug that masks these symptoms). To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). Is that why turning on NFS mount debugging on does not provide any debug messages? I believe that the Debian nfs-utils forces use of the legacy mount command. mount -o sec=sys gere:/home /home-- this results in sec=sys in /proc/mounts mount -o sec=none gere:/home /home-- this results in sec=null in /proc/mounts mount gere:/home /home-- this results in sec=null in /proc/mounts Regards /Rasmus On Oct 2, 2008, at Oct 2, 2008, 9:27 AM, Steve Dickson wrote: What is logged in /var/log/messages you turn on the in-kernel mount debugging via: rpcdebug -m nfs -s mount then do the following three mounts: mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home mount madhat:/home /mnt/home I got: Oct 2 09:23:10 rawhat kernel: NFS: nfs mount opts='sec=none,addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'sec=none' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:10 rawhat kernel: NFS: MNT request succeeded Oct 2 09:23:43 rawhat kernel: NFS: nfs mount opts='sec=sys,addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'sec=sys' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:43 rawhat kernel: NFS: MNT request succeeded Oct 2 09:24:00 rawhat kernel: NFS: nfs mount opts='addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- Rasmus Bøg Hansen MSC Aps Bøgesvinget 8 2740 Skovlunde 44 53 93 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Oct 6, 2008, at 5:12 AM, Rasmus Bøg Hansen wrote: Chuck Lever skrev: Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22 (ie the problem is with the legacy mount command, not with the in-kernel mount parser, which has a different, less harmful bug that masks these symptoms). To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). Is that why turning on NFS mount debugging on does not provide any debug messages? Yes. I believe that the Debian nfs-utils forces use of the legacy mount command. That's why Debian hits this, and other testers missed it before 1.1.3 was released. I think Debian forces legacy mode because they hit some other bugs with text-based mounts. These should be mostly addressed with 2.6.27. mount -o sec=sys gere:/home /home-- this results in sec=sys in /proc/mounts mount -o sec=none gere:/home /home-- this results in sec=null in /proc/mounts mount gere:/home /home-- this results in sec=null in /proc/mounts Regards /Rasmus On Oct 2, 2008, at Oct 2, 2008, 9:27 AM, Steve Dickson wrote: What is logged in /var/log/messages you turn on the in-kernel mount debugging via: rpcdebug -m nfs -s mount then do the following three mounts: mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home mount madhat:/home /mnt/home I got: Oct 2 09:23:10 rawhat kernel: NFS: nfs mount opts='sec=none,addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'sec=none' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:10 rawhat kernel: NFS: MNT request succeeded Oct 2 09:23:43 rawhat kernel: NFS: nfs mount opts='sec=sys,addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'sec=sys' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:43 rawhat kernel: NFS: MNT request succeeded Oct 2 09:24:00 rawhat kernel: NFS: nfs mount opts='addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- Rasmus Bøg Hansen MSC Aps Bøgesvinget 8 2740 Skovlunde 44 53 93 66 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Thu, Oct 02, 2008 at 09:19:58AM -0400, Steve Dickson wrote: Aníbal Monsalve Salazar wrote: In my case I run Debian stable (nfs-utils 1.0.10) on the server and Debian unstable (1.1.3) on the client. I have not tried upgrading the server (which is probably not an option until Debian Lenny is released), but running the client with sec=sys solves the problem for me like here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970#40 This appears to be a debian only issues since with fedora I *always* get 'sec=sys' in /proc/mounts even when I specify -o sec=none which does not seem right I'm investigating that right now... I tried a couple of times without no patches and the bug was there. Are there any other debian only patches out there that might be causing havoc?? I tried debian packages created with no patches, just the nsf-utils original 1.1.3 tarball. steved signature.asc Description: Digital signature
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Fri, Aug 08, 2008 at 09:06:46PM -0400, Chuck Lever wrote: Confirmed. The kernel's mountd client doesn't even bother to unmarshal the auth flavor list in the server's reply. I'll work on a fix. Chuck Lever was able to confirm this bug. On Thu, Oct 02, 2008 at 01:30:54PM +0200, Rasmus Bøg Hansen wrote: Hi Steve and Aníbal Steve Dickson [EMAIL PROTECTED] writes: Rasmus Bøg Hansen wrote: Steve Dickson [EMAIL PROTECTED] writes: Hey... In the following problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970 What were the kernel versions on both the client and server? I would like to knock this out before cutting another release of nfs-utils... Phew, package manager logs fortunately tell me 'cause I didn't remember. Client: 2.6.26.3 Server: 2.6.26 Those were both home-compiled, non-patched kernels from kernel.org, not Debian kernels. Hope this helps - I will gladly send you more information if you might need anything. Ok... I am not able to reproduce this problem with the following setup: both server and client: 2.6.25-1.fc9.x86_64 and nfs-utils-1.1.3-5.fc10.x86_64 mount server:/home /mnt/home (as steved) cd /mnt/home/steved touch foo with no problem... what am I doing differently that you guys? In my case I run Debian stable (nfs-utils 1.0.10) on the server and Debian unstable (1.1.3) on the client. I have not tried upgrading the server (which is probably not an option until Debian Lenny is released), but running the client with sec=sys solves the problem for me like here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970#40 There is talk about a debian specific patch that might be the culprit here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970#90 When I read that message, I tried without that patch and had the same problem. I even tried without all debian patches and the bug was there. I just tried again with the same result. The mentioned patch: Index: nfs-utils-1.1.2/utils/mount/mount.c === --- nfs-utils-1.1.2.orig/utils/mount/mount.c2008-07-11 18:56:00.0 +0200 +++ nfs-utils-1.1.2/utils/mount/mount.c 2008-07-11 18:56:06.0 +0200 @@ -189,9 +189,6 @@ } if (nfs_mount_data_version NFS_MOUNT_VERSION) nfs_mount_data_version = NFS_MOUNT_VERSION; - else - if (kernel_version MAKE_VERSION(2, 6, 22)) - string++; } static void print_one(char *spec, char *node, char *type, char *opts) Regards /Rasmus -- Rasmus Bøg Hansen MSC Aps Bøgesvinget 8 2740 Skovlunde 44 53 93 66 signature.asc Description: Digital signature
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Aníbal Monsalve Salazar wrote: In my case I run Debian stable (nfs-utils 1.0.10) on the server and Debian unstable (1.1.3) on the client. I have not tried upgrading the server (which is probably not an option until Debian Lenny is released), but running the client with sec=sys solves the problem for me like here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970#40 This appears to be a debian only issues since with fedora I *always* get 'sec=sys' in /proc/mounts even when I specify -o sec=none which does not seem right I'm investigating that right now... Are there any other debian only patches out there that might be causing havoc?? steved -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
What is logged in /var/log/messages you turn on the in-kernel mount debugging via: rpcdebug -m nfs -s mount then do the following three mounts: mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home mount madhat:/home /mnt/home I got: Oct 2 09:23:10 rawhat kernel: NFS: nfs mount opts='sec=none,addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'sec=none' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:10 rawhat kernel: NFS: MNT request succeeded Oct 2 09:23:43 rawhat kernel: NFS: nfs mount opts='sec=sys,addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'sec=sys' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:23:43 rawhat kernel: NFS: MNT request succeeded Oct 2 09:24:00 rawhat kernel: NFS: nfs mount opts='addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
Hi Steve- As I understand it, the documented bug refers to running nfs-utils 1.1.3 on kernels older than 2.6.22 (ie the problem is with the legacy mount command, not with the in-kernel mount parser, which has a different, less harmful bug that masks these symptoms). To reproduce this you need to force the use of the legacy mount command that parses mount options in user space and passes a binary data structure to the kernel via mount(2). On Oct 2, 2008, at Oct 2, 2008, 9:27 AM, Steve Dickson wrote: What is logged in /var/log/messages you turn on the in-kernel mount debugging via: rpcdebug -m nfs -s mount then do the following three mounts: mount -o sec=none madhat:/home /mnt/home mount -o sec=sys madhat:/home /mnt/home mount madhat:/home /mnt/home I got: Oct 2 09:23:10 rawhat kernel: NFS: nfs mount opts='sec=none,addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'sec=none' Oct 2 09:23:10 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:10 rawhat kernel: NFS: sending MNT request for madhat:/ home Oct 2 09:23:10 rawhat kernel: NFS: MNT request succeeded Oct 2 09:23:43 rawhat kernel: NFS: nfs mount opts='sec=sys,addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'sec=sys' Oct 2 09:23:43 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:23:43 rawhat kernel: NFS: sending MNT request for madhat:/ home Oct 2 09:23:43 rawhat kernel: NFS: MNT request succeeded Oct 2 09:24:00 rawhat kernel: NFS: nfs mount opts='addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: parsing nfs mount option 'addr=10.16.60.33' Oct 2 09:24:00 rawhat kernel: NFS: sending MNT request for madhat:/ home Oct 2 09:24:00 rawhat kernel: NFS: MNT request succeeded steved. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492970: #492970 - nfs-common 1:1.1.3-1 client disallows access to files/directories where it should allow access - Debian Bug report logs
On Tue, Sep 30, 2008 at 11:42:28AM -0400, Steve Dickson wrote: Hey... In the following problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970 What were the kernel versions on both the client and server? I would like to knock this out before cutting another release of nfs-utils... I have the following versions. server: nfs-utils 1.1.2 uname -a Linux kogi 2.6.22-2-amd64 #1 SMP Thu Aug 30 23:43:59 UTC 2007 x86_64 GNU/Linux clients: nfs-utils 1.1.3 uname -a Linux elida 2.6.24-1-686 #1 SMP Thu May 8 02:16:39 UTC 2008 i686 GNU/Linux uname -a Linux hopi 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux steved. Thank you. signature.asc Description: Digital signature
