zfs discuss - Mar 2010 - 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  VALUE            SOURCE
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

> 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

And I update the sharenfs option with "rw,root=@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

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,root=@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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Tue, 2010-03-09 at 20:47 -0800, mingli wrote:
> And I update the sharenfs option with
"rw,root=@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

"Andrew Daugherity" <adaugherity at tamu.edu> writes:
>> And I update the sharenfs option with
"rw,root=@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,root=@198.xxx.xxx.xxx,USERNAME=@192.xxx.xxx.101

or do you have to add the rw, for each one too:
sharenfs=on,rw,root=@198.xxx.xxx.xxx,rw,USERNAME=@192.xxx.xxx.102

Is any of that syntax right?

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,root=@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.

>>>>> "ea" == erik ableson <eableson at me.com>
writes:
>>>>> "dc" == Dennis Clarke <dclarke at
blastwave.org> writes:
     >> "rw,root=@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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100310/10a86cbd/attachment.bin>

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

>>>>>> "ea" == erik ableson <eableson at
me.com> writes:
>>>>>> "dc" == Dennis Clarke <dclarke at
blastwave.org> writes:
>
>      >> "rw,root=@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

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.

>>>>> "dc" == Dennis Clarke <dclarke at
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100310/5f512c00/attachment.bin>

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 at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

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

> 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.

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

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

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

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

>>>>> "rs" == Ragnar Sundblad <ragge at
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100408/bcb1a930/attachment.bin>

mingli <liming700 at 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  on        local

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.

On 8 apr 2010, at 23.21, Miles Nordin wrote:
>>>>>> "rs" == Ragnar Sundblad <ragge at
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