Project

General

Profile

Actions

Bug #1592

closed

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

Added by Yuri Pankov about 10 years ago. Updated about 10 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:
Gerrit CR:

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 subnetsResolvedYuri Pankov2011-04-03

Actions
Actions #1

Updated by Rich Lowe about 10 years ago

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

Resolved in r13500 commit:f077aa5fa57c

Actions

Also available in: Atom PDF