[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