[6720] in Athena Bugs
Re: [jfc@MIT.EDU: AFS writes fail silently]
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Fri Dec 28 01:42:30 1990
Date: Fri, 28 Dec 90 01:41:57 -0500
To: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Cc: bug-afs@MIT.EDU, bugs@ATHENA.MIT.EDU
In-Reply-To: Jonathan I. Kamens's message of Wed, 26 Dec 90 20:05:23 -0500,
From: Richard Basch <probe@MIT.EDU>
Return-Path: jfc@ATHENA.MIT.EDU
To: bugs@ATHENA.MIT.EDU
Subject: AFS writes fail silently
Date: Tue, 21 Aug 90 05:09:31 EDT
From: John Carr <jfc@ATHENA.MIT.EDU>
Writing to a file in a cell that enforces group permissions (testers, rel-eng)
can fail silently if the file is owned by another user and has group write
off.
Specific example: I was using vi to edit a number of files in the X sources.
These were owned by other users, but the directory acl gave me write
permission. After I wrote the file and quit vi, I found the file unchanged.
I never saw an error message. This cost me an hour of work after I figured
out the problem, because I had to go back and re-edit all the files AFS had
refused to change.
There are 2 bugs: (1) access checks, including the one by the open system
call, return OK for files to which access is denied by the group permission
bits (2) either [1] error status is not returned for such files on close or
[2] vi does not check the return value of close.
I suspect bugs in checking read permission in similar cases.
John is correct, and unfortunately, there is no solution with AFS. AFS,
unfortunately, decided that it was going to be "smart" about things and
do access checks locally, rather than making an "access" call to the
server (and caching that information, possibly registering a callback
for when it changes). So, it like NFS, loses because it thinks that the
client knows everything about the server, and thus decides to first
check the PRSFS_RIGHTS (rights granted by the acl), and then masks the
open modes with the file's owner bits to see if access should be
granted.
It is lack of thought like this that has led us to having problems with
NFS as well, forcing us to have the same uid on the client on server if
you want full access to your files in NFS.
AFS 4.0 has an extended acl mechanism, and is more POSIX compliant than
AFS 3.x, so hopefully this problem will go away then. I'll see if I can
find the appropriate code in the DCE and report a bug/suggestion to
Transarc before they make the same mistake again.
The one possibility for fixing it with the AFS 3.x protocol is if the
caching of rights for a file are actually done per file rather than per
directory (yes, I know acls are per directory, but that does not mean
the association of file rights may be sharing a common directory right
in the kernel). If that is so, then it may be possible to frob with the
rights returned by the server to reflect what the user is allowed to do
to a given file. There will still be the bug that the file is expected
to have the most access in the owner bits, but at least this is usually
the case.
In the meantime, I would suggest that "vi" be checked to verify that it
does have a check on the close status. Of course, errors on write won't
be detected since you are only writing to your local cache, and are not
flushing data to the server until close.
-Richard
