user/sven/linux.git/include/linux/nfs_mount.h, branch tmp/leds/core

NFS: add "[no]resvport" mount option

2008-12-23T20:21:37Z

The standard default security setting for NFS is AUTH_SYS. An NFS client connects to NFS servers via a privileged source port and a fixed standard destination port (2049). The client sends raw uid and gid numbers to identify users making NFS requests, and the server assumes an appropriate authority on the client has vetted these values because the source port is privileged. On Linux, by default in-kernel RPC services use a privileged port in the range between 650 and 1023 to avoid using source ports of well- known IP services. Using such a small range limits the number of NFS mount points and the number of unique NFS servers to which a client can connect concurrently. An NFS client can use unprivileged source ports to expand the range of source port numbers, allowing more concurrent server connections and more NFS mount points. Servers must explicitly allow NFS connections from unprivileged ports for this to work. In the past, bumping the value of the sunrpc.max_resvport sysctl on the client would permit the NFS client to use unprivileged ports. Bumping this setting also changes the maximum port number used by other in-kernel RPC services, some of which still required a port number less than 1023. This is exacerbated by the way source port numbers are chosen by the Linux RPC client, which starts at the top of the range and works downwards. It means that bumping the maximum means all RPC services requesting a source port will likely get an unprivileged port instead of a privileged one. Changing this setting effects all NFS mount points on a client. A sysadmin could not selectively choose which mount points would use non-privileged ports and which could not. Lastly, this mechanism of expanding the limit on the number of NFS mount points was entirely undocumented. To address the need for the NFS client to use a large range of source ports without interfering with the activity of other in-kernel RPC services, we introduce a new NFS mount option. This option explicitly tells only the NFS client to use a non-privileged source port when communicating with the NFS server for one specific mount point. This new mount option is called "resvport," like the similar NFS mount option on FreeBSD and Mac OS X. A sister patch for nfs-utils will be submitted that documents this new option in nfs(5). The default setting for this new mount option requires the NFS client to use a privileged port, as before. Explicitly specifying the "noresvport" mount option allows the NFS client to use an unprivileged source port for this mount point when connecting to the NFS server port. This mount option is supported only for text-based NFS mounts. [ Sidebar: it is widely known that security mechanisms based on the use of privileged source ports are ineffective. However, the NFS client can combine the use of unprivileged ports with the use of secure authentication mechanisms, such as Kerberos. This allows a large number of connections and mount points while ensuring a useful level of security. Eventually we may change the default setting for this option depending on the security flavor used for the mount. For example, if the mount is using only AUTH_SYS, then the default setting will be "resvport;" if the mount is using a strong security flavor such as krb5, the default setting will be "noresvport." ] Signed-off-by: Chuck Lever [Trond.Myklebust@netapp.com: Fixed a bug whereby nfs4_init_client() was being called with incorrect arguments.] Signed-off-by: Trond Myklebust

NFS: Add options for finer control of the lookup cache

2008-10-07T21:22:20Z

Add the flag NFS_MOUNT_LOOKUP_CACHE_NONEG to turn off the caching of negative dentries. In reality what we do is to force nfs_lookup_revalidate() to always discard negative dentries. Add the flag NFS_MOUNT_LOOKUP_CACHE_NONE for enforcing stricter revalidation of dentries. It forces the revalidate code to always do a lookup instead of just checking the cached mtime of the parent directory. Signed-off-by: Trond Myklebust

NFS: Switch from intr mount option to TASK_KILLABLE

2007-12-06T22:40:25Z

By using the TASK_KILLABLE infrastructure, we can get rid of the 'intr' mount option. We have to use _killable everywhere instead of _interruptible as we get rid of rpc_clnt_sigmask/sigunmask. Signed-off-by: Liam R. Howlett Signed-off-by: Matthew Wilcox

NFS: Add the mount option "nosharecache"

2007-07-11T03:40:48Z

Prior to David Howell's mount changes in 2.6.18, users who mounted different directories which happened to be from the same filesystem on the server would get different super blocks, and hence could choose different mount options. As long as there were no hard linked files that crossed from one subtree to another, this was quite safe. Post the changes, if the two directories are on the same filesystem (have the same 'fsid'), they will share the same super block, and hence the same mount options. Add a flag to allow users to elect not to share the NFS super block with another mount point, even if the fsids are the same. This will allow users to set different mount options for the two different super blocks, as was previously possible. It is still up to the user to ensure that there are no cache coherency issues when doing this, however the default behaviour will be to share super blocks whenever two paths result in the same fsid. Signed-off-by: Trond Myklebust

NFS: Clean-up: Define macros for maximum host and export path name lengths

2007-07-11T03:40:44Z

Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust

NFS: Added support to turn off the NFSv3 READDIRPLUS RPC.

2007-05-01T05:17:16Z

READDIRPLUS can be a performance hindrance when the client is working with large directories. In addition, some servers still have bugs in their implementations (e.g. Tru64 returns wrong values for the fsid). Add a mount flag to enable users to turn it off at mount time following the implementation in Apple's NFS client. Signed-off-by: Steve Dickson Signed-off-by: Trond Myklebust

[PATCH] NFS: Add support for NFSv3 ACLs

2005-06-22T20:07:24Z

This adds acl support fo nfs clients via the NFSACL protocol extension, by implementing the getxattr, listxattr, setxattr, and removexattr iops for the system.posix_acl_access and system.posix_acl_default attributes. This patch implements a dumb version that uses no caching (and thus adds some overhead). (Another patch in this patchset adds caching as well.) Signed-off-by: Andreas Gruenbacher Acked-by: Olaf Kirch Signed-off-by: Andrew Morton Signed-off-by: Trond Myklebust

[PATCH] SELinux: context mount support - NFS

2004-02-16T02:05:17Z

From: James Morris This patch modifies the kernel's NFS mount data structure to include SELinux context mount data. It allows NFS fileystems to be labeled on a per-mountpoint basis, and should not affect existing versions of userspace mount. (A patch to the userspace mount code is available at http://people.redhat.com/jmorris/selinux/context_mounts/)

[PATCH] Allow unattended nfs3/krb5 mounts

2003-07-17T03:28:19Z

The comment in nfs_get_root() basically describes the patch: Some authentication types (gss/krb5, most notably) are such that root won't be able to present a credential for GETATTR (ie, getroot()). An easy way (ie, without this patch) to have unattended mounts is to have a root/host@REALM (or similar) principal stashed in a keytab, which root (rather, gssd) can use. However, this might not be desirable for many sites. In any case, RFC2623 specifically describes the problem addressed here. Notes: - Root inode gets inum of 1. This doesn't seem to matter, but may be aesthetically unpleasing. I wanted to choose an inum unlikely to conflict with an existing inum (although NFS has specific support for that). It looks like more work than it's worth to change the inum after the info is available. AFAICT it's not critical info. - Solaris has this "wierd" (but understandable) behavior that after mounting without a credential, the mount point is not visible at all until an access is attempted with a credential. This now-you-see-it- now-you-don't behavior doesn't seem worthwhile to reproduce here. - Unfortunately, MOUNT_VERSION must go to 5. Some kernels with ver 4 do not understand pseudoflavor. Keeping it at 4 means that the userland mount can't know for sure whether the kernel accepted the option or not. (Unless I'm missing some hack that could be done.) It works in my environment, against a netapp server (with the rpcsec_gss patch I provided earlier).

[PATCH] RPCSEC_GSS authentication framework [4/6]

2003-01-13T05:41:33Z

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.