2008-03-26 15:23:12 +00:00
|
|
|
/* $NetBSD: svc_vc.c,v 1.7 2000/08/03 00:01:53 fvdl Exp $ */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sun RPC is a product of Sun Microsystems, Inc. and is provided for
|
|
|
|
* unrestricted use provided that this legend is included on all tape
|
|
|
|
* media and as a part of the software program in whole or part. Users
|
|
|
|
* may copy or modify Sun RPC without charge, but are not authorized
|
|
|
|
* to license or distribute it to anyone else except as part of a product or
|
|
|
|
* program developed by the user.
|
|
|
|
*
|
|
|
|
* SUN RPC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
|
|
|
|
* WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE.
|
|
|
|
*
|
|
|
|
* Sun RPC is provided with no support and without any obligation on the
|
|
|
|
* part of Sun Microsystems, Inc. to assist in its use, correction,
|
|
|
|
* modification or enhancement.
|
|
|
|
*
|
|
|
|
* SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
|
|
|
|
* INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY SUN RPC
|
|
|
|
* OR ANY PART THEREOF.
|
|
|
|
*
|
|
|
|
* In no event will Sun Microsystems, Inc. be liable for any lost revenue
|
|
|
|
* or profits or other special, indirect and consequential damages, even if
|
|
|
|
* Sun has been advised of the possibility of such damages.
|
|
|
|
*
|
|
|
|
* Sun Microsystems, Inc.
|
|
|
|
* 2550 Garcia Avenue
|
|
|
|
* Mountain View, California 94043
|
|
|
|
*/
|
|
|
|
|
|
|
|
#if defined(LIBC_SCCS) && !defined(lint)
|
|
|
|
static char *sccsid2 = "@(#)svc_tcp.c 1.21 87/08/11 Copyr 1984 Sun Micro";
|
|
|
|
static char *sccsid = "@(#)svc_tcp.c 2.2 88/08/01 4.0 RPCSRC";
|
|
|
|
#endif
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* svc_vc.c, Server side for Connection Oriented based RPC.
|
|
|
|
*
|
|
|
|
* Actually implements two flavors of transporter -
|
|
|
|
* a tcp rendezvouser (a listner and connection establisher)
|
|
|
|
* and a record/tcp stream.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/lock.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/malloc.h>
|
|
|
|
#include <sys/mbuf.h>
|
|
|
|
#include <sys/mutex.h>
|
2009-06-05 14:29:49 +00:00
|
|
|
#include <sys/proc.h>
|
2008-03-26 15:23:12 +00:00
|
|
|
#include <sys/protosw.h>
|
|
|
|
#include <sys/queue.h>
|
|
|
|
#include <sys/socket.h>
|
|
|
|
#include <sys/socketvar.h>
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
#include <sys/sx.h>
|
2008-03-26 15:23:12 +00:00
|
|
|
#include <sys/systm.h>
|
|
|
|
#include <sys/uio.h>
|
2009-08-24 10:09:30 +00:00
|
|
|
|
|
|
|
#include <net/vnet.h>
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
#include <netinet/tcp.h>
|
|
|
|
|
|
|
|
#include <rpc/rpc.h>
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
#include <rpc/krpc.h>
|
2008-03-28 09:50:32 +00:00
|
|
|
#include <rpc/rpc_com.h>
|
2008-03-26 15:23:12 +00:00
|
|
|
|
2009-06-05 14:29:49 +00:00
|
|
|
#include <security/mac/mac_framework.h>
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
static bool_t svc_vc_rendezvous_recv(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr **, struct mbuf **);
|
2008-03-26 15:23:12 +00:00
|
|
|
static enum xprt_stat svc_vc_rendezvous_stat(SVCXPRT *);
|
|
|
|
static void svc_vc_rendezvous_destroy(SVCXPRT *);
|
|
|
|
static bool_t svc_vc_null(void);
|
|
|
|
static void svc_vc_destroy(SVCXPRT *);
|
|
|
|
static enum xprt_stat svc_vc_stat(SVCXPRT *);
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
static bool_t svc_vc_recv(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr **, struct mbuf **);
|
|
|
|
static bool_t svc_vc_reply(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr *, struct mbuf *);
|
2008-03-26 15:23:12 +00:00
|
|
|
static bool_t svc_vc_control(SVCXPRT *xprt, const u_int rq, void *in);
|
|
|
|
static bool_t svc_vc_rendezvous_control (SVCXPRT *xprt, const u_int rq,
|
|
|
|
void *in);
|
2012-12-08 00:29:16 +00:00
|
|
|
static void svc_vc_backchannel_destroy(SVCXPRT *);
|
|
|
|
static enum xprt_stat svc_vc_backchannel_stat(SVCXPRT *);
|
|
|
|
static bool_t svc_vc_backchannel_recv(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr **, struct mbuf **);
|
|
|
|
static bool_t svc_vc_backchannel_reply(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr *, struct mbuf *);
|
|
|
|
static bool_t svc_vc_backchannel_control(SVCXPRT *xprt, const u_int rq,
|
|
|
|
void *in);
|
2008-03-26 15:23:12 +00:00
|
|
|
static SVCXPRT *svc_vc_create_conn(SVCPOOL *pool, struct socket *so,
|
|
|
|
struct sockaddr *raddr);
|
|
|
|
static int svc_vc_accept(struct socket *head, struct socket **sop);
|
2009-06-01 21:17:03 +00:00
|
|
|
static int svc_vc_soupcall(struct socket *so, void *arg, int waitflag);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
static struct xp_ops svc_vc_rendezvous_ops = {
|
|
|
|
.xp_recv = svc_vc_rendezvous_recv,
|
|
|
|
.xp_stat = svc_vc_rendezvous_stat,
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
.xp_reply = (bool_t (*)(SVCXPRT *, struct rpc_msg *,
|
|
|
|
struct sockaddr *, struct mbuf *))svc_vc_null,
|
2008-03-26 15:23:12 +00:00
|
|
|
.xp_destroy = svc_vc_rendezvous_destroy,
|
|
|
|
.xp_control = svc_vc_rendezvous_control
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct xp_ops svc_vc_ops = {
|
|
|
|
.xp_recv = svc_vc_recv,
|
|
|
|
.xp_stat = svc_vc_stat,
|
|
|
|
.xp_reply = svc_vc_reply,
|
|
|
|
.xp_destroy = svc_vc_destroy,
|
|
|
|
.xp_control = svc_vc_control
|
|
|
|
};
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static struct xp_ops svc_vc_backchannel_ops = {
|
|
|
|
.xp_recv = svc_vc_backchannel_recv,
|
|
|
|
.xp_stat = svc_vc_backchannel_stat,
|
|
|
|
.xp_reply = svc_vc_backchannel_reply,
|
|
|
|
.xp_destroy = svc_vc_backchannel_destroy,
|
|
|
|
.xp_control = svc_vc_backchannel_control
|
2008-03-26 15:23:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Usage:
|
|
|
|
* xprt = svc_vc_create(sock, send_buf_size, recv_buf_size);
|
|
|
|
*
|
|
|
|
* Creates, registers, and returns a (rpc) tcp based transporter.
|
|
|
|
* Once *xprt is initialized, it is registered as a transporter
|
|
|
|
* see (svc.h, xprt_register). This routine returns
|
|
|
|
* a NULL if a problem occurred.
|
|
|
|
*
|
|
|
|
* The filedescriptor passed in is expected to refer to a bound, but
|
|
|
|
* not yet connected socket.
|
|
|
|
*
|
|
|
|
* Since streams do buffered io similar to stdio, the caller can specify
|
|
|
|
* how big the send and receive buffers are via the second and third parms;
|
|
|
|
* 0 => use the system default.
|
|
|
|
*/
|
|
|
|
SVCXPRT *
|
|
|
|
svc_vc_create(SVCPOOL *pool, struct socket *so, size_t sendsize,
|
|
|
|
size_t recvsize)
|
|
|
|
{
|
|
|
|
SVCXPRT *xprt;
|
|
|
|
struct sockaddr* sa;
|
|
|
|
int error;
|
|
|
|
|
2008-06-26 10:21:54 +00:00
|
|
|
if (so->so_state & SS_ISCONNECTED) {
|
|
|
|
error = so->so_proto->pr_usrreqs->pru_peeraddr(so, &sa);
|
|
|
|
if (error)
|
|
|
|
return (NULL);
|
|
|
|
xprt = svc_vc_create_conn(pool, so, sa);
|
|
|
|
free(sa, M_SONAME);
|
|
|
|
return (xprt);
|
|
|
|
}
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
xprt = svc_xprt_alloc();
|
|
|
|
sx_init(&xprt->xp_lock, "xprt->xp_lock");
|
2008-03-26 15:23:12 +00:00
|
|
|
xprt->xp_pool = pool;
|
|
|
|
xprt->xp_socket = so;
|
|
|
|
xprt->xp_p1 = NULL;
|
|
|
|
xprt->xp_p2 = NULL;
|
|
|
|
xprt->xp_ops = &svc_vc_rendezvous_ops;
|
|
|
|
|
|
|
|
error = so->so_proto->pr_usrreqs->pru_sockaddr(so, &sa);
|
2009-08-24 10:09:30 +00:00
|
|
|
if (error) {
|
2008-03-26 15:23:12 +00:00
|
|
|
goto cleanup_svc_vc_create;
|
2009-08-24 10:09:30 +00:00
|
|
|
}
|
2008-03-26 15:23:12 +00:00
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
memcpy(&xprt->xp_ltaddr, sa, sa->sa_len);
|
2008-03-26 15:23:12 +00:00
|
|
|
free(sa, M_SONAME);
|
|
|
|
|
|
|
|
xprt_register(xprt);
|
|
|
|
|
|
|
|
solisten(so, SOMAXCONN, curthread);
|
|
|
|
|
|
|
|
SOCKBUF_LOCK(&so->so_rcv);
|
2009-06-04 14:13:06 +00:00
|
|
|
xprt->xp_upcallset = 1;
|
2009-06-01 21:17:03 +00:00
|
|
|
soupcall_set(so, SO_RCV, svc_vc_soupcall, xprt);
|
2008-03-26 15:23:12 +00:00
|
|
|
SOCKBUF_UNLOCK(&so->so_rcv);
|
|
|
|
|
|
|
|
return (xprt);
|
|
|
|
cleanup_svc_vc_create:
|
|
|
|
if (xprt)
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
svc_xprt_free(xprt);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a new transport for a socket optained via soaccept().
|
|
|
|
*/
|
|
|
|
SVCXPRT *
|
|
|
|
svc_vc_create_conn(SVCPOOL *pool, struct socket *so, struct sockaddr *raddr)
|
|
|
|
{
|
|
|
|
SVCXPRT *xprt = NULL;
|
|
|
|
struct cf_conn *cd = NULL;
|
|
|
|
struct sockaddr* sa = NULL;
|
2008-06-26 10:21:54 +00:00
|
|
|
struct sockopt opt;
|
|
|
|
int one = 1;
|
2008-03-26 15:23:12 +00:00
|
|
|
int error;
|
|
|
|
|
2008-06-26 10:21:54 +00:00
|
|
|
bzero(&opt, sizeof(struct sockopt));
|
|
|
|
opt.sopt_dir = SOPT_SET;
|
|
|
|
opt.sopt_level = SOL_SOCKET;
|
|
|
|
opt.sopt_name = SO_KEEPALIVE;
|
|
|
|
opt.sopt_val = &one;
|
|
|
|
opt.sopt_valsize = sizeof(one);
|
|
|
|
error = sosetopt(so, &opt);
|
2009-08-24 10:09:30 +00:00
|
|
|
if (error) {
|
2008-06-26 10:21:54 +00:00
|
|
|
return (NULL);
|
2009-08-24 10:09:30 +00:00
|
|
|
}
|
2008-06-26 10:21:54 +00:00
|
|
|
|
|
|
|
if (so->so_proto->pr_protocol == IPPROTO_TCP) {
|
|
|
|
bzero(&opt, sizeof(struct sockopt));
|
|
|
|
opt.sopt_dir = SOPT_SET;
|
|
|
|
opt.sopt_level = IPPROTO_TCP;
|
|
|
|
opt.sopt_name = TCP_NODELAY;
|
|
|
|
opt.sopt_val = &one;
|
|
|
|
opt.sopt_valsize = sizeof(one);
|
|
|
|
error = sosetopt(so, &opt);
|
2009-08-24 10:09:30 +00:00
|
|
|
if (error) {
|
2008-06-26 10:21:54 +00:00
|
|
|
return (NULL);
|
2009-08-24 10:09:30 +00:00
|
|
|
}
|
2008-06-26 10:21:54 +00:00
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
cd = mem_alloc(sizeof(*cd));
|
|
|
|
cd->strm_stat = XPRT_IDLE;
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
xprt = svc_xprt_alloc();
|
|
|
|
sx_init(&xprt->xp_lock, "xprt->xp_lock");
|
2008-03-26 15:23:12 +00:00
|
|
|
xprt->xp_pool = pool;
|
|
|
|
xprt->xp_socket = so;
|
|
|
|
xprt->xp_p1 = cd;
|
|
|
|
xprt->xp_p2 = NULL;
|
|
|
|
xprt->xp_ops = &svc_vc_ops;
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
/*
|
|
|
|
* See http://www.connectathon.org/talks96/nfstcp.pdf - client
|
|
|
|
* has a 5 minute timer, server has a 6 minute timer.
|
|
|
|
*/
|
|
|
|
xprt->xp_idletimeout = 6 * 60;
|
|
|
|
|
|
|
|
memcpy(&xprt->xp_rtaddr, raddr, raddr->sa_len);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
error = so->so_proto->pr_usrreqs->pru_sockaddr(so, &sa);
|
|
|
|
if (error)
|
|
|
|
goto cleanup_svc_vc_create;
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
memcpy(&xprt->xp_ltaddr, sa, sa->sa_len);
|
2008-03-26 15:23:12 +00:00
|
|
|
free(sa, M_SONAME);
|
|
|
|
|
|
|
|
xprt_register(xprt);
|
|
|
|
|
|
|
|
SOCKBUF_LOCK(&so->so_rcv);
|
2009-06-04 14:13:06 +00:00
|
|
|
xprt->xp_upcallset = 1;
|
2009-06-01 21:17:03 +00:00
|
|
|
soupcall_set(so, SO_RCV, svc_vc_soupcall, xprt);
|
2008-03-26 15:23:12 +00:00
|
|
|
SOCKBUF_UNLOCK(&so->so_rcv);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Throw the transport into the active list in case it already
|
|
|
|
* has some data buffered.
|
|
|
|
*/
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
xprt_active(xprt);
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
return (xprt);
|
|
|
|
cleanup_svc_vc_create:
|
|
|
|
if (xprt) {
|
|
|
|
mem_free(xprt, sizeof(*xprt));
|
|
|
|
}
|
|
|
|
if (cd)
|
|
|
|
mem_free(cd, sizeof(*cd));
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
/*
|
|
|
|
* Create a new transport for a backchannel on a clnt_vc socket.
|
|
|
|
*/
|
|
|
|
SVCXPRT *
|
|
|
|
svc_vc_create_backchannel(SVCPOOL *pool)
|
|
|
|
{
|
|
|
|
SVCXPRT *xprt = NULL;
|
|
|
|
struct cf_conn *cd = NULL;
|
|
|
|
|
|
|
|
cd = mem_alloc(sizeof(*cd));
|
|
|
|
cd->strm_stat = XPRT_IDLE;
|
|
|
|
|
|
|
|
xprt = svc_xprt_alloc();
|
|
|
|
sx_init(&xprt->xp_lock, "xprt->xp_lock");
|
|
|
|
xprt->xp_pool = pool;
|
|
|
|
xprt->xp_socket = NULL;
|
|
|
|
xprt->xp_p1 = cd;
|
|
|
|
xprt->xp_p2 = NULL;
|
|
|
|
xprt->xp_ops = &svc_vc_backchannel_ops;
|
|
|
|
return (xprt);
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
/*
|
|
|
|
* This does all of the accept except the final call to soaccept. The
|
|
|
|
* caller will call soaccept after dropping its locks (soaccept may
|
|
|
|
* call malloc).
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
svc_vc_accept(struct socket *head, struct socket **sop)
|
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
struct socket *so;
|
|
|
|
|
|
|
|
if ((head->so_options & SO_ACCEPTCONN) == 0) {
|
|
|
|
error = EINVAL;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
#ifdef MAC
|
2009-06-05 14:29:49 +00:00
|
|
|
error = mac_socket_check_accept(curthread->td_ucred, head);
|
2008-03-26 15:23:12 +00:00
|
|
|
if (error != 0)
|
|
|
|
goto done;
|
|
|
|
#endif
|
|
|
|
ACCEPT_LOCK();
|
|
|
|
if (TAILQ_EMPTY(&head->so_comp)) {
|
|
|
|
ACCEPT_UNLOCK();
|
|
|
|
error = EWOULDBLOCK;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
so = TAILQ_FIRST(&head->so_comp);
|
|
|
|
KASSERT(!(so->so_qstate & SQ_INCOMP), ("svc_vc_accept: so SQ_INCOMP"));
|
|
|
|
KASSERT(so->so_qstate & SQ_COMP, ("svc_vc_accept: so not SQ_COMP"));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Before changing the flags on the socket, we have to bump the
|
|
|
|
* reference count. Otherwise, if the protocol calls sofree(),
|
|
|
|
* the socket will be released due to a zero refcount.
|
|
|
|
* XXX might not need soref() since this is simpler than kern_accept.
|
|
|
|
*/
|
|
|
|
SOCK_LOCK(so); /* soref() and so_state update */
|
|
|
|
soref(so); /* file descriptor reference */
|
|
|
|
|
|
|
|
TAILQ_REMOVE(&head->so_comp, so, so_list);
|
|
|
|
head->so_qlen--;
|
|
|
|
so->so_state |= (head->so_state & SS_NBIO);
|
|
|
|
so->so_qstate &= ~SQ_COMP;
|
|
|
|
so->so_head = NULL;
|
|
|
|
|
|
|
|
SOCK_UNLOCK(so);
|
|
|
|
ACCEPT_UNLOCK();
|
|
|
|
|
|
|
|
*sop = so;
|
|
|
|
|
|
|
|
/* connection has been removed from the listen queue */
|
|
|
|
KNOTE_UNLOCKED(&head->so_rcv.sb_sel.si_note, 0);
|
|
|
|
done:
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*ARGSUSED*/
|
|
|
|
static bool_t
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
svc_vc_rendezvous_recv(SVCXPRT *xprt, struct rpc_msg *msg,
|
|
|
|
struct sockaddr **addrp, struct mbuf **mp)
|
2008-03-26 15:23:12 +00:00
|
|
|
{
|
|
|
|
struct socket *so = NULL;
|
|
|
|
struct sockaddr *sa = NULL;
|
|
|
|
int error;
|
2009-06-17 22:50:26 +00:00
|
|
|
SVCXPRT *new_xprt;
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The socket upcall calls xprt_active() which will eventually
|
|
|
|
* cause the server to call us here. We attempt to accept a
|
|
|
|
* connection from the socket and turn it into a new
|
|
|
|
* transport. If the accept fails, we have drained all pending
|
|
|
|
* connections so we call xprt_inactive().
|
|
|
|
*/
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
error = svc_vc_accept(xprt->xp_socket, &so);
|
|
|
|
|
|
|
|
if (error == EWOULDBLOCK) {
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
/*
|
|
|
|
* We must re-test for new connections after taking
|
|
|
|
* the lock to protect us in the case where a new
|
|
|
|
* connection arrives after our call to accept fails
|
|
|
|
* with EWOULDBLOCK. The pool lock protects us from
|
|
|
|
* racing the upcall after our TAILQ_EMPTY() call
|
|
|
|
* returns false.
|
|
|
|
*/
|
|
|
|
ACCEPT_LOCK();
|
|
|
|
mtx_lock(&xprt->xp_pool->sp_lock);
|
|
|
|
if (TAILQ_EMPTY(&xprt->xp_socket->so_comp))
|
|
|
|
xprt_inactive_locked(xprt);
|
|
|
|
mtx_unlock(&xprt->xp_pool->sp_lock);
|
|
|
|
ACCEPT_UNLOCK();
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
SOCKBUF_LOCK(&xprt->xp_socket->so_rcv);
|
2009-06-04 14:13:06 +00:00
|
|
|
if (xprt->xp_upcallset) {
|
|
|
|
xprt->xp_upcallset = 0;
|
|
|
|
soupcall_clear(xprt->xp_socket, SO_RCV);
|
|
|
|
}
|
2008-03-26 15:23:12 +00:00
|
|
|
SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv);
|
|
|
|
xprt_inactive(xprt);
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
sa = 0;
|
|
|
|
error = soaccept(so, &sa);
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
/*
|
|
|
|
* XXX not sure if I need to call sofree or soclose here.
|
|
|
|
*/
|
|
|
|
if (sa)
|
|
|
|
free(sa, M_SONAME);
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* svc_vc_create_conn will call xprt_register - we don't need
|
2009-06-17 22:50:26 +00:00
|
|
|
* to do anything with the new connection except derefence it.
|
2008-03-26 15:23:12 +00:00
|
|
|
*/
|
2009-06-17 22:50:26 +00:00
|
|
|
new_xprt = svc_vc_create_conn(xprt->xp_pool, so, sa);
|
|
|
|
if (!new_xprt) {
|
2008-06-26 10:21:54 +00:00
|
|
|
soclose(so);
|
2009-06-17 22:50:26 +00:00
|
|
|
} else {
|
|
|
|
SVC_RELEASE(new_xprt);
|
|
|
|
}
|
2008-06-26 10:21:54 +00:00
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
free(sa, M_SONAME);
|
|
|
|
|
|
|
|
return (FALSE); /* there is never an rpc msg to be processed */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*ARGSUSED*/
|
|
|
|
static enum xprt_stat
|
|
|
|
svc_vc_rendezvous_stat(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (XPRT_IDLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
svc_vc_destroy_common(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
SOCKBUF_LOCK(&xprt->xp_socket->so_rcv);
|
2009-06-04 14:13:06 +00:00
|
|
|
if (xprt->xp_upcallset) {
|
|
|
|
xprt->xp_upcallset = 0;
|
|
|
|
soupcall_clear(xprt->xp_socket, SO_RCV);
|
|
|
|
}
|
2008-03-26 15:23:12 +00:00
|
|
|
SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv);
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_destroy(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
if (xprt->xp_socket)
|
|
|
|
(void)soclose(xprt->xp_socket);
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
if (xprt->xp_netid)
|
|
|
|
(void) mem_free(xprt->xp_netid, strlen(xprt->xp_netid) + 1);
|
|
|
|
svc_xprt_free(xprt);
|
2008-03-26 15:23:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
svc_vc_rendezvous_destroy(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
|
|
|
|
svc_vc_destroy_common(xprt);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
svc_vc_destroy(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
struct cf_conn *cd = (struct cf_conn *)xprt->xp_p1;
|
|
|
|
|
|
|
|
svc_vc_destroy_common(xprt);
|
|
|
|
|
|
|
|
if (cd->mreq)
|
|
|
|
m_freem(cd->mreq);
|
|
|
|
if (cd->mpending)
|
|
|
|
m_freem(cd->mpending);
|
|
|
|
mem_free(cd, sizeof(*cd));
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static void
|
|
|
|
svc_vc_backchannel_destroy(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
struct cf_conn *cd = (struct cf_conn *)xprt->xp_p1;
|
|
|
|
struct mbuf *m, *m2;
|
|
|
|
|
|
|
|
svc_xprt_free(xprt);
|
|
|
|
m = cd->mreq;
|
|
|
|
while (m != NULL) {
|
|
|
|
m2 = m;
|
|
|
|
m = m->m_nextpkt;
|
|
|
|
m_freem(m2);
|
|
|
|
}
|
|
|
|
mem_free(cd, sizeof(*cd));
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
/*ARGSUSED*/
|
|
|
|
static bool_t
|
|
|
|
svc_vc_control(SVCXPRT *xprt, const u_int rq, void *in)
|
|
|
|
{
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool_t
|
|
|
|
svc_vc_rendezvous_control(SVCXPRT *xprt, const u_int rq, void *in)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static bool_t
|
|
|
|
svc_vc_backchannel_control(SVCXPRT *xprt, const u_int rq, void *in)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
static enum xprt_stat
|
|
|
|
svc_vc_stat(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
struct cf_conn *cd;
|
|
|
|
struct mbuf *m;
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
cd = (struct cf_conn *)(xprt->xp_p1);
|
|
|
|
|
|
|
|
if (cd->strm_stat == XPRT_DIED)
|
|
|
|
return (XPRT_DIED);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return XPRT_MOREREQS if we have buffered data and we are
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
* mid-record or if we have enough data for a record
|
|
|
|
* marker. Since this is only a hint, we read mpending and
|
|
|
|
* resid outside the lock. We do need to take the lock if we
|
|
|
|
* have to traverse the mbuf chain.
|
2008-03-26 15:23:12 +00:00
|
|
|
*/
|
|
|
|
if (cd->mpending) {
|
|
|
|
if (cd->resid)
|
|
|
|
return (XPRT_MOREREQS);
|
|
|
|
n = 0;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
m = cd->mpending;
|
|
|
|
while (m && n < sizeof(uint32_t)) {
|
|
|
|
n += m->m_len;
|
|
|
|
m = m->m_next;
|
|
|
|
}
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
if (n >= sizeof(uint32_t))
|
|
|
|
return (XPRT_MOREREQS);
|
|
|
|
}
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
if (soreadable(xprt->xp_socket))
|
|
|
|
return (XPRT_MOREREQS);
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
return (XPRT_IDLE);
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static enum xprt_stat
|
|
|
|
svc_vc_backchannel_stat(SVCXPRT *xprt)
|
|
|
|
{
|
|
|
|
struct cf_conn *cd;
|
|
|
|
|
|
|
|
cd = (struct cf_conn *)(xprt->xp_p1);
|
|
|
|
|
|
|
|
if (cd->mreq != NULL)
|
|
|
|
return (XPRT_MOREREQS);
|
|
|
|
|
|
|
|
return (XPRT_IDLE);
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
static bool_t
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
svc_vc_recv(SVCXPRT *xprt, struct rpc_msg *msg,
|
|
|
|
struct sockaddr **addrp, struct mbuf **mp)
|
2008-03-26 15:23:12 +00:00
|
|
|
{
|
|
|
|
struct cf_conn *cd = (struct cf_conn *) xprt->xp_p1;
|
|
|
|
struct uio uio;
|
|
|
|
struct mbuf *m;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
XDR xdrs;
|
2008-03-26 15:23:12 +00:00
|
|
|
int error, rcvflag;
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
/*
|
|
|
|
* Serialise access to the socket and our own record parsing
|
|
|
|
* state.
|
|
|
|
*/
|
|
|
|
sx_xlock(&xprt->xp_lock);
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
for (;;) {
|
|
|
|
/*
|
|
|
|
* If we have an mbuf chain in cd->mpending, try to parse a
|
|
|
|
* record from it, leaving the result in cd->mreq. If we don't
|
|
|
|
* have a complete record, leave the partial result in
|
|
|
|
* cd->mreq and try to read more from the socket.
|
|
|
|
*/
|
|
|
|
if (cd->mpending) {
|
|
|
|
/*
|
|
|
|
* If cd->resid is non-zero, we have part of the
|
|
|
|
* record already, otherwise we are expecting a record
|
|
|
|
* marker.
|
|
|
|
*/
|
|
|
|
if (!cd->resid) {
|
|
|
|
/*
|
|
|
|
* See if there is enough data buffered to
|
|
|
|
* make up a record marker. Make sure we can
|
|
|
|
* handle the case where the record marker is
|
|
|
|
* split across more than one mbuf.
|
|
|
|
*/
|
|
|
|
size_t n = 0;
|
|
|
|
uint32_t header;
|
|
|
|
|
|
|
|
m = cd->mpending;
|
|
|
|
while (n < sizeof(uint32_t) && m) {
|
|
|
|
n += m->m_len;
|
|
|
|
m = m->m_next;
|
|
|
|
}
|
|
|
|
if (n < sizeof(uint32_t))
|
|
|
|
goto readmore;
|
2011-01-10 21:35:10 +00:00
|
|
|
m_copydata(cd->mpending, 0, sizeof(header),
|
|
|
|
(char *)&header);
|
2008-03-26 15:23:12 +00:00
|
|
|
header = ntohl(header);
|
|
|
|
cd->eor = (header & 0x80000000) != 0;
|
|
|
|
cd->resid = header & 0x7fffffff;
|
|
|
|
m_adj(cd->mpending, sizeof(uint32_t));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Start pulling off mbufs from cd->mpending
|
|
|
|
* until we either have a complete record or
|
|
|
|
* we run out of data. We use m_split to pull
|
|
|
|
* data - it will pull as much as possible and
|
|
|
|
* split the last mbuf if necessary.
|
|
|
|
*/
|
|
|
|
while (cd->mpending && cd->resid) {
|
|
|
|
m = cd->mpending;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
if (cd->mpending->m_next
|
|
|
|
|| cd->mpending->m_len > cd->resid)
|
|
|
|
cd->mpending = m_split(cd->mpending,
|
2012-12-05 08:04:20 +00:00
|
|
|
cd->resid, M_WAITOK);
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
else
|
|
|
|
cd->mpending = NULL;
|
2008-03-26 15:23:12 +00:00
|
|
|
if (cd->mreq)
|
|
|
|
m_last(cd->mreq)->m_next = m;
|
|
|
|
else
|
|
|
|
cd->mreq = m;
|
|
|
|
while (m) {
|
|
|
|
cd->resid -= m->m_len;
|
|
|
|
m = m->m_next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If cd->resid is zero now, we have managed to
|
|
|
|
* receive a record fragment from the stream. Check
|
|
|
|
* for the end-of-record mark to see if we need more.
|
|
|
|
*/
|
|
|
|
if (cd->resid == 0) {
|
|
|
|
if (!cd->eor)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Success - we have a complete record in
|
|
|
|
* cd->mreq.
|
|
|
|
*/
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
xdrmbuf_create(&xdrs, cd->mreq, XDR_DECODE);
|
2008-03-26 15:23:12 +00:00
|
|
|
cd->mreq = NULL;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
|
|
|
|
|
|
|
if (! xdr_callmsg(&xdrs, msg)) {
|
|
|
|
XDR_DESTROY(&xdrs);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
|
|
|
|
*addrp = NULL;
|
|
|
|
*mp = xdrmbuf_getall(&xdrs);
|
|
|
|
XDR_DESTROY(&xdrs);
|
2008-03-26 15:23:12 +00:00
|
|
|
|
|
|
|
return (TRUE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
readmore:
|
|
|
|
/*
|
|
|
|
* The socket upcall calls xprt_active() which will eventually
|
|
|
|
* cause the server to call us here. We attempt to
|
|
|
|
* read as much as possible from the socket and put
|
|
|
|
* the result in cd->mpending. If the read fails,
|
|
|
|
* we have drained both cd->mpending and the socket so
|
|
|
|
* we can call xprt_inactive().
|
|
|
|
*/
|
|
|
|
uio.uio_resid = 1000000000;
|
|
|
|
uio.uio_td = curthread;
|
|
|
|
m = NULL;
|
|
|
|
rcvflag = MSG_DONTWAIT;
|
|
|
|
error = soreceive(xprt->xp_socket, NULL, &uio, &m, NULL,
|
|
|
|
&rcvflag);
|
|
|
|
|
|
|
|
if (error == EWOULDBLOCK) {
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
/*
|
|
|
|
* We must re-test for readability after
|
|
|
|
* taking the lock to protect us in the case
|
|
|
|
* where a new packet arrives on the socket
|
|
|
|
* after our call to soreceive fails with
|
|
|
|
* EWOULDBLOCK. The pool lock protects us from
|
|
|
|
* racing the upcall after our soreadable()
|
|
|
|
* call returns false.
|
|
|
|
*/
|
|
|
|
mtx_lock(&xprt->xp_pool->sp_lock);
|
|
|
|
if (!soreadable(xprt->xp_socket))
|
|
|
|
xprt_inactive_locked(xprt);
|
|
|
|
mtx_unlock(&xprt->xp_pool->sp_lock);
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (error) {
|
|
|
|
SOCKBUF_LOCK(&xprt->xp_socket->so_rcv);
|
2009-06-04 14:13:06 +00:00
|
|
|
if (xprt->xp_upcallset) {
|
|
|
|
xprt->xp_upcallset = 0;
|
|
|
|
soupcall_clear(xprt->xp_socket, SO_RCV);
|
|
|
|
}
|
2008-03-26 15:23:12 +00:00
|
|
|
SOCKBUF_UNLOCK(&xprt->xp_socket->so_rcv);
|
|
|
|
xprt_inactive(xprt);
|
|
|
|
cd->strm_stat = XPRT_DIED;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!m) {
|
|
|
|
/*
|
|
|
|
* EOF - the other end has closed the socket.
|
|
|
|
*/
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
xprt_inactive(xprt);
|
2008-03-26 15:23:12 +00:00
|
|
|
cd->strm_stat = XPRT_DIED;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sx_xunlock(&xprt->xp_lock);
|
2008-03-26 15:23:12 +00:00
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cd->mpending)
|
|
|
|
m_last(cd->mpending)->m_next = m;
|
|
|
|
else
|
|
|
|
cd->mpending = m;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static bool_t
|
|
|
|
svc_vc_backchannel_recv(SVCXPRT *xprt, struct rpc_msg *msg,
|
|
|
|
struct sockaddr **addrp, struct mbuf **mp)
|
|
|
|
{
|
|
|
|
struct cf_conn *cd = (struct cf_conn *) xprt->xp_p1;
|
|
|
|
struct ct_data *ct;
|
|
|
|
struct mbuf *m;
|
|
|
|
XDR xdrs;
|
|
|
|
|
|
|
|
sx_xlock(&xprt->xp_lock);
|
|
|
|
ct = (struct ct_data *)xprt->xp_p2;
|
|
|
|
if (ct == NULL) {
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
mtx_lock(&ct->ct_lock);
|
|
|
|
m = cd->mreq;
|
|
|
|
if (m == NULL) {
|
|
|
|
xprt_inactive(xprt);
|
|
|
|
mtx_unlock(&ct->ct_lock);
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
cd->mreq = m->m_nextpkt;
|
|
|
|
mtx_unlock(&ct->ct_lock);
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
|
|
|
|
|
|
|
xdrmbuf_create(&xdrs, m, XDR_DECODE);
|
|
|
|
if (! xdr_callmsg(&xdrs, msg)) {
|
|
|
|
XDR_DESTROY(&xdrs);
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
*addrp = NULL;
|
|
|
|
*mp = xdrmbuf_getall(&xdrs);
|
|
|
|
XDR_DESTROY(&xdrs);
|
|
|
|
return (TRUE);
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
static bool_t
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
svc_vc_reply(SVCXPRT *xprt, struct rpc_msg *msg,
|
|
|
|
struct sockaddr *addr, struct mbuf *m)
|
2008-03-26 15:23:12 +00:00
|
|
|
{
|
|
|
|
XDR xdrs;
|
|
|
|
struct mbuf *mrep;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
bool_t stat = TRUE;
|
2008-03-26 15:23:12 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Leave space for record mark.
|
|
|
|
*/
|
2012-12-05 08:04:20 +00:00
|
|
|
MGETHDR(mrep, M_WAITOK, MT_DATA);
|
2008-03-26 15:23:12 +00:00
|
|
|
mrep->m_len = 0;
|
|
|
|
mrep->m_data += sizeof(uint32_t);
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
xdrmbuf_create(&xdrs, mrep, XDR_ENCODE);
|
|
|
|
|
|
|
|
if (msg->rm_reply.rp_stat == MSG_ACCEPTED &&
|
|
|
|
msg->rm_reply.rp_acpt.ar_stat == SUCCESS) {
|
|
|
|
if (!xdr_replymsg(&xdrs, msg))
|
|
|
|
stat = FALSE;
|
|
|
|
else
|
|
|
|
xdrmbuf_append(&xdrs, m);
|
|
|
|
} else {
|
|
|
|
stat = xdr_replymsg(&xdrs, msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stat) {
|
2008-03-26 15:23:12 +00:00
|
|
|
m_fixhdr(mrep);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepend a record marker containing the reply length.
|
|
|
|
*/
|
2012-12-05 08:04:20 +00:00
|
|
|
M_PREPEND(mrep, sizeof(uint32_t), M_WAITOK);
|
2008-03-26 15:23:12 +00:00
|
|
|
*mtod(mrep, uint32_t *) =
|
|
|
|
htonl(0x80000000 | (mrep->m_pkthdr.len
|
|
|
|
- sizeof(uint32_t)));
|
|
|
|
error = sosend(xprt->xp_socket, NULL, NULL, mrep, NULL,
|
|
|
|
0, curthread);
|
|
|
|
if (!error) {
|
|
|
|
stat = TRUE;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_freem(mrep);
|
|
|
|
}
|
|
|
|
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
XDR_DESTROY(&xdrs);
|
2008-03-26 15:23:12 +00:00
|
|
|
xprt->xp_p2 = NULL;
|
|
|
|
|
|
|
|
return (stat);
|
|
|
|
}
|
|
|
|
|
2012-12-08 00:29:16 +00:00
|
|
|
static bool_t
|
|
|
|
svc_vc_backchannel_reply(SVCXPRT *xprt, struct rpc_msg *msg,
|
|
|
|
struct sockaddr *addr, struct mbuf *m)
|
|
|
|
{
|
|
|
|
struct ct_data *ct;
|
|
|
|
XDR xdrs;
|
|
|
|
struct mbuf *mrep;
|
|
|
|
bool_t stat = TRUE;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Leave space for record mark.
|
|
|
|
*/
|
|
|
|
MGETHDR(mrep, M_WAITOK, MT_DATA);
|
|
|
|
mrep->m_len = 0;
|
|
|
|
mrep->m_data += sizeof(uint32_t);
|
|
|
|
|
|
|
|
xdrmbuf_create(&xdrs, mrep, XDR_ENCODE);
|
|
|
|
|
|
|
|
if (msg->rm_reply.rp_stat == MSG_ACCEPTED &&
|
|
|
|
msg->rm_reply.rp_acpt.ar_stat == SUCCESS) {
|
|
|
|
if (!xdr_replymsg(&xdrs, msg))
|
|
|
|
stat = FALSE;
|
|
|
|
else
|
|
|
|
xdrmbuf_append(&xdrs, m);
|
|
|
|
} else {
|
|
|
|
stat = xdr_replymsg(&xdrs, msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stat) {
|
|
|
|
m_fixhdr(mrep);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepend a record marker containing the reply length.
|
|
|
|
*/
|
|
|
|
M_PREPEND(mrep, sizeof(uint32_t), M_WAITOK);
|
|
|
|
*mtod(mrep, uint32_t *) =
|
|
|
|
htonl(0x80000000 | (mrep->m_pkthdr.len
|
|
|
|
- sizeof(uint32_t)));
|
|
|
|
sx_xlock(&xprt->xp_lock);
|
|
|
|
ct = (struct ct_data *)xprt->xp_p2;
|
|
|
|
if (ct != NULL)
|
|
|
|
error = sosend(ct->ct_socket, NULL, NULL, mrep, NULL,
|
|
|
|
0, curthread);
|
|
|
|
else
|
|
|
|
error = EPIPE;
|
|
|
|
sx_xunlock(&xprt->xp_lock);
|
|
|
|
if (!error) {
|
|
|
|
stat = TRUE;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_freem(mrep);
|
|
|
|
}
|
|
|
|
|
|
|
|
XDR_DESTROY(&xdrs);
|
|
|
|
|
|
|
|
return (stat);
|
|
|
|
}
|
|
|
|
|
2008-03-26 15:23:12 +00:00
|
|
|
static bool_t
|
|
|
|
svc_vc_null()
|
|
|
|
{
|
|
|
|
|
|
|
|
return (FALSE);
|
|
|
|
}
|
|
|
|
|
2009-06-01 21:17:03 +00:00
|
|
|
static int
|
2008-03-26 15:23:12 +00:00
|
|
|
svc_vc_soupcall(struct socket *so, void *arg, int waitflag)
|
|
|
|
{
|
|
|
|
SVCXPRT *xprt = (SVCXPRT *) arg;
|
|
|
|
|
|
|
|
xprt_active(xprt);
|
2009-06-01 21:17:03 +00:00
|
|
|
return (SU_OK);
|
2008-03-26 15:23:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#if 0
|
|
|
|
/*
|
|
|
|
* Get the effective UID of the sending process. Used by rpcbind, keyserv
|
|
|
|
* and rpc.yppasswdd on AF_LOCAL.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
__rpc_get_local_uid(SVCXPRT *transp, uid_t *uid) {
|
|
|
|
int sock, ret;
|
|
|
|
gid_t egid;
|
|
|
|
uid_t euid;
|
|
|
|
struct sockaddr *sa;
|
|
|
|
|
|
|
|
sock = transp->xp_fd;
|
Implement support for RPCSEC_GSS authentication to both the NFS client
and server. This replaces the RPC implementation of the NFS client and
server with the newer RPC implementation originally developed
(actually ported from the userland sunrpc code) to support the NFS
Lock Manager. I have tested this code extensively and I believe it is
stable and that performance is at least equal to the legacy RPC
implementation.
The NFS code currently contains support for both the new RPC
implementation and the older legacy implementation inherited from the
original NFS codebase. The default is to use the new implementation -
add the NFS_LEGACYRPC option to fall back to the old code. When I
merge this support back to RELENG_7, I will probably change this so
that users have to 'opt in' to get the new code.
To use RPCSEC_GSS on either client or server, you must build a kernel
which includes the KGSSAPI option and the crypto device. On the
userland side, you must build at least a new libc, mountd, mount_nfs
and gssd. You must install new versions of /etc/rc.d/gssd and
/etc/rc.d/nfsd and add 'gssd_enable=YES' to /etc/rc.conf.
As long as gssd is running, you should be able to mount an NFS
filesystem from a server that requires RPCSEC_GSS authentication. The
mount itself can happen without any kerberos credentials but all
access to the filesystem will be denied unless the accessing user has
a valid ticket file in the standard place (/tmp/krb5cc_<uid>). There
is currently no support for situations where the ticket file is in a
different place, such as when the user logged in via SSH and has
delegated credentials from that login. This restriction is also
present in Solaris and Linux. In theory, we could improve this in
future, possibly using Brooks Davis' implementation of variant
symlinks.
Supporting RPCSEC_GSS on a server is nearly as simple. You must create
service creds for the server in the form 'nfs/<fqdn>@<REALM>' and
install them in /etc/krb5.keytab. The standard heimdal utility ktutil
makes this fairly easy. After the service creds have been created, you
can add a '-sec=krb5' option to /etc/exports and restart both mountd
and nfsd.
The only other difference an administrator should notice is that nfsd
doesn't fork to create service threads any more. In normal operation,
there will be two nfsd processes, one in userland waiting for TCP
connections and one in the kernel handling requests. The latter
process will create as many kthreads as required - these should be
visible via 'top -H'. The code has some support for varying the number
of service threads according to load but initially at least, nfsd uses
a fixed number of threads according to the value supplied to its '-n'
option.
Sponsored by: Isilon Systems
MFC after: 1 month
2008-11-03 10:38:00 +00:00
|
|
|
sa = (struct sockaddr *)transp->xp_rtaddr;
|
2008-03-26 15:23:12 +00:00
|
|
|
if (sa->sa_family == AF_LOCAL) {
|
|
|
|
ret = getpeereid(sock, &euid, &egid);
|
|
|
|
if (ret == 0)
|
|
|
|
*uid = euid;
|
|
|
|
return (ret);
|
|
|
|
} else
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
#endif
|