NFSv4 Questions

[Robert Simmons]

I've been digging and digging to find sources to clarify the
exports(5) man page with no luck.  What I have read differs from what
I see on my server.  From the man page examples section:

V4: /   -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0

Now, here is what I have put as an experiment to try to understand
what's happening here (my /etc/exports):

V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
/

In this case, -sec=krb5 is totally ignored.  I can mount / using sys.

If I use this:

V4: /
/ -sec=krb5

It requires proper kerberos authentication.

My next question is can I reject NFSv3/v2 clients/connections?

Third question is: how can I disable rpcbind?  It seems that the
following does not work in rc.conf:
rpcbind_enable="NO"
When I'm running NFSv4 rpcbind is not needed, but it seems that mountd
always starts rpcbind no matter what I do:
/etc/rc.d/rpcbind stop
is the only way to do it, and that is only after boot, or mountd starting.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Robert Simmons wrote:

> I've been digging and digging to find sources to clarify the
> exports(5) man page with no luck. What I have read differs from what
> I see on my server. From the man page examples section:
>
> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
>
> Now, here is what I have put as an experiment to try to understand
> what's happening here (my /etc/exports):
>
> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
> /
>
> In this case, -sec=krb5 is totally ignored. I can mount / using sys.
>

The "-sec=krb5" restriction applies to state related operations that don't
use file handles.
The FreeBSD mount doesn't do any of those, so it is the options on the second line
"/" that control whether or not the mount succeeds.

With the above exports, the first Open of a file should fail when attempted via auth_sys,
at least for the FreeBSD client. (The FreeBSD client doesn't try and establish
state via SetClientID until the first Open. Some other clients do so at mount time.)

I know this is ugly, but I thought it would be confusing to have the semantics
of the other export lines (like "/") different for NFSv4 than NFSv2,3. For NFSv2,3
all RPCs involve a file handle, so they can be associated with a server volume.
For NFSv4, this is not the case, since some state related operations
(SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) do not use
a file handle and, as such, can't be associated with an exported volume. I put
the options in the "V4:" for those, since I couldn't think of where else to put
them.

> If I use this:
>
> V4: /
> / -sec=krb5
>
> It requires proper kerberos authentication.
>
Yep, as explained above. If you really want to restrict NFSv4 use to kerberos,
then you should put the "-sec=krb5" on the V4: line and all lines exporting
volumes. For example:
V4: / -sec=krb5
/ -sec=krb5

> My next question is can I reject NFSv3/v2 clients/connections?
>
sysctl vfs.nfsd.server_min_nfsvers=4

> Third question is: how can I disable rpcbind? It seems that the
> following does not work in rc.conf:
> rpcbind_enable="NO"
> When I'm running NFSv4 rpcbind is not needed, but it seems that mountd
> always starts rpcbind no matter what I do:
> /etc/rc.d/rpcbind stop
> is the only way to do it, and that is only after boot, or mountd
> starting.
> _
Yea, I suppose there should be a -nfsv4-only option on mountd, so it
knows that it only needs to do exports and doesn't need rpcbind.
Since you are probably the first person wanting an NFSv4 only server,
I hadn't thought to do this. I'll put it on my "to do" list.

Thanks for the comments, rick
> ______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Robert Simmons]

On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <[hidden email]> wrote:

> Robert Simmons wrote:
>> I've been digging and digging to find sources to clarify the
>> exports(5) man page with no luck. What I have read differs from what
>> I see on my server. From the man page examples section:
>>
>> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
>>
>> Now, here is what I have put as an experiment to try to understand
>> what's happening here (my /etc/exports):
>>
>> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
>> /
>>
>> In this case, -sec=krb5 is totally ignored. I can mount / using sys.
>>
> The "-sec=krb5" restriction applies to state related operations that don't
> use file handles.
> The FreeBSD mount doesn't do any of those, so it is the options on the second line
> "/" that control whether or not the mount succeeds.
>
> With the above exports, the first Open of a file should fail when attempted via auth_sys,
> at least for the FreeBSD client. (The FreeBSD client doesn't try and establish
> state via SetClientID until the first Open. Some other clients do so at mount time.)
>
> I know this is ugly, but I thought it would be confusing to have the semantics
> of the other export lines (like "/") different for NFSv4 than NFSv2,3. For NFSv2,3
> all RPCs involve a file handle, so they can be associated with a server volume.
> For NFSv4, this is not the case, since some state related operations
> (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) do not use
> a file handle and, as such, can't be associated with an exported volume. I put
> the options in the "V4:" for those, since I couldn't think of where else to put
> them.

I think a rewrite of exports(5) might help out quite a lot.
Especially if the EXAMPLES section was scrapped entirely and replaced
with a set of examples each one more granular in explaining one
feature or use case instead of lumping all of it into explaining one
huge export file.

Since I'm working on setting up a pair of NFS servers with a set of
clients, I volunteer.  May I contact you offlist if I have questions?

>> If I use this:
>>
>> V4: /
>> / -sec=krb5
>>
>> It requires proper kerberos authentication.
>>
> Yep, as explained above. If you really want to restrict NFSv4 use to kerberos,
> then you should put the "-sec=krb5" on the V4: line and all lines exporting
> volumes. For example:
> V4: / -sec=krb5
> / -sec=krb5

Got it.

>> My next question is can I reject NFSv3/v2 clients/connections?
>>
> sysctl vfs.nfsd.server_min_nfsvers=4

Perfect.

>> Third question is: how can I disable rpcbind? It seems that the
>> following does not work in rc.conf:
>> rpcbind_enable="NO"
>> When I'm running NFSv4 rpcbind is not needed, but it seems that mountd
>> always starts rpcbind no matter what I do:
>> /etc/rc.d/rpcbind stop
>> is the only way to do it, and that is only after boot, or mountd
>> starting.
>> _
> Yea, I suppose there should be a -nfsv4-only option on mountd, so it
> knows that it only needs to do exports and doesn't need rpcbind.
> Since you are probably the first person wanting an NFSv4 only server,
> I hadn't thought to do this. I'll put it on my "to do" list.

If I may, perhaps a switch in /etc/rc.conf:
nfsv4_only="YES"

This would set the -nfsv4-only switch you mention for mountd, and it
would set vfs.nfsd.server_min_nfsvers=4

