[OpenAFS-devel] Strange results from access(F_OK)/stat and caching

[Geoffrey Thomas]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1257051904-2053222215-1289097814=:21239
Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi,

I noticed the following behavior on OpenAFS on Linux (1.4.12+dfsg-3 on=20
Ubuntu 10.04 i386, but I've seen symptoms explainable by this behavior on=
=20
other Linux systems). Given that /mit/geofft/hello.c is in AFS and=20
system:anyuser l (not rl) and geofft rlidkwa, and I have tokens for geofft=
=20
but root does not:

geofft@white-elephant:/tmp$ cat access.c
#include <unistd.h>
main() {
         perror("access", access("/mit/geofft/hello.c", F_OK));
         return 0;
}
geofft@white-elephant:/tmp$ ./access
access: Success
geofft@white-elephant:/tmp$ sudo ./access
access: Success
geofft@white-elephant:/tmp$ fs flushv /mit/geofft/
geofft@white-elephant:/tmp$ sudo ./access
access: Permission denied
geofft@white-elephant:/tmp$ sudo stat /mit/geofft/hello.c
stat: cannot stat `/mit/geofft/hello.c': Permission denied
geofft@white-elephant:/tmp$ ./access
access: Success
geofft@white-elephant:/tmp$ sudo ./access
access: Success
geofft@white-elephant:/tmp$ sudo stat /mit/geofft/hello.c
   File: `/mit/geofft/hello.c'
   Size: 148             Blocks: 2          IO Block: 4096   regular file
Device: 16h/22d Inode: 1101648276  Links: 1
Access: (0600/-rw-------)  Uid: (40490/ UNKNOWN)   Gid: (  101/ libuuid)
Access: 2008-09-09 06:40:03.000000000 -0400
Modify: 2008-09-09 06:40:03.000000000 -0400
Change: 2008-09-09 06:40:03.000000000 -0400


In other words, access(F_OK) or stat() on a file that clearly exists=20
returns EACCES until such time as a user who has more permissions tries to=
=20
access it. At that point, access(F_OK) will return 0 and stat() will=20
return stat info until it leaves cache. (Note that for nonexistent files=20
it will correctly return ENOENT instead.)

It's not really clear to me that POSIX permits access(F_OK) to return=20
EACCES if all the directories up to that point are searchable (i.e., "l"),=
=20
and either way the cache-dependent behavior of 0 vs. EACCES is confusing.

=F8For example, the current implementation of Kerberos' .k5login-checking=
=20
behavior effectively assumes that any nonzero return of access(F_OK) must=
=20
be ENOENT, so if you have a non-world-readable .k5login file, it will=20
_mostly_ appear to krb5_kuserok to not exist by access() returning EACCES,=
=20
but if you get your .k5login into cache, access() will start returning 0=20
instead, and you'll be unable to log in for some period of time (since the=
=20
file isn't world-readable). We've suggested an alternative implementation=
=20
to the Kerberos list, but the apparently-nondeterministic behavior of=20
access(F_OK) and stat() is nonetheless confusing and extremely difficult=20
to track down.

--=20
Geoffrey Thomas
geofft@mit.edu
---1257051904-2053222215-1289097814=:21239--