Subject: Re: [netatalk-admins] permissions

From: [email-masked]
Date: Wed, 6 May 98 19:33:59 PST

Original message sent on Wed, May 6  2:40 AM by [email-masked] (Jan
Dockx) :

> Netatalk maps the sharing settings (and possibly also the locking in the
> Finder Get Info of files) to Unix file permissions.
>
> Instead of continuing to try to find out how this mapping is done by trial
> and error, can someone tell me, or point me to a document describing this?
> I can't seem to find it, and it is not in the FAQs.

Aha, a chance to gripe about one of my pet peeves with afpd.

I do not know if the permissions mapping is documented anywhere, but I do know
from experience that it is somewhat unpredictable and erratic.  The AppleShare
concept does not assign ownership or permission attributes to individual files,
only to folders.  Unix assigns attributes to everything, so to make things work
right afpd should set file attributes to always match the directory containing
the file; it tries to do this, but it seems to be very hit-and-miss about it.  I
frequently have problems with files that end up with the wrong permissions and
have to be fixed manually from the Unix side.  This usually happens after some
files have been moved from one directory to another and should have different
permissions as a result, but afpd doesn't make the changes.  Also it happens
when I change permissions on a directory from the Finder, afpd doesn't always
propagate the change to all the files in the directory.

A similar problem is specific to Unices like Linux that use the setgid bit on a
directory to determine whether files created in that directory are assigned the
group of the directory or the primary group of the user.  When this is the case
afpd should always turn on setgid for directories so that files have the group
of the directory; however again it is hit-and-miss, it will sometimes create
directories with setgid off.  This is a problem if you use group privileges to
share an afpd volume among multiple users; if any of the users are in a
different primary group (meaning they are in the volume's group by secondary
 membership), missing setgid bits will cause files to be created with the wrong
group which will make those files unreadable to some of the other users of the
volume.

Also, the Finder "locked file" attribute is *not* mapped to Unix permissions; a
locked file on an afpd volume is not really protected, the application using the
file can still write to it.  Some applications seem to check the lock bit
independently and will honor it, however many don't, they apparently depend on
being told they can't write to the file.  Since afpd doesn't map the lock bit to
permissions, the application is told that it has write privilege, and the lock
is essentially ignored.  This seems like a bug in afpd but I haven't really dug
into the code to see.  Anyway, the only reliable way to "lock" a file on an afpd
volume is to "chmod a-w" from the Unix shell.

In summary, afpd's permissions handling is in need of some improvement, in my
opinion.  There, I feel better now.

Bob Smith
Hammett & Edison, Inc.
[email-masked]