This would be exactly what I'm looking for.

Thanks for your help!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Robert Simmons wrote:

> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <[hidden email]>
> wrote:
> > Robert Simmons wrote:
> >> I've been digging and digging to find sources to clarify the
> >> exports(5) man page with no luck. What I have read differs from
> >> what
> >> I see on my server. From the man page examples section:
> >>
> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
> >>
> >> Now, here is what I have put as an experiment to try to understand
> >> what's happening here (my /etc/exports):
> >>
> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
> >> /
> >>
> >> In this case, -sec=krb5 is totally ignored. I can mount / using
> >> sys.
> >>
> > The "-sec=krb5" restriction applies to state related operations that
> > don't
> > use file handles.
> > The FreeBSD mount doesn't do any of those, so it is the options on
> > the second line
> > "/" that control whether or not the mount succeeds.
> >
> > With the above exports, the first Open of a file should fail when
> > attempted via auth_sys,
> > at least for the FreeBSD client. (The FreeBSD client doesn't try and
> > establish
> > state via SetClientID until the first Open. Some other clients do so
> > at mount time.)
> >
> > I know this is ugly, but I thought it would be confusing to have the
> > semantics
> > of the other export lines (like "/") different for NFSv4 than
> > NFSv2,3. For NFSv2,3
> > all RPCs involve a file handle, so they can be associated with a
> > server volume.
> > For NFSv4, this is not the case, since some state related operations
> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others)
> > do not use
> > a file handle and, as such, can't be associated with an exported
> > volume. I put
> > the options in the "V4:" for those, since I couldn't think of where
> > else to put
> > them.
>
> I think a rewrite of exports(5) might help out quite a lot.
> Especially if the EXAMPLES section was scrapped entirely and replaced
> with a set of examples each one more granular in explaining one
> feature or use case instead of lumping all of it into explaining one
> huge export file.
>
> Since I'm working on setting up a pair of NFS servers with a set of
> clients, I volunteer. May I contact you offlist if I have questions?
>

Sure. However, I'd suggest that you get others to review it as well, since
I kinda know how it works and won't spot "missing bits", although I should
be able to catch most inaccuracies.

Also, be sure to check "man nfsv4" and maybe reference it (it is currently
in the See Also list, but that might not be strong enough).

> >> If I use this:
> >>
> >> V4: /
> >> / -sec=krb5
> >>
> >> It requires proper kerberos authentication.
> >>
> > Yep, as explained above. If you really want to restrict NFSv4 use to
> > kerberos,
> > then you should put the "-sec=krb5" on the V4: line and all lines
> > exporting
> > volumes. For example:
> > V4: / -sec=krb5
> > / -sec=krb5
>
> Got it.
>
> >> My next question is can I reject NFSv3/v2 clients/connections?
> >>
> > sysctl vfs.nfsd.server_min_nfsvers=4
>
> Perfect.
>
> >> Third question is: how can I disable rpcbind? It seems that the
> >> following does not work in rc.conf:
> >> rpcbind_enable="NO"
> >> When I'm running NFSv4 rpcbind is not needed, but it seems that
> >> mountd
> >> always starts rpcbind no matter what I do:
> >> /etc/rc.d/rpcbind stop
> >> is the only way to do it, and that is only after boot, or mountd
> >> starting.
> >> _
> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it
> > knows that it only needs to do exports and doesn't need rpcbind.
> > Since you are probably the first person wanting an NFSv4 only
> > server,
> > I hadn't thought to do this. I'll put it on my "to do" list.
>
> If I may, perhaps a switch in /etc/rc.conf:
> nfsv4_only="YES"
>

I might call it nfsv4_server_only, but sounds like a good suggestion.

> This would set the -nfsv4-only switch you mention for mountd, and it
> would set vfs.nfsd.server_min_nfsvers=4
>
It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind".

Have fun with it, rick

> This would be exactly what I'm looking for.
>
> Thanks for your help!
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Robert Simmons]

On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem <[hidden email]> wrote:

> Robert Simmons wrote:
>> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <[hidden email]>
>> wrote:
>> > Robert Simmons wrote:
>> >> I've been digging and digging to find sources to clarify the
>> >> exports(5) man page with no luck. What I have read differs from
>> >> what
>> >> I see on my server. From the man page examples section:
>> >>
>> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
>> >>
>> >> Now, here is what I have put as an experiment to try to understand
>> >> what's happening here (my /etc/exports):
>> >>
>> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
>> >> /
>> >>
>> >> In this case, -sec=krb5 is totally ignored. I can mount / using
>> >> sys.
>> >>
>> > The "-sec=krb5" restriction applies to state related operations that
>> > don't
>> > use file handles.
>> > The FreeBSD mount doesn't do any of those, so it is the options on
>> > the second line
>> > "/" that control whether or not the mount succeeds.
>> >
>> > With the above exports, the first Open of a file should fail when
>> > attempted via auth_sys,
>> > at least for the FreeBSD client. (The FreeBSD client doesn't try and
>> > establish
>> > state via SetClientID until the first Open. Some other clients do so
>> > at mount time.)
>> >
>> > I know this is ugly, but I thought it would be confusing to have the
>> > semantics
>> > of the other export lines (like "/") different for NFSv4 than
>> > NFSv2,3. For NFSv2,3
>> > all RPCs involve a file handle, so they can be associated with a
>> > server volume.
>> > For NFSv4, this is not the case, since some state related operations
>> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others)
>> > do not use
>> > a file handle and, as such, can't be associated with an exported
>> > volume. I put
>> > the options in the "V4:" for those, since I couldn't think of where
>> > else to put
>> > them.
>>
>> I think a rewrite of exports(5) might help out quite a lot.
>> Especially if the EXAMPLES section was scrapped entirely and replaced
>> with a set of examples each one more granular in explaining one
>> feature or use case instead of lumping all of it into explaining one
>> huge export file.
>>
>> Since I'm working on setting up a pair of NFS servers with a set of
>> clients, I volunteer. May I contact you offlist if I have questions?
>>
> Sure. However, I'd suggest that you get others to review it as well, since
> I kinda know how it works and won't spot "missing bits", although I should
> be able to catch most inaccuracies.
>
> Also, be sure to check "man nfsv4" and maybe reference it (it is currently
> in the See Also list, but that might not be strong enough).

