access.2: Fix outdated NFS information

Note that NFS versions since version 3 support an "access" call
so that the client doesn't have to guess permissions or ID
mapping on its own.

(See RFC 1813 sections 1.7 and 3.3.4.)

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
J. Bruce Fields 2013-09-11 16:22:11 -04:00 committed by Michael Kerrisk
parent 464e572e99
commit 1a7d4eb74c
1 changed files with 4 additions and 3 deletions

View File

@ -40,7 +40,7 @@
.\" Modified 2004-06-23 by Michael Kerrisk
.\" 2007-06-10, mtk, various parts rewritten, and added BUGS section.
.\"
.TH ACCESS 2 2013-04-16 "Linux" "Linux Programmer's Manual"
.TH ACCESS 2 2013-09-13 "Linux" "Linux Programmer's Manual"
.SH NAME
access \- check real user's permissions for a file
.SH SYNOPSIS
@ -209,9 +209,10 @@ Similarly, a DOS file may be found to be "executable," but the
call will still fail.
.PP
.BR access ()
may not work correctly on NFS filesystems with UID mapping enabled,
may not work correctly on NFSv2 filesystems with UID mapping enabled,
because UID mapping is done on the server and hidden from the client,
which checks permissions.
which checks permissions. (NFS versions 3 and higher perform the check on
the server.)
Similar problems can occur to FUSE mounts.
.SH BUGS
In kernel 2.4 (and earlier) there is some strangeness in the handling of