[OpenAFS-devel] Re: reason for afsfileprocs.c:876-885?

Adam Megacz megacz@cs.berkeley.edu
Fri, 13 Apr 2007 17:18:01 -0700


Jeffrey Altman <jaltman@secure-endpoints.com> writes:
> Adam Megacz wrote:
>> Does anybody know why this is in afsfileprocs.c?  It doesn't appear to
>> be UNIX file semantics.
>> 
>>   /*
>>    * The check with the ownership below is a kludge to allow
>>    * reading of files created with no read permission. The owner
>>    * of the file is always allowed to read it.
>>    */
>>   if ((client->ViceId != targetptr->disk.owner)
>>       && VanillaUser(client))
>>       errorCode =
>>           (((OWNERREAD | OWNEREXEC) & targetptr->disk.
>>             modeBits) ? 0 : EACCES);
>
> Insert privilege

Hrm...  I'm aware of the "owner can read+write if s/he can insert"
clause to make dropboxes work.  AFAICT the code above deals with mode
bits, not ACLs, doesn't it?

Phrased another way, why would anybody expect a file created with
(mode & 0100)==0 to be readable?  What functionality relies on this
behavior?

  - a

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380