Understood.

>> >> If I use this:
>> >>
>> >> V4: /
>> >> / -sec=krb5
>> >>
>> >> It requires proper kerberos authentication.
>> >>
>> > Yep, as explained above. If you really want to restrict NFSv4 use to
>> > kerberos,
>> > then you should put the "-sec=krb5" on the V4: line and all lines
>> > exporting
>> > volumes. For example:
>> > V4: / -sec=krb5
>> > / -sec=krb5
>>
>> Got it.
>>
>> >> My next question is can I reject NFSv3/v2 clients/connections?
>> >>
>> > sysctl vfs.nfsd.server_min_nfsvers=4
>>
>> Perfect.
>>
>> >> Third question is: how can I disable rpcbind? It seems that the
>> >> following does not work in rc.conf:
>> >> rpcbind_enable="NO"
>> >> When I'm running NFSv4 rpcbind is not needed, but it seems that
>> >> mountd
>> >> always starts rpcbind no matter what I do:
>> >> /etc/rc.d/rpcbind stop
>> >> is the only way to do it, and that is only after boot, or mountd
>> >> starting.
>> >> _
>> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it
>> > knows that it only needs to do exports and doesn't need rpcbind.
>> > Since you are probably the first person wanting an NFSv4 only
>> > server,
>> > I hadn't thought to do this. I'll put it on my "to do" list.
>>
>> If I may, perhaps a switch in /etc/rc.conf:
>> nfsv4_only="YES"
>>
> I might call it nfsv4_server_only, but sounds like a good suggestion.
>
>> This would set the -nfsv4-only switch you mention for mountd, and it
>> would set vfs.nfsd.server_min_nfsvers=4
>>
> It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind".
>
> Have fun with it, rick

Another thing to note about the behavior of mountd and the
instructions in nfsv4(4):
The three recommended lines to add to rc.conf are:
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"

With only these three, if you change something in /etc/exports and
want to kick mountd to have it reread the file, you get the following
error:
Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or
use 'onerestart' instead of 'restart'.

Would there be a drawback to suggesting setting mountd_enable in man
page to avoid this?  In other words, is there a reason this is setup
this way?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Robert Simmons wrote:

> On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem <[hidden email]>
> wrote:
> > Robert Simmons wrote:
> >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem
> >> <[hidden email]>
> >> wrote:
> >> > Robert Simmons wrote:
> >> >> I've been digging and digging to find sources to clarify the
> >> >> exports(5) man page with no luck. What I have read differs from
> >> >> what
> >> >> I see on my server. From the man page examples section:
> >> >>
> >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask
> >> >> 255.255.255.0
> >> >>
> >> >> Now, here is what I have put as an experiment to try to
> >> >> understand
> >> >> what's happening here (my /etc/exports):
> >> >>
> >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
> >> >> /
> >> >>
> >> >> In this case, -sec=krb5 is totally ignored. I can mount / using
> >> >> sys.
> >> >>
> >> > The "-sec=krb5" restriction applies to state related operations
> >> > that
> >> > don't
> >> > use file handles.
> >> > The FreeBSD mount doesn't do any of those, so it is the options
> >> > on
> >> > the second line
> >> > "/" that control whether or not the mount succeeds.
> >> >
> >> > With the above exports, the first Open of a file should fail when
> >> > attempted via auth_sys,
> >> > at least for the FreeBSD client. (The FreeBSD client doesn't try
> >> > and
> >> > establish
> >> > state via SetClientID until the first Open. Some other clients do
> >> > so
> >> > at mount time.)
> >> >
> >> > I know this is ugly, but I thought it would be confusing to have
> >> > the
> >> > semantics
> >> > of the other export lines (like "/") different for NFSv4 than
> >> > NFSv2,3. For NFSv2,3
> >> > all RPCs involve a file handle, so they can be associated with a
> >> > server volume.
> >> > For NFSv4, this is not the case, since some state related
> >> > operations
> >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of
> >> > others)
> >> > do not use
> >> > a file handle and, as such, can't be associated with an exported
> >> > volume. I put
> >> > the options in the "V4:" for those, since I couldn't think of
> >> > where
> >> > else to put
> >> > them.
> >>
> >> I think a rewrite of exports(5) might help out quite a lot.
> >> Especially if the EXAMPLES section was scrapped entirely and
> >> replaced
> >> with a set of examples each one more granular in explaining one
> >> feature or use case instead of lumping all of it into explaining
> >> one
> >> huge export file.
> >>
> >> Since I'm working on setting up a pair of NFS servers with a set of
> >> clients, I volunteer. May I contact you offlist if I have
> >> questions?
> >>
> > Sure. However, I'd suggest that you get others to review it as well,
> > since
> > I kinda know how it works and won't spot "missing bits", although I
> > should
> > be able to catch most inaccuracies.
> >
> > Also, be sure to check "man nfsv4" and maybe reference it (it is
> > currently
> > in the See Also list, but that might not be strong enough).
>
> Understood.
>
> >> >> If I use this:
> >> >>
> >> >> V4: /
> >> >> / -sec=krb5
> >> >>
> >> >> It requires proper kerberos authentication.
> >> >>
> >> > Yep, as explained above. If you really want to restrict NFSv4 use
> >> > to
> >> > kerberos,
> >> > then you should put the "-sec=krb5" on the V4: line and all lines
> >> > exporting
> >> > volumes. For example:
> >> > V4: / -sec=krb5
> >> > / -sec=krb5
> >>
> >> Got it.
> >>
> >> >> My next question is can I reject NFSv3/v2 clients/connections?
> >> >>
> >> > sysctl vfs.nfsd.server_min_nfsvers=4
> >>
> >> Perfect.
> >>
> >> >> Third question is: how can I disable rpcbind? It seems that the
> >> >> following does not work in rc.conf:
> >> >> rpcbind_enable="NO"
> >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that
> >> >> mountd
> >> >> always starts rpcbind no matter what I do:
> >> >> /etc/rc.d/rpcbind stop
> >> >> is the only way to do it, and that is only after boot, or mountd
> >> >> starting.
> >> >> _
> >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so
> >> > it
> >> > knows that it only needs to do exports and doesn't need rpcbind.
> >> > Since you are probably the first person wanting an NFSv4 only
> >> > server,
> >> > I hadn't thought to do this. I'll put it on my "to do" list.
> >>
> >> If I may, perhaps a switch in /etc/rc.conf:
> >> nfsv4_only="YES"
> >>
> > I might call it nfsv4_server_only, but sounds like a good
> > suggestion.
> >
> >> This would set the -nfsv4-only switch you mention for mountd, and
> >> it
> >> would set vfs.nfsd.server_min_nfsvers=4
> >>
> > It could also be used by /etc/rc.d/mountd to indicate "don't force
> > rpcbind".
> >
> > Have fun with it, rick
>
> Another thing to note about the behavior of mountd and the
> instructions in nfsv4(4):
> The three recommended lines to add to rc.conf are:
> nfs_server_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
>
> With only these three, if you change something in /etc/exports and
> want to kick mountd to have it reread the file, you get the following
> error:
> Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or
> use 'onerestart' instead of 'restart'.
>
> Would there be a drawback to suggesting setting mountd_enable in man
> page to avoid this? In other words, is there a reason this is setup
> this way?

