Subject: FW: Re: [netatalk-admins] permissions
From: Mark J. Taylor (mtaylor@cybernet.com)
Date: Mon Jan 11 1999 - 18:24:28 EST
Hi!
Following is an old email (May 6, '98) referring to file permission
problems that we are also experiencing, with the netatalk+asun code
(2.1.1-4). Our target OS is FreeBSD 2.2.7.
The two main points made below:
1) The setgid bit on directories is a problem:
When the user is not a member of the group that owns a directory,
then they cannot enable the setgid bit on the directory. This results
in an error message to the Mac. This is especially a problem with the
"nobody" user (guest file access).
What does a "real" Macintosh do?
2) The Locked File attribute is causing other problems: sometimes,
you can delete locked files, and sometimes you can't (it seems that the
very first attempt fails, and subsequent attempts succeed).
The problem (1) can be hidden from the user by not notifying them that the
setdirmode() failed (etc/afpd/unix.c:setdirmode). This is probably not the
best approach. :)
Any suggestions?
-Mark Taylor
NetMAX Developer
mtaylor@cybernet.com
http://www.netmax.com/
-----FW: <00001675.sm@h-e.com>-----
Date: Wed, 6 May 98 19:33:59 PST
Sender: owner-netatalk-admins@terminator.rs.itd.umich.edu
From: bsmith@h-e.com
To: netatalk-admins@umich.edu
Subject: Re: [netatalk-admins] permissions
Cc: bsmith@h-e.com
Original message sent on Wed, May 6 2:40 AM by Jan.Dockx@cs.kuleuven.ac.be (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.
bsmith@h-e.com
--------------End of forwarded message-------------------------
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:10 EST