Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
If you're getting nobody:nobody on an NFS mount you have an NFS version mismatch, (usually between V3 V4) to get around this use the following as mount options on the client: hard,bg,intr,vers=3 e.g: mount -o hard,bg,intr,vers=3 server:/pool/zfs /mountpoint -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On 12 mar 2010, at 03.58, Damon Atkins wrote: ... Unfortunately DNS spoofing exists, which means forward lookups can be poison. And IP address spoofing, and... The best (maybe only) way to make NFS secure is NFSv4 and Kerb5 used together. Amen! DNS is NOT an authentication system! IP is NOT an authentication system! I don't think the (rw|root|...)=(hostname|address) kind of functionality has any place in a system from after the 80's, when the world got connected and security became an issue for the masses. It should be an extra feature marked with a big insecure that you should have to enable through a very cumbersome process. Instead, use Kerberos, or if that is not possible, at least use IPSEC to make IP address spoofing harder. /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
rs == Ragnar Sundblad ra...@csc.kth.se writes: rs use IPSEC to make IP address spoofing harder. IPsec with channel binding is win, but not until SA's are offloaded to the NIC and all NIC's can do IPsec AES at line rate. Until this happens you need to accept there will be some protocols used on SAN that are not on ``the Internet'' and for which your axiomatic security declarations don't apply, where the relevant features are things like doing the DNS lookup in the proper .rhosts manner and doing uRPF, minimum, and more optimistically stop adding new protocols without IPv6 support, and start adding support for multiple IP stacks / VRF's. If saying ``the only way to do any given thing is twicecrypted kerberized ipsec within dnssec namespaces'' is blocking doing these immediate plaintext things that allow a host to participate in both the internet and a SAN at once, well that's no good either. pgptkJNIK5h42.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
mingli liming...@gmail.com writes: Thank Erik, and I will try it, but the new question is that the root of the NFS server mapped as nobody at the NFS client. For this issue, I set up a new test NFS server and NFS client, and with the same option, at this test environment, the file owner mapped correctly, it confused me. From the original post in this thread it wasn't clear if you're doing this on a local lan, and if both server and client are opensolaris machines. Maybe I missed it. I don't have any problems now and don't use any of the options to sharenfs that you showed. zfs get sharenfs z3/projects NAME PROPERTY VALUE SOURCE z3/projects sharenfs onlocal Just a simple `on'. At first, I had all kinds of problems and being a newbie nfs user seemed to see all kinds of strange phenomena, including seeing `nobody:nobody' as owner:group I had the version for nfs set properly on the opensolaris server but it turned to be only set for the server: grep NFS_SERVER_VERSMAX /etc/default/nfs #NFS_SERVER_VERSMAX=4 NFS_SERVER_VERSMAX=3 But somehow had completely overlooked the CLIENT setting: grep NFS_CLIENT_VERSMAX /etc/default/nfs grep NFS_CLIENT_VERSMAX /etc/default/nfs # NFS_CLIENT_VERSMAX=4 # NFS_CLIENT_VERSMAX=3 I'd been running with both commented out instead of what I needed, like this: NFS_CLIENT_VERSMAX=3 (uncommented) The client was a linux machine and it was the client trying to mount the share as version 4. What tipped me off was accidentally seeing something in the output of the linux `mount' cmd that indicated the share was mounted as version 4 nfs. Once I made the correct setting for NFS_CLIENT... things just started working. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On 8 apr 2010, at 23.21, Miles Nordin wrote: rs == Ragnar Sundblad ra...@csc.kth.se writes: rs use IPSEC to make IP address spoofing harder. IPsec with channel binding is win, but not until SA's are offloaded to the NIC and all NIC's can do IPsec AES at line rate. Until this happens you need to accept there will be some protocols used on SAN that are not on ``the Internet'' and for which your axiomatic security declarations don't apply, where the relevant features are things like doing the DNS lookup in the proper .rhosts manner and doing uRPF, minimum, and more optimistically stop adding new protocols without IPv6 support, and start adding support for multiple IP stacks / VRF's. If saying ``the only way to do any given thing is twicecrypted kerberized ipsec within dnssec namespaces'' is blocking doing these immediate plaintext things that allow a host to participate in both the internet and a SAN at once, well that's no good either. I totally agree. Since DNS, fqdn, and the like was mentioned, I don't think this was intended for a SAN, not-on-the-internet, environment. uRPF and other filters may of course harden your environment. Let's hope everyone using the NFS features in question all use them in a completely non-spoofable (L1..L3 and name resolver) setup, then! ;-) /ragge ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
pantzer5 wrote: These days I am a fan for forward check access lists, because any one who owns a DNS server can say that for IPAddressX returns aserver.google.com. They can not set the forward lookup outside of their domain but they can setup a reverse lookup. The other advantage is forword looking access lists is you can use DNS Alias in access lists as well. That is not true, you have to have a valid A record in the correct domain. I am not sure what this means, unless it indicates every application follows the steps outline below. Unfortunately, only a few applications/services do. This is how it works (and how you should check you reverse lookups in your applications): 1. Do a reverse lookup. 1b check if the name matches any hosts listed in the access list 2. Do a lookup with the name from 1. 3. Check that the IP address is one of the addresses you got in 2. Ignore the reverse lookup if the check in 3 fails. The above describes a forward lookup check, its just uses reverse lookup to determine what forward to lookup. The other method is when the service starts or re-reads the access list it finds A record/IP address for all the names in the access list and keeps a record of them, which it uses for checking when a connection comes in, saves doing the DNS lookup when a new connection starts, but it means all the DNS overhead is at the start. Unfortunately DNS spoofing exists, which means forward lookups can be poison. The best (maybe only) way to make NFS secure is NFSv4 and Kerb5 used together. Cheers -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
Thank Erik, and I will try it, but the new question is that the root of the NFS server mapped as nobody at the NFS client. For this issue, I set up a new test NFS server and NFS client, and with the same option, at this test environment, the file owner mapped correctly, it confused me. Thanks, Ming -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
I' ve found that the NFS host based settings required the FQDN, and that the reverse lookup must be available in your DNS. Try rw,root=host1.mydomain.net Cheers, Erik On 10 mars 2010, at 05:47, mingli wrote: And I update the sharenfs option with rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. Thanks. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On Tue, 2010-03-09 at 20:47 -0800, mingli wrote: And I update the sharenfs option with rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. Thanks. I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). Perhaps it's because I left the NFSv4 domain setting at the default. (I'm just using NFSv3, but trying to come up with an explanation. In any case, using the FQDN works.) -Andrew ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
Andrew Daugherity adaugher...@tamu.edu writes: And I update the sharenfs option with rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. Thanks. I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). Perhaps it's because I left the NFSv4 domain setting at the default. (I'm just using NFSv3, but trying to come up with an explanation. In any case, using the FQDN works.) if you wanted to add more would it just be separated with a comma: sharenfs=on,rw,ro...@198.xxx.xxx.xxx,userna...@192.xxx.xxx.101 or do you have to add the rw, for each one too: sharenfs=on,rw,ro...@198.xxx.xxx.xxx,rw,userna...@192.xxx.xxx.102 Is any of that syntax right? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On 03/11/10 05:42 AM, Andrew Daugherity wrote: On Tue, 2010-03-09 at 20:47 -0800, mingli wrote: And I update the sharenfs option with rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. Thanks. I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). Perhaps it's because I left the NFSv4 domain setting at the default. (I'm just using NFSv3, but trying to come up with an explanation. In any case, using the FQDN works.) I have found the same, whether sharing to Linux or Solaris hosts, the FQDN appears to be required. This doesn't appear to be documented anywhere. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
ea == erik ableson eable...@me.com writes: dc == Dennis Clarke dcla...@blastwave.org writes: rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. ea I' ve found that the NFS host based settings required the ea FQDN, and that the reverse lookup must be available in your ea DNS. I found, oddly, the @a.b.c.d/y syntax works only if the client's IP has reverse lookup. I had to add bogus hostnames to /etc/hosts for the whole /24 because if I didn't, for v3 it would reject mounts immediately, and for v4 mountd would core dump (and get restarted) which you see from the client as a mount that appears to hang. This is all using the @ip/mask syntax. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6901832 If you use hostnames instead, it makes sense that you would have to use FQDN's. If you want to rewrite mountd to allow using short hostnames, the access checking has to be done like this: at export time: given hostname- forward nss lookup - list of IP's - remember IP's at mount time: client IP - check against list of remembered IP's but with fqdn's it can be: at export time: given hostname - remember it at mount time: client IP - reverse nss lookup - check against remembered list \--forward lookup-verify client IP among results The second way, all the lookups happen at mount time rather than export time. This way the data in the nameservice can change without forcing you to learn and then invoke some kind of ``rescan the exported filesystems'' command or making mountd remember TTL's for its cached nss data, or any such complexity. Keep all the nameservice caching inside nscd so there is only one place to flush it! However the forward lookup is mandatory for security, not optional OCDism. Without it, anyone from any IP can access your NFS server so long as he has control of his reverse lookup, which he probably does. I hope mountd is doing that forward lookup! dc Try to use a backslash to escape those special chars like so : dc zfs set dc sharenfs=nosub\,nosuid\,rw\=hostname1\:hostname2\,root\=hostname2 dc zpoolname/zfsname/pathname wth? Commas and colons are not special characters. This is silly. pgptWVuUb6wBm.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
Ian Collins wrote: On 03/11/10 05:42 AM, Andrew Daugherity wrote: I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). I have found the same, whether sharing to Linux or Solaris hosts, the FQDN appears to be required. It's not quite true that you need the FQDN, as it still does depend on the name service setup. However, what is true is this: to authenticate a client, the server does a IP-to-hostname mapping and compares the string with the string on the share entry. If the strings match (ignoring case), the client gets access. If not, the client does not get access. This has confused many, and it's not clear how or where to document this so that it does not cause more confusion. RFEs with example language would be welcome. So, to make a long story short, if you log into the server from the client and do who am i, you will get the host name you need for the share. Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
ea == erik ableson eable...@me.com writes: dc == Dennis Clarke dcla...@blastwave.org writes: rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. ea I' ve found that the NFS host based settings required the ea FQDN, and that the reverse lookup must be available in your ea DNS. I found, oddly, the @a.b.c.d/y syntax works only if the client's IP has reverse lookup. I had to add bogus hostnames to /etc/hosts for the whole /24 because if I didn't, for v3 it would reject mounts immediately, and for v4 mountd would core dump (and get restarted) which you see from the client as a mount that appears to hang. This is all using the @ip/mask syntax. I have LDAP and DNS in place for name resolution and NFS v4 works fine with either format in the sharenfs parameter. Never seen a problem. The Solaris 8 an 9 NFS clients work fine also. http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6901832 If you use hostnames instead, it makes sense that you would have to use FQDN's. If you want to rewrite mountd to allow using short hostnames, the access checking has to be done like this: at export time: given hostname- forward nss lookup - list of IP's - remember IP's at mount time: client IP - check against list of remembered IP's but with fqdn's it can be: at export time: given hostname - remember it at mount time: client IP - reverse nss lookup - check against remembered list \--forward lookup-verify client IP among results The second way, all the lookups happen at mount time rather than export time. This way the data in the nameservice can change without forcing you to learn and then invoke some kind of ``rescan the exported filesystems'' command or making mountd remember TTL's for its cached nss data, or any such complexity. Keep all the nameservice caching inside nscd so there is only one place to flush it! However the forward lookup is mandatory for security, not optional OCDism. Without it, anyone from any IP can access your NFS server so long as he has control of his reverse lookup, which he probably does. I hope mountd is doing that forward lookup! dc Try to use a backslash to escape those special chars like so : dc zfs set dc sharenfs=nosub\,nosuid\,rw\=hostname1\:hostname2\,root\=hostname2 dc zpoolname/zfsname/pathname wth? Commas and colons are not special characters. This is silly. Works real well. -- Dennis ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On 03/11/10 09:27 AM, Robert Thurlow wrote: Ian Collins wrote: On 03/11/10 05:42 AM, Andrew Daugherity wrote: I've found that when using hostnames in the sharenfs line, I had to use the FQDN; the short hostname did not work, even though both client and server were in the same DNS domain and that domain is in the search path, and nsswitch uses DNS for hosts (read: 'ping client1' works fine, as does 'mount server:/export/fs /mnt' from client1). I have found the same, whether sharing to Linux or Solaris hosts, the FQDN appears to be required. It's not quite true that you need the FQDN, as it still does depend on the name service setup. However, what is true is this: to authenticate a client, the server does a IP-to-hostname mapping and compares the string with the string on the share entry. If the strings match (ignoring case), the client gets access. If not, the client does not get access. This has confused many, and it's not clear how or where to document this so that it does not cause more confusion. RFEs with example language would be welcome. So, to make a long story short, if you log into the server from the client and do who am i, you will get the host name you need for the share. Thanks for the clarification Rob. Digging a little deeper, this is documented in the share_nfs man page: access_list The access_list argument is a colon-separated list whose components may be any number of the following: hostname The name of a host. With a server configured for DNS or LDAP naming in the nsswitch hosts entry, any hostname must be represented as a fully qualified DNS or LDAP name. Maybe your last paragraph could be added to the NOTES section on that page? -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
dc == Dennis Clarke dcla...@blastwave.org writes: dc zfs set dc sharenfs=nosub\,nosuid\,rw\=hostname1\:hostname2\,root\=hostname2 dc zpoolname/zfsname/pathname wth? Commas and colons are not special characters. This is silly. dc Works real well. I said it was silly, not broken. It's cargo-cult. Try this: \z\f\s \s\e\t \s\h\a\r\e\n\f\s\=\n\o\s\u\b\,\n\o\s\u\i\d\,\r\w\=\h\o\s\t\n\a\m\e\1\:\h\o\s\t\n\a\m\e\2\,\r\o\o\t\=\h\o\s\t\n\a\m\e\2 \z\p\o\o\l\n\a\m\e\/\z\f\s\n\a\m\e\/\p\a\t\h\n\a\m\e works real well, too. pgp9sZc4ojaDX.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
On 3/10/2010 3:27 PM, Robert Thurlow wrote: As said earlier, it's the string returned from the reverse DNS lookup that needs to be matched. So, to make a long story short, if you log into the server from the client and do who am i, you will get the host name you need for the share. Another test (for a server configured as a DNS client, LDAP would be different) is to run 'nslookup client-ip' (or the dig equivalent.) The name returned is the one that needs to be in the share config. -Kyle Rob T ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
In /etc/hosts for the format is IP FQDN Alias... Which would means 1.1.1.1 aserver.google.com aserver aserver-le0 I have seen a lot of sysadmins do the following: 1.1.1.1 aserver aserver.google.com which means the host file (or NIS) does not match DNS As the first entry is FQDN it is then name return when an application looks up an IP address. In the first example 1.1.1.1 belongs to aserver.google.com (FQDN) and access lists need to match this (e.g. .rhost/nfs shares) e.g. dig -x 1.1.1.1 | egrep PTR And it will return FQDN for example aserver.google.com (assuming a standard DNS setup) These days I am a fan for forward check access lists, because any one who owns a DNS server can say that for IPAddressX returns aserver.google.com. They can not set the forward lookup outside of their domain but they can setup a reverse lookup. The other advantage is forword looking access lists is you can use DNS Alias in access lists as well. e.g. NFS share should do a DNS lookup on aserver.google.com get an IP Address or multiple IP Address and then check to see if the client has the same IP address rather than a string match. PS I read in the doco that as of Solaris 10 hostname should be set to FQDN if you wish to use Kerb5. e.g. hostname command should return aserver.google.com.au not aserver if you wish to use Kerb5 Sol10. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
These days I am a fan for forward check access lists, because any one who owns a DNS server can say that for IPAddressX returns aserver.google.com. They can not set the forward lookup outside of their domain but they can setup a reverse lookup. The other advantage is forword looking access lists is you can use DNS Alias in access lists as well. That is not true, you have to have a valid A record in the correct domain. This is how it works (and how you should check you reverse lookups in your applications): 1. Do a reverse lookup. 2. Do a lookup with the name from 1. 3. Check that the IP address is one of the adresses you got in 2. Ignore the reverse lookup if the check in 3 fails. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] sharenfs option rw,root=host1 don't take effect
Hi All, I had create a ZFS filesystem test and shared it with zfs set sharenfs=root=host1 test, and I checked the sharenfs option and it already update to root=host1: bash-3.00# zfs get sharenfs test - NAME PROPERTY VALUESOURCE test sharenfs rw,root=host local - and NFS command share show it already shared as rw,root=host1 also: - bash-3.00# share - /test sec=sys,rw,root=host1 - But at host1, after I mounted this filesystem and tried to do some write operation at it, it still return permission denied: - bash-3.00# touch ll touch: cannot create ll: Permission denied - Thanks for any reply. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
Hi All, I had create a ZFS filesystem test and shared it with zfs set sharenfs=root=host1 test, and I checked the sharenfs option and it already update to root=host1: Try to use a backslash to escape those special chars like so : zfs set sharenfs=nosub\,nosuid\,rw\=hostname1\:hostname2\,root\=hostname2 zpoolname/zfsname/pathname Dennis ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] sharenfs option rw,root=host1 don't take effect
And I update the sharenfs option with rw,ro...@100.198.100.0/24, it works fine, and the NFS client can do the write without error. Thanks. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