Nope. Adding mountd_enable="YES" would be fine, as far as I know.
(I never use the scripts to kill/restart stuff.)

rick

> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[clutton]

All your thought was interesting.
I also had all those problem (exports, rpcbind, sysctl).
But now, I work with third version, because I need working amd(8).
Does anyone has suggestion how make it work with nfsv4?



On Sun, 2012-04-29 at 17:23 -0400, Robert Simmons wrote:

> On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem <[hidden email]> wrote:
> > Robert Simmons wrote:
> >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <[hidden email]>
> >> wrote:
> >> > Robert Simmons wrote:
> >> >> I've been digging and digging to find sources to clarify the
> >> >> exports(5) man page with no luck. What I have read differs from
> >> >> what
> >> >> I see on my server. From the man page examples section:
> >> >>
> >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
> >> >>
> >> >> Now, here is what I have put as an experiment to try to understand
> >> >> what's happening here (my /etc/exports):
> >> >>
> >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
> >> >> /
> >> >>
> >> >> In this case, -sec=krb5 is totally ignored. I can mount / using
> >> >> sys.
> >> >>
> >> > The "-sec=krb5" restriction applies to state related operations that
> >> > don't
> >> > use file handles.
> >> > The FreeBSD mount doesn't do any of those, so it is the options on
> >> > the second line
> >> > "/" that control whether or not the mount succeeds.
> >> >
> >> > With the above exports, the first Open of a file should fail when
> >> > attempted via auth_sys,
> >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and
> >> > establish
> >> > state via SetClientID until the first Open. Some other clients do so
> >> > at mount time.)
> >> >
> >> > I know this is ugly, but I thought it would be confusing to have the
> >> > semantics
> >> > of the other export lines (like "/") different for NFSv4 than
> >> > NFSv2,3. For NFSv2,3
> >> > all RPCs involve a file handle, so they can be associated with a
> >> > server volume.
> >> > For NFSv4, this is not the case, since some state related operations
> >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others)
> >> > do not use
> >> > a file handle and, as such, can't be associated with an exported
> >> > volume. I put
> >> > the options in the "V4:" for those, since I couldn't think of where
> >> > else to put
> >> > them.
> >>
> >> I think a rewrite of exports(5) might help out quite a lot.
> >> Especially if the EXAMPLES section was scrapped entirely and replaced
> >> with a set of examples each one more granular in explaining one
> >> feature or use case instead of lumping all of it into explaining one
> >> huge export file.
> >>
> >> Since I'm working on setting up a pair of NFS servers with a set of
> >> clients, I volunteer. May I contact you offlist if I have questions?
> >>
> > Sure. However, I'd suggest that you get others to review it as well, since
> > I kinda know how it works and won't spot "missing bits", although I should
> > be able to catch most inaccuracies.
> >
> > Also, be sure to check "man nfsv4" and maybe reference it (it is currently
> > in the See Also list, but that might not be strong enough).
>
> Understood.
>
> >> >> If I use this:
> >> >>
> >> >> V4: /
> >> >> / -sec=krb5
> >> >>
> >> >> It requires proper kerberos authentication.
> >> >>
> >> > Yep, as explained above. If you really want to restrict NFSv4 use to
> >> > kerberos,
> >> > then you should put the "-sec=krb5" on the V4: line and all lines
> >> > exporting
> >> > volumes. For example:
> >> > V4: / -sec=krb5
> >> > / -sec=krb5
> >>
> >> Got it.
> >>
> >> >> My next question is can I reject NFSv3/v2 clients/connections?
> >> >>
> >> > sysctl vfs.nfsd.server_min_nfsvers=4
> >>
> >> Perfect.
> >>
> >> >> Third question is: how can I disable rpcbind? It seems that the
> >> >> following does not work in rc.conf:
> >> >> rpcbind_enable="NO"
> >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that
> >> >> mountd
> >> >> always starts rpcbind no matter what I do:
> >> >> /etc/rc.d/rpcbind stop
> >> >> is the only way to do it, and that is only after boot, or mountd
> >> >> starting.
> >> >> _
> >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it
> >> > knows that it only needs to do exports and doesn't need rpcbind.
> >> > Since you are probably the first person wanting an NFSv4 only
> >> > server,
> >> > I hadn't thought to do this. I'll put it on my "to do" list.
> >>
> >> If I may, perhaps a switch in /etc/rc.conf:
> >> nfsv4_only="YES"
> >>
> > I might call it nfsv4_server_only, but sounds like a good suggestion.
> >
> >> This would set the -nfsv4-only switch you mention for mountd, and it
> >> would set vfs.nfsd.server_min_nfsvers=4
> >>
> > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind".
> >
> > Have fun with it, rick
>
> Another thing to note about the behavior of mountd and the
> instructions in nfsv4(4):
> The three recommended lines to add to rc.conf are:
> nfs_server_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
>
> With only these three, if you change something in /etc/exports and
> want to kick mountd to have it reread the file, you get the following
> error:
> Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or
> use 'onerestart' instead of 'restart'.
>
> Would there be a drawback to suggesting setting mountd_enable in man
> page to avoid this?  In other words, is there a reason this is setup
> this way?
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"

