Project

General

Profile

Bug #1592

NFS access checks shouldn't fail if client address can't be resolved

Added by Yuri Pankov almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
nfs - NFS server and client
Start date:
2011-10-02
Due date:
% Done:

100%

Estimated time:
Difficulty:
Bite-size
Tags:

Description

Current logic in in_access_list (http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/fs.d/nfs/mountd/mountd.c#1720) is strange - we first check if we have an "@" entry, and then return 0 (not found) if we can't resolve client address - problem is that "@" entry (not requiring client hostname) may be not the first in access list.. There are two possible solutions:

  1. do the lookup before processing access list (which is described as "costly", but the current "workaround" isn't correct)
  2. instead of return'ing just skip to next entry (but in this case we'll do the lookups over and over again)

First one seems less "costly" and matches what we have in libsmb's smb_chk_hostaccess.


Related issues

Related to illumos gate - Bug #877: share_nfs cannot share to IPv6 subnetsResolved2011-04-03

Actions

History

#1

Updated by Rich Lowe almost 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Resolved in r13500 commit:f077aa5fa57c

Also available in: Atom PDF