An error occurred fetching the project authors.
- 26 Feb, 2004 1 commit
-
-
Andrew Morton authored
From: NeilBrown <neilb@cse.unsw.edu.au> From: "J. Bruce Fields" <bfields@fieldses.org> Note that the user (or exportfs, on the user's behalf) allows a gss pseudoflavor to be used to access an export by exporting to a special client named "gss/pseudoflavor-name", e.g., "gss/krb5" or "gss/lipkey-i".
-
- 03 Feb, 2003 1 commit
-
-
Kai Germaschewski authored
One of the goals of the whole new modversions implementation: export-objs is gone for good!
-
- 13 Jan, 2003 2 commits
-
-
Trond Myklebust authored
The following patch provides minimal client support for the (mandatory) Kerberos V5 authentication mechanism under RPCSEC_GSS. See RFC2623 and RFC3010 for protocol details. Only authentication is supported for the moment. Data integrity and/or data privacy (encryption) will be implemented at a later stage.
-
Trond Myklebust authored
This patch provides the basic framework for RPCSEC_GSS authentication in the RPC client. The protocol is fully described in RFC-2203. Sun has supported it in their commercial NFSv3 and v2 implementations for quite some time, and it has been specified in RFC3010 as being mandatory for NFSv4. - Update the mount_data struct for NFSv2 and v3 in order to allow them to pass an RPCSEC_GSS security flavour. Compatibility with existing versions of the 'mount' program is ensured by requiring that RPCSEC support be enabled using the new flag NFS_MOUNT_SECFLAVOUR. - Provide secure authentication, and later data encryption on a per-user basis. A later patch will an provide an implementation of the Kerberos 5 security mechanism. SPKM and LIPKEY are still being planned. - Security context negotiation and initialization are all assumed to be done in userland. A later patch will provide the actual upcall mechanisms to allow for this.
-