[clutton]

All your thoughts were interesting.
I also had all those problems (exports, rpcbind, sysctl).
But now, I work with third version, because I need working amd(8).
Does anyone has suggestion how make it work with nfsv4?



On Sun, 2012-04-29 at 17:23 -0400, Robert Simmons wrote:

> On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem <[hidden email]> wrote:
> > Robert Simmons wrote:
> >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem <[hidden email]>
> >> wrote:
> >> > Robert Simmons wrote:
> >> >> I've been digging and digging to find sources to clarify the
> >> >> exports(5) man page with no luck. What I have read differs from
> >> >> what
> >> >> I see on my server. From the man page examples section:
> >> >>
> >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0
> >> >>
> >> >> Now, here is what I have put as an experiment to try to understand
> >> >> what's happening here (my /etc/exports):
> >> >>
> >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0
> >> >> /
> >> >>
> >> >> In this case, -sec=krb5 is totally ignored. I can mount / using
> >> >> sys.
> >> >>
> >> > The "-sec=krb5" restriction applies to state related operations that
> >> > don't
> >> > use file handles.
> >> > The FreeBSD mount doesn't do any of those, so it is the options on
> >> > the second line
> >> > "/" that control whether or not the mount succeeds.
> >> >
> >> > With the above exports, the first Open of a file should fail when
> >> > attempted via auth_sys,
> >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and
> >> > establish
> >> > state via SetClientID until the first Open. Some other clients do so
> >> > at mount time.)
> >> >
> >> > I know this is ugly, but I thought it would be confusing to have the
> >> > semantics
> >> > of the other export lines (like "/") different for NFSv4 than
> >> > NFSv2,3. For NFSv2,3
> >> > all RPCs involve a file handle, so they can be associated with a
> >> > server volume.
> >> > For NFSv4, this is not the case, since some state related operations
> >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others)
> >> > do not use
> >> > a file handle and, as such, can't be associated with an exported
> >> > volume. I put
> >> > the options in the "V4:" for those, since I couldn't think of where
> >> > else to put
> >> > them.
> >>
> >> I think a rewrite of exports(5) might help out quite a lot.
> >> Especially if the EXAMPLES section was scrapped entirely and replaced
> >> with a set of examples each one more granular in explaining one
> >> feature or use case instead of lumping all of it into explaining one
> >> huge export file.
> >>
> >> Since I'm working on setting up a pair of NFS servers with a set of
> >> clients, I volunteer. May I contact you offlist if I have questions?
> >>
> > Sure. However, I'd suggest that you get others to review it as well, since
> > I kinda know how it works and won't spot "missing bits", although I should
> > be able to catch most inaccuracies.
> >
> > Also, be sure to check "man nfsv4" and maybe reference it (it is currently
> > in the See Also list, but that might not be strong enough).
>
> Understood.
>
> >> >> If I use this:
> >> >>
> >> >> V4: /
> >> >> / -sec=krb5
> >> >>
> >> >> It requires proper kerberos authentication.
> >> >>
> >> > Yep, as explained above. If you really want to restrict NFSv4 use to
> >> > kerberos,
> >> > then you should put the "-sec=krb5" on the V4: line and all lines
> >> > exporting
> >> > volumes. For example:
> >> > V4: / -sec=krb5
> >> > / -sec=krb5
> >>
> >> Got it.
> >>
> >> >> My next question is can I reject NFSv3/v2 clients/connections?
> >> >>
> >> > sysctl vfs.nfsd.server_min_nfsvers=4
> >>
> >> Perfect.
> >>
> >> >> Third question is: how can I disable rpcbind? It seems that the
> >> >> following does not work in rc.conf:
> >> >> rpcbind_enable="NO"
> >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that
> >> >> mountd
> >> >> always starts rpcbind no matter what I do:
> >> >> /etc/rc.d/rpcbind stop
> >> >> is the only way to do it, and that is only after boot, or mountd
> >> >> starting.
> >> >> _
> >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it
> >> > knows that it only needs to do exports and doesn't need rpcbind.
> >> > Since you are probably the first person wanting an NFSv4 only
> >> > server,
> >> > I hadn't thought to do this. I'll put it on my "to do" list.
> >>
> >> If I may, perhaps a switch in /etc/rc.conf:
> >> nfsv4_only="YES"
> >>
> > I might call it nfsv4_server_only, but sounds like a good suggestion.
> >
> >> This would set the -nfsv4-only switch you mention for mountd, and it
> >> would set vfs.nfsd.server_min_nfsvers=4
> >>
> > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind".
> >
> > Have fun with it, rick
>
> Another thing to note about the behavior of mountd and the
> instructions in nfsv4(4):
> The three recommended lines to add to rc.conf are:
> nfs_server_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
>
> With only these three, if you change something in /etc/exports and
> want to kick mountd to have it reread the file, you get the following
> error:
> Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or
> use 'onerestart' instead of 'restart'.
>
> Would there be a drawback to suggesting setting mountd_enable in man
> page to avoid this?  In other words, is there a reason this is setup
> this way?
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"

[Andrey Simonenko]

On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote:
>
> Also, be sure to check "man nfsv4" and maybe reference it (it is currently
> in the See Also list, but that might not be strong enough).

There is another question not explained in documentation (I could not
find the answer at least).  Currently NFSv3 client uses reserved port
for NFS mounts and uses non reserved port if "noresvport" is specified.
NFSv4 client always uses non reserved port, ignoring the "resvport"
option in the mount_nfs command.

Such behaviour of NFS client was introduced in 1.18 version of
fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is cleared
for NFSv4 mounts.

Why does "reserved port logic" differ in NFSv3 and NFSv4 clients?

> > If I may, perhaps a switch in /etc/rc.conf:
> > nfsv4_only="YES"
> >
> I might call it nfsv4_server_only, but sounds like a good suggestion.
>
> > This would set the -nfsv4-only switch you mention for mountd, and it
> > would set vfs.nfsd.server_min_nfsvers=4
> >
> It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind".
>

I'm sure that you know all these, but let me add some comments.

1. Using server_min_nfsvers and server_max_nfsvers are global settings
   and do not allow to make one file system NFSv2/3/4 exported and another
   one NFSv4 exported only for example.

