I find myself wanting to NFS export a filesystem to all the machines on a network with one set of export options, and to a restricted subset of machines on the same network with a slightly different set of options. I expected to be able to do this with an /etc/exports line something like this: /export -rw,sync,fsid=0,sec=krb5 163.1.248.0/22 @trusted(sec=sys) the intention being that any machine on the subnet can mount the filesystem, if they use Kerberos authentication, and the members of the netgroup "trusted" can opt to use AUTH_SYS rather than Kerberos. However, it appears that the export lists in-core are always held in some sort of sorted order. No matter how the /etc/exports file is written, if a filesystem is exported to several different "machine name formats" then at mount request time the checks always seem to be done in the order: match against FQDN; match against IP addresses and IP ranges; match against wildcard hostnames; match match against netgroups; match "<world>". First positive match determines the NFS export parameters that the server applies to the If the client matches both a subnet "name format" and is a member of a netgroup then the options set for the subnet always get applied to a mount request, and the client is never tested for membership of the netgroup. The same applies to clients that match both a wildcarded domain name and are also a member of a netgroup. The relatively low position of netgroups in the pecking order means that they are far less useful than might otherwise be the case. If they were treated as ranking after FQDNs but before IP addresses then there would be a relatively easy way to express an access control rule of the form "all the machines in the organisation can access this resource with one set of options, and a subset of those machines get this alternative set of options". As things stand, it looks to me as though the only way to implement the sort of rule that I want is to maintain two netgroups: the "trusted" one, and a manually maintained list of all the machines in the organisation that aren't on the "trusted" list? Regards, -- Neil Hoggarth -------------- Department of Physiology, Anatomy and Genetics Head of IT --------------------------------------- University of Oxford, UK ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued. Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead. http://vger.kernel.org/vger-lists.html#linux-nfs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
