more NFS questions, why is the VFS_FHTOVP weird?
If you look in src/nfs/nfs_serv.c in almost every call you'll see this: nfsm_srvmtofh(fhp); nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); error = nfsrv_fhtovp(fhp, 1, &vp, cred, slp, nam, &rdonly, (nfsd->nd_flag & ND_KERBAUTH), TRUE); if (error) { nfsm_reply(NFSX_UNSIGNED); nfsm_srvpostop_attr(1, (struct vattr *)0); error = 0; goto nfsmout; } my interest is the third function called (nfsrv_fhtovp) it is in "nfs_subs.c" around line 1953 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) 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 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) btw, since this seems to work... is it ok to pass in a NULL sockaddr *? (nam) thanks for all the help, -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
more NFS questions, why is the VFS_FHTOVP weird?
If you look in src/nfs/nfs_serv.c in almost every call you'll see this: nfsm_srvmtofh(fhp); nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); error = nfsrv_fhtovp(fhp, 1, &vp, cred, slp, nam, &rdonly, (nfsd->nd_flag & ND_KERBAUTH), TRUE); if (error) { nfsm_reply(NFSX_UNSIGNED); nfsm_srvpostop_attr(1, (struct vattr *)0); error = 0; goto nfsmout; } my interest is the third function called (nfsrv_fhtovp) it is in "nfs_subs.c" around line 1953 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) 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 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) btw, since this seems to work... is it ok to pass in a NULL sockaddr *? (nam) thanks for all the help, -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more NFS questions, why is the VFS_FHTOVP weird?
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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: more NFS questions, why is the VFS_FHTOVP weird?
On 3 Aug 1999, Assar Westerlund wrote: > Alfred Perlstein writes: > > > > * 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. ah thank you it makes more sense now, i'm working on patches to make this more like netbsd's way. > > 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. I just booted my NetBSD box and saw the implemented functions. :) > > 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? no it's not what I want to do, thank you for the help. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: more NFS questions, why is the VFS_FHTOVP weird?
Alfred Perlstein <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more NFS questions, why is the VFS_FHTOVP weird?
On 3 Aug 1999, Assar Westerlund wrote: > Alfred Perlstein <[EMAIL PROTECTED]> writes: > > > > * 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. ah thank you it makes more sense now, i'm working on patches to make this more like netbsd's way. > > 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. I just booted my NetBSD box and saw the implemented functions. :) > > 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? no it's not what I want to do, thank you for the help. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Wintelcom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message