2. MOUNT protocol is not used only for MNT/UMNT/UMNTALL requests from
   NFSv2/3 clients.  As I know some automounters use MOUNT EXPORT requests
   to get information about exported file systems.  So, MOUNT protocol
   can be usefull for somebody who uses NFSv4 only.

Both items have something common.  There should be options that enable/
disables NFSv2, NFSv3 and/or NFSv4 per address specification and/or per
file system.  And there should be the option that allows to disable the
MOUNT protocol entirely, some of its versions or some of its netconfigs
(some of visible netconfigs that can be used by the MOUNT protocol).

[1] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nfsclient/nfs_clvfsops.c.diff?r1=1.17;r2=1.18
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Andrey Simonenko wrote:

> On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote:
> >
> > Also, be sure to check "man nfsv4" and maybe reference it (it is
> > currently
> > in the See Also list, but that might not be strong enough).
>
> There is another question not explained in documentation (I could not
> find the answer at least). Currently NFSv3 client uses reserved port
> for NFS mounts and uses non reserved port if "noresvport" is
> specified.
> NFSv4 client always uses non reserved port, ignoring the "resvport"
> option in the mount_nfs command.
>
> Such behaviour of NFS client was introduced in 1.18 version of
> fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is cleared
> for NFSv4 mounts.
>
> Why does "reserved port logic" differ in NFSv3 and NFSv4 clients?
>

It is my understanding that NFSv4 servers are not supposed to require
a "reserved" port#. However, at a quick glance, I can't find that stated
in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user" based
security model and not a "host" based one.)

As such, the client should never need to "waste" a reserved port# on a NFSv4
connection.

rick

> > > If I may, perhaps a switch in /etc/rc.conf:
> > > nfsv4_only="YES"
> > >
> > I might call it nfsv4_server_only, but sounds like a good
> > suggestion.
> >
> > > This would set the -nfsv4-only switch you mention for mountd, and
> > > it
> > > would set vfs.nfsd.server_min_nfsvers=4
> > >
> > It could also be used by /etc/rc.d/mountd to indicate "don't force
> > rpcbind".
> >
>
> I'm sure that you know all these, but let me add some comments.
>
> 1. Using server_min_nfsvers and server_max_nfsvers are global settings
> and do not allow to make one file system NFSv2/3/4 exported and
> another
> one NFSv4 exported only for example.
>
> 2. MOUNT protocol is not used only for MNT/UMNT/UMNTALL requests from
> NFSv2/3 clients. As I know some automounters use MOUNT EXPORT requests
> to get information about exported file systems. So, MOUNT protocol
> can be usefull for somebody who uses NFSv4 only.
>
> Both items have something common. There should be options that enable/
> disables NFSv2, NFSv3 and/or NFSv4 per address specification and/or
> per
> file system. And there should be the option that allows to disable the
> MOUNT protocol entirely, some of its versions or some of its
> netconfigs
> (some of visible netconfigs that can be used by the MOUNT protocol).
>
> [1]
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/nfsclient/nfs_clvfsops.c.diff?r1=1.17;r2=1.18

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Bob Friesenhahn]

On Mon, 7 May 2012, Rick Macklem wrote:
>>
> It is my understanding that NFSv4 servers are not supposed to require
> a "reserved" port#. However, at a quick glance, I can't find that stated
> in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user" based
> security model and not a "host" based one.)
>
> As such, the client should never need to "waste" a reserved port# on a NFSv4
> connection.

Firewalls might use the reserved port as part of a filtering
algorithm.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Bob Friesenhahn wrote:

> On Mon, 7 May 2012, Rick Macklem wrote:
> >>
> > It is my understanding that NFSv4 servers are not supposed to
> > require
> > a "reserved" port#. However, at a quick glance, I can't find that
> > stated
> > in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user"
> > based
> > security model and not a "host" based one.)
> >
> > As such, the client should never need to "waste" a reserved port# on
> > a NFSv4
> > connection.
>
> Firewalls might use the reserved port as part of a filtering
> algorithm.
>

Hmm, since the IETF working group was determined to "get rid of this
bunk w.r.t. reserved port #s being used to enhance security", I might
argue that said firewalls were misconfigured/broken.

However, I can see an argument that, instead of silently ignoring the
option, it should be obeyed, but with a note in the man page that it
shouldn't be used for NFSv4.

rick

> Bob
> --
> Bob Friesenhahn
> [hidden email],
> http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Andrey Simonenko]

On Mon, May 07, 2012 at 07:40:18PM -0400, Rick Macklem wrote:

> Andrey Simonenko wrote:
> > On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote:
> > >
> > > Also, be sure to check "man nfsv4" and maybe reference it (it is
> > > currently
> > > in the See Also list, but that might not be strong enough).
> >
> > There is another question not explained in documentation (I could not
> > find the answer at least). Currently NFSv3 client uses reserved port
> > for NFS mounts and uses non reserved port if "noresvport" is
> > specified.
> > NFSv4 client always uses non reserved port, ignoring the "resvport"
> > option in the mount_nfs command.
> >
> > Such behaviour of NFS client was introduced in 1.18 version of
> > fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is cleared
> > for NFSv4 mounts.
> >
> > Why does "reserved port logic" differ in NFSv3 and NFSv4 clients?
> >
> It is my understanding that NFSv4 servers are not supposed to require
> a "reserved" port#. However, at a quick glance, I can't find that stated
> in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user" based
> security model and not a "host" based one.)
>
> As such, the client should never need to "waste" a reserved port# on a NFSv4
> connection.

Since AUTH_SYS can be used in NFSv4 as well and according to RFC 3530
AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then

1. Does "user" based security model mean RPCSEC_GSS?

2. Does "host" based security model mean AUTH_SYS?

I did not find any mention about port numbers in RFC 1813 and 3530,
looks like that ports numbers range used by NFS clients and checked by
NFS server is the implementation decision.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Andrey Simonenko wrote:

