acl_extended_file() and NFS file systems

We've just come across a problem with running 'ls -l' on NFS mounted files from a client running Fedora Core 1 with the latest coreutils RPM (5.0-34.1)

Running ls -l on a file exported by a RedHat 7.2 system gives

% ls -l /some/remote/file
ls: /some/remote/file: Input/output error -rw-rw-r-- 1 james user 17373 Jun 1 20:02 /some/remote/file

/var/log/messages on the client gives:

Jun 23 16:00:53 wingnut kernel: call_verify: server accept status: 1
Jun 23 16:00:53 wingnut last message repeated 2 times
Jun 23 16:00:53 wingnut kernel: RPC: garbage, exit EIO

I've tracked this down to the use of acl_extended_file() by this version of ls - it works OK on local file systems and NFS file systems exported by other FC1 machines and Solaris boxes, but gives this error on file systems exported by RedHat 7.2 and Irix boxes.

I can reproduce the errors with a simple bit of 'C':

#include <sys/types.h>
#include <acl/libacl.h>
#include <errno.h>

main(int argc, char **argv)

{
        int ret;

        errno = 0;
        ret = acl_extended_file (argv[1]);
        printf("ret = %d\nerrno = %d\n", ret, errno);
        exit (0);
}

(need to link with -lacl)

I've searched around and come across references to a 'noacl' option to mount that might help, but mount on Fedora doesn't seem to support this - I get:

unknown nfs mount option: noacl

I don't really know if this a real problem (I can easily fix 'ls' by backing out the patch to coreutils that introduces this issue), but I would like to understand more on what is going on ...

Thanks

James Pearson

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

hmm... it sound like 7.2 is returning garbage but to which over-the-wire operation? Since FC1 does not have ACL support so the getxattr() (that is done by your test program) should be returned EOPNOTSUPP (as it does in my testing) but instead it sounds like the FC1 is actually trying to send something otw.. Would it be possible to get a strace and ethereal trace of this phenomenon?

SteveD.

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

I've put the strace and ethereal outputs at:

ftp://ftp.moving-picture.com/private/nfs/

The files 'works' from using a file on a FC1 server

The files 'fails' from using a file on a RH7.2 server

Note: it also fails on NFS files from an Irix 6.5.X server

James Pearson

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

Ok... see if the attached patch takes care of the problem...

SteveD.

@@ -923,6 +923,16 @@ call_verify(struct rpc_task *task)
 		return p;
 	case RPC_GARBAGE_ARGS:
 		break;			/* retry */
+	case RPC_PROG_UNAVAIL:
+		/* report requested program number*/
+		dprintk(KERN_WARNING "RPC: unknown program\n");
+		rpc_exit(task, -ENOSYS);
+		return NULL;
+	case RPC_PROC_UNAVAIL:
+		/* report requested program and procedure number, version */
+		dprintk(KERN_WARNING "RPC: unknown procedure\n");
+		rpc_exit(task, -ENOSYS);
+		return NULL;
 	default:
 		printk(KERN_WARNING "call_verify: server accept status: %x\n", n);
 		/* Also retry */

I think I've worked out what is going on ... when I said the client was a FC1 box, I didn't give all the facts - it's using a kernel based on the FC1 kernel - actually one from ATrpms (http://atrpms.net/).

It turns out that this kernel has a 'nfsacl' patch (from http://acl.bestbits.at/download.html) applied that adds CONFIG_NFS_ACL (and CONFIG_NFSD_ACL) which are enabled by default -
compiling a new kernel with the CONFIG_NFS_ACL option disabled (i.e.
something closer to a vanilla FC1 kernel), then the problem goes away ...

James Pearson

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs