From owner-freebsd-hackers Tue Aug 3 5:14:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by hub.freebsd.org (Postfix) with ESMTP id 8E34214E53 for ; Tue, 3 Aug 1999 05:14:21 -0700 (PDT) (envelope-from assar@sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id OAA55819; Tue, 3 Aug 1999 14:14:52 +0200 (CEST) To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: more NFS questions, why is the VFS_FHTOVP weird? References: Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 03 Aug 1999 14:14:50 +0200 In-Reply-To: Alfred Perlstein's message of "Tue, 3 Aug 1999 06:15:55 -0400 (EDT)" Message-ID: <5lwvvdysat.fsf@assaris.sics.se> Lines: 80 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: > the problem with nfsrv_fhtovp is that it is overkill for my application > (it checks perms where i don't need it to, so i would have to fake > a lot of stuff to look like i was authorized) What's your application? > so instead I gutted nfsrv_fhtovp a bit and came up with this sequence: > > fhp = &nfh.fh_generic; > error = copyin(u_fhp, fhp, fhlen); > if (error) > return(error); > > /* find the mount point */ > mp = vfs_getvfs(&fhp->fh_fsid); > if (!mp) > return (ESTALE); > > /* now give me my vnode, it gets returned to me locked */ > error = VFS_FHTOVP(mp, &fhp->fh_fid, nam, &vp, &exflags, &credanon); > if (error) > return (error); > > the copying is from userspace, it's a NFS handle... > > now here's where I get very confused... > > in src/nfs/nfs_vfsops.c around line 1100: > > /* > * At this point, this should never happen > */ > /* ARGSUSED */ > static int > nfs_fhtovp(mp, fhp, nam, vpp, exflagsp, credanonp) > register struct mount *mp; > struct fid *fhp; > struct sockaddr *nam; > struct vnode **vpp; > int *exflagsp; > struct ucred **credanonp; > { > > return (EINVAL); > } > > ok, now if you look at the first piece of code it obviously > fails if nfsrv_fhtovp fails, and nfsrv_fhtovp fails if VFS_FHTOVP > fails... > > so how does NFS work? where is this magic function? The NFS server is calling the FHTOVP function of the exported file system. You're looking at the FHTOVP function for the NFS file system itself. Look for example at ffs_fhtovp and ufs_check_export. > the macro VFS_FHTOVP is defined in mount.h: > > #define VFS_FHTOVP(MP, FIDP, NAM, VPP, EXFLG, CRED) \ > (*(MP)->mnt_op->vfs_fhtovp)(MP, FIDP, NAM, VPP, EXFLG, CRED) I do think that checking for what file systems are exported has no place in FHTOVP and this should probably be rewritten similar to the way it has recently been done in NetBSD, namely with a new vfs operation: int (*vfs_checkexp) __P((struct mount *mp, struct mbuf *nam, int *extflagsp, struct ucred **credanonp)); And they have also added fhopen and other syscalls that take file handles instead of file names. > btw, since this seems to work... is it ok to pass in a NULL > sockaddr *? (nam) I think that nam == NULL means the default export list which doesn't sound as what you want do do? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message