> On Mon, May 07, 2012 at 07:40:18PM -0400, Rick Macklem wrote:
> > Andrey Simonenko wrote:
> > > On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote:
> > > >
> > > > Also, be sure to check "man nfsv4" and maybe reference it (it is
> > > > currently
> > > > in the See Also list, but that might not be strong enough).
> > >
> > > There is another question not explained in documentation (I could
> > > not
> > > find the answer at least). Currently NFSv3 client uses reserved
> > > port
> > > for NFS mounts and uses non reserved port if "noresvport" is
> > > specified.
> > > NFSv4 client always uses non reserved port, ignoring the
> > > "resvport"
> > > option in the mount_nfs command.
> > >
> > > Such behaviour of NFS client was introduced in 1.18 version of
> > > fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is
> > > cleared
> > > for NFSv4 mounts.
> > >
> > > Why does "reserved port logic" differ in NFSv3 and NFSv4 clients?
> > >
> > It is my understanding that NFSv4 servers are not supposed to
> > require
> > a "reserved" port#. However, at a quick glance, I can't find that
> > stated
> > in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user"
> > based
> > security model and not a "host" based one.)
> >
> > As such, the client should never need to "waste" a reserved port# on
> > a NFSv4
> > connection.
>
> Since AUTH_SYS can be used in NFSv4 as well and according to RFC 3530
> AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then
>
> 1. Does "user" based security model mean RPCSEC_GSS?
>
> 2. Does "host" based security model mean AUTH_SYS?
>

My guess is that AUTH_SYS is not considered a security model at all,
but the "authenticators" refer to users.

I believe the "host" based security model referred to in the RFCs refers
to the restrictions implemented by /etc/exports, based on client host IP
addresses.

I do remember that the IETF working group discussed "reserved port #s" and
agreed that requiring one did not enhance security and that NFSv4 servers
should not require that a client's port# be within a certain range.
(If you were to search the archive for [hidden email], it should be somewhere
 in there.)

However, I agree that this does not seem to be stated in the RFCs, because
I couldn't find it when the question came up. (It may be that IETF does not
have a definition of a "reserved port#".)

Personally, I agree with the working group and have always thought requiring
a client to use a "reserved port#" was meaningless. However, I already noted
that I don't mind enabling it, with a comment that it should not be required
for NFSv4.

> I did not find any mention about port numbers in RFC 1813 and 3530,
> looks like that ports numbers range used by NFS clients and checked by
> NFS server is the implementation decision.

During interoperability testing (I'll be at another NFSv4 Bakeathon in June)
I have never had a server that would not allow a connection to happen from
a non-reserved port# for NFSv4, so I believe that the implementation practice is to
not require it for NFSv4. (Consistent with the discussion on [hidden email].)

rick

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Andrey Simonenko]

On Thu, May 10, 2012 at 04:34:15PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:

> > > in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user"
> > > based
> > > security model and not a "host" based one.)
> > >
> > > As such, the client should never need to "waste" a reserved port# on
> > > a NFSv4
> > > connection.
> >
> > Since AUTH_SYS can be used in NFSv4 as well and according to RFC 3530
> > AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then
> >
> > 1. Does "user" based security model mean RPCSEC_GSS?
> >
> > 2. Does "host" based security model mean AUTH_SYS?
> >
> My guess is that AUTH_SYS is not considered a security model at all,
> but the "authenticators" refer to users.

Probably I wrongly asked the question.  I did not mean that some security
flavor (eg. AUTH_SYS) is a security model.  I wanted to say that NFSv4
allows to use AUTH_SYS security flavor and user credentials are given
as is by client's machine, so some form of control by client's IP address
is required by the NFSv4 server if a client uses and is allowed to use
AUTH_SYS security flavor.  Actually this is specified in "16. Security
Considerations" from RFC 3530 and AUTH_SYS in NFSv4 is called << "classic"
model of machine authentication via IP address checking >>.

What do you think about the following idea about configuration?

1. The NFS server for NFSv2/3 clients allows to specify whether their
   MOUNT MNT, UMNT and UMNTALL RPC requests have to or do not have to come
   from reserved ports.

2. The NFS server for NFSv2/3/4 clients allows to specify whether their
   NFS RPC calls:
        a) do not have to come from reserved ports
        b) always have to come from reserved ports
        c) have to come from reserved ports if clients use AUTH_SYS.

3. By default reserved ports are not required for MOUNT RPC and
   NFS RPC calls.  Corresponding options can be used for entire file
   system and/or for single address specification.

First item obviously is checked in a user space and second item is checked
in the NFS server somewhere after VFS_CHECKEXP() when the server decides
which security flavor to use.

NetBSD already has -noresvmnt and -noresvport options in their exports(5).

> Personally, I agree with the working group and have always thought requiring
> a client to use a "reserved port#" was meaningless. However, I already noted
> that I don't mind enabling it, with a comment that it should not be required
> for NFSv4.

If a client machine is trusted, then reserved ports can guaranty that
requests come from privileged processes and not from user space where
client can fill any credentials in AUTH_SYS.  If client machine is not
trusted, then this will not work of course.  BTW mountd requires reserved
port and NFS server does not required reserved port by default.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Rick Macklem]

Andrey Simonenko wrote:

> On Thu, May 10, 2012 at 04:34:15PM -0400, Rick Macklem wrote:
> > Andrey Simonenko wrote:
>
> > > > in RFC 3530. (It may be implied by the fact that NFSv4 uses a
> > > > "user"
> > > > based
> > > > security model and not a "host" based one.)
> > > >
> > > > As such, the client should never need to "waste" a reserved
> > > > port# on
> > > > a NFSv4
> > > > connection.
> > >
> > > Since AUTH_SYS can be used in NFSv4 as well and according to RFC
> > > 3530
> > > AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then
> > >
> > > 1. Does "user" based security model mean RPCSEC_GSS?
> > >
> > > 2. Does "host" based security model mean AUTH_SYS?
> > >
> > My guess is that AUTH_SYS is not considered a security model at all,
> > but the "authenticators" refer to users.
>
> Probably I wrongly asked the question. I did not mean that some
> security
> flavor (eg. AUTH_SYS) is a security model. I wanted to say that NFSv4
> allows to use AUTH_SYS security flavor and user credentials are given
> as is by client's machine, so some form of control by client's IP
> address
> is required by the NFSv4 server if a client uses and is allowed to use
> AUTH_SYS security flavor. Actually this is specified in "16. Security
> Considerations" from RFC 3530 and AUTH_SYS in NFSv4 is called <<
> "classic"
> model of machine authentication via IP address checking >>.
>
> What do you think about the following idea about configuration?
>
> 1. The NFS server for NFSv2/3 clients allows to specify whether their
> MOUNT MNT, UMNT and UMNTALL RPC requests have to or do not have to
> come
> from reserved ports.
>
> 2. The NFS server for NFSv2/3/4 clients allows to specify whether
> their
> NFS RPC calls:
> a) do not have to come from reserved ports
> b) always have to come from reserved ports
> c) have to come from reserved ports if clients use AUTH_SYS.
>
> 3. By default reserved ports are not required for MOUNT RPC and
> NFS RPC calls. Corresponding options can be used for entire file
> system and/or for single address specification.
>
> First item obviously is checked in a user space and second item is
> checked
> in the NFS server somewhere after VFS_CHECKEXP() when the server
> decides
> which security flavor to use.
>

