[OpenAFS-port-darwin] Unix permission bits

[Chuck Boeheim]

Thanks for your replies.   The afssettings seems to work as
advertised.  It took me a little bit to come up with a case
that was affected by this.  To have GUI problem, you have
to have

1) a file or directory not owned by your uid.
2) an ACL that lets you in with your current token
3) group or other permission bits that contradict the ACL.

Correct?  I actually had to construct a test case, since
I couldn't readily find one that failed.  Perhaps that's
because our umask is typically 022 and files and directories
are readable by group and other.  Do other sites see
common failures?

I would argue that RealModes = true should be the default
for two reasons:

1) A user copying files to AFS for archival via 'cp -rp' or
rsynch will have all his files made world-writable when
copying them back from AFS to the local file system.
That's a pretty big security exposure, since the files
could contain ssh keys, grid certificates, etc.

2) This isn't just a Mac problem, though GUIs are more
prevalent on the Mac.  It seems it should be addressed
more globally.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chuck Boeheim    Stanford Linear Accelerator Center     650-926-4640
SLAC Computing Services Assistant Director Boeheim@SLAC.Stanford.Edu
Contact info & PGP key:        http://www.slac.stanford.edu/~boeheim
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



David Botsch wrote:
> The reason is a bug in the Finder. Finder tries to predetermine whether 
> or not you are allowed to access a particular directory or file by 
> looking at the unix mode bits. This breaks under afs where only the user 
> mode bits matter and the unix user id of the file does not matter.
> 
> On 2004.02.03 15:35 Edward Moy wrote:
> 
>> I don't know the history or initial reason why this extra code to 
>> modify the permission bits was added to darwin/macosx.  But starting 
>> with the 1.2.10a version, that "feature" can be turned off, using the 
>> afssettings mentioned below.
>>
>> Edward Moy
>> emoy@apple.com
>> ---------------------------------------------------------------
>> (This messages is from me as a reader of this list, and not a 
>> statement from Apple.)
>>
>> On Feb 3, 2004, at 6:32 AM, David Botsch wrote:
>>
>>> Are these new permission things only there in either the Panther 
>>> package or
>>> only in 1.2.11 package?
>>>
>>> On Tue, Feb 03, 2004 at 10:26:27AM +0100, Sebastian Hagedorn wrote:
>>>
>>>> Hi,
>>>>
>>>> --On Montag, 2. Februar 2004 22:36 Uhr -0800 Chuck Boeheim
>>>> <boeheim@SLAC.Stanford.EDU> wrote:
>>>>
>>>>> We've just started looking at supporting macosx, and running afs on 
>>>>> it.
>>>>> Running openafs 1.2.10 on macosx 10.3, I observe that the unix 
>>>>> permission
>>>>> bits look quite different than they do on other platforms.  I found 
>>>>> some
>>>>> of
>>>>> the references to the 'permission patch', so it seems that this is
>>>>> deliberate, but
>>>>> I hadn't yet found a discussion about why this was a desireable 
>>>>> thing to
>>>>> do.
>>>>
>>>>
>>>> the GUI apps can't handle the AFS bits, so e.g. the Finder won't 
>>>> allow you
>>>> to open directories for which you have AFS permissions.
>>>>
>>>>> We have some system maintenance appliations that copy config files,
>>>>> applications,
>>>>> etc from AFS space to the local disk.  They depend on replicating the
>>>>> permission
>>>>> bits from AFS to the local copy, which of course breaks with this
>>>>> behavior. We end up with applications and config files being world
>>>>> writable this way.
>>>>> We trust our users, but not that much!  Is there a way to configure 
>>>>> this
>>>>> behavior
>>>>> or otherwise get at the true bits stored in AFS?
>>>>
>>>>
>>>> Check out /private/var/db/openafs/etc/config/settings.plist. You 
>>>> need to
>>>> run /private/var/db/openafs/etc/config/afssettings after you've made a
>>>> change.
> 
>