One problem with this is that some NFSv4 operations do not have any
file handle and, as such, cannot be associated with any exported file
system. (I suppose you could add the export option for resvport to
the V4: line like I did with "-sec" for these operations, but it will
get messy.)

> NetBSD already has -noresvmnt and -noresvport options in their
> exports(5).
>
I'll let others comment w.r.t. whether they have a need for this. To me,
unless others are saying "we need this", I don't see any reason to change
what is already there, except maybe optionally require a reserved port#
for NFSv4 mounts via a sysctl. I comment on this further down.

> > Personally, I agree with the working group and have always thought
> > requiring
> > a client to use a "reserved port#" was meaningless. However, I
> > already noted
> > that I don't mind enabling it, with a comment that it should not be
> > required
> > for NFSv4.
>
> If a client machine is trusted, then reserved ports can guaranty that
> requests come from privileged processes and not from user space where
> client can fill any credentials in AUTH_SYS. If client machine is not
> trusted, then this will not work of course. BTW mountd requires
> reserved
> port and NFS server does not required reserved port by default.

Well, I agree that, if you have a client machine where "root" is secure
(no root kit vunerabilities, etc) but non-root users on this machine
would potentially run their own bogus userland NFS client, then requiring
a reserved port# does subvert the use of such a bogus NFS client.
(My concern is that some people will think that requiring a reserved port#
 makes NFS secure for other cases, like users with their own laptops/desktops.)

Personally, I think the above case is rare and that having another sysctl
vfs.nfsd.nfsv4_privport (similar to vfs.nfsd.nfs_privport) is sufficient,
but I'll let others comment on this, since it is not my decision.

rick
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"

[Andrey Simonenko]

On Fri, May 11, 2012 at 09:45:11PM -0400, Rick Macklem wrote:
> Andrey Simonenko wrote:
>
> > NetBSD already has -noresvmnt and -noresvport options in their
> > exports(5).
> >
> I'll let others comment w.r.t. whether they have a need for this. To me,
> unless others are saying "we need this", I don't see any reason to change
> what is already there, except maybe optionally require a reserved port#
> for NFSv4 mounts via a sysctl. I comment on this further down.

According to exports(5) manual page for Linux, similar option named
"secure" also exists in Linux NFS server implementation.  [1]

> > If a client machine is trusted, then reserved ports can guaranty that
> > requests come from privileged processes and not from user space where
> > client can fill any credentials in AUTH_SYS. If client machine is not
> > trusted, then this will not work of course. BTW mountd requires
> > reserved
> > port and NFS server does not required reserved port by default.
> Well, I agree that, if you have a client machine where "root" is secure
> (no root kit vunerabilities, etc) but non-root users on this machine
> would potentially run their own bogus userland NFS client, then requiring
> a reserved port# does subvert the use of such a bogus NFS client.
> (My concern is that some people will think that requiring a reserved port#
>  makes NFS secure for other cases, like users with their own laptops/desktops.)

Current implementation allows to export subdirectories to NFSv2/3 clients.
A NFSv2/3 client can guess a filehandle and access any part of exported file
system.  This is more insecure by design, than option that allows to specify
whether reserved port is required for NFS RPC requests.  Similar logic is
given in RFC2623.

> Personally, I think the above case is rare and that having another sysctl
> vfs.nfsd.nfsv4_privport (similar to vfs.nfsd.nfs_privport) is sufficient,
> but I'll let others comment on this, since it is not my decision.

Since nobody commented these ideas, I want to give description of my
implementation.  If somebody wants to do something similar for mountd,
then this description will give some information for thinking at least.

Command option for MOUNT protocol settings:

 -m mntset
         Specifies whether ... should service MOUNT protocol requests and
         what it should support from this protocol.  The argument is a
         colon separated list of values: no disables the protocol support,
         v1 supports version 1 of the protocol (used in NFSv2), v3 sup-
         ports version 3 of the protocol (used in NFSv3), udp, tcp, udp6
         and tcp6 specify which netconfig should be supported for the pro-
         tocol.  Disabling MOUNT protocol or some its version does not
         disable NFSv2/3 in the NFS server, the same logic is applied for
         disabled netconfigs.

Configuration options:

 -mnt_mount=arg1[:arg2...]
         Specify settings for MOUNT protocol's procedures MNT, UMNT and
         UMNTALL.  Available arguments are: default (set default set-
         tings), regfile (allow MNT requests for regular files), resvport
         (allow requests from reserved IP ports numbers only).  By default
         MNT requests are allowed for directories only, all requests are
         allowed from any IP port number.

 -resvport=value
         Specify whether NFS and NLM RPC requests should be received from
         sender's reserved IP port numbers (less than 1024).  Available
         arguments are: default (set default settings), always (reserved
         sender's IP port number is always required), weakauth (reserved
         sender's IP port number is required if the AUTH_SYS security fla-
         vor is used).  By default reserved sender's IP port numbers are
         not required.

Well, -resvport option does not work well for NLM RPC requests if
non-AUTH_SYS security flavor is used and user credentials on a client
differ with user credentials on a server.  But NLM does not work
in such configuration even without this options, details here [2].

[1] http://www.linuxmanpages.com/man5/exports.5.php
[2] http://lists.freebsd.org/pipermail/freebsd-fs/2012-May/014444.html
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"