Subject: Re: [netatalk-admins] SOLVED(?): Shared Trash Problem
From: Bob Smith, Hammett & Edison, Inc. (bsmith@h-e.com)
Date: Wed Aug 26 1998 - 18:02:51 EDT
On Tue, Aug 25, 1998, 21:18:15 Neil McAllister wrote:
>Interestingly enough, Bob later said that he believed the eventual fix
>would be an easy one, but that he didn't think it was a permissions
>problem. Well -- I'm here to tell you it IS a permissions problem. I'll
>explain, but first I'm going to post my entire fix (see if you like the
>look of mine better than Bob's):
.
.
.
>What seems to be the case, is that for the network trash to operate
>properly, the Network Trash Can and the Trash Can Usage maps need to be
>world read-writeable. But the "Trash Can #xx" files are a special case.
>Get this -- for whatever reason, in order to interpret those directories
>properly, the Appleshare client just needs to see that they are WRITABLE.
Neil -
Hey, good find! This is a major clue and actually confirms what I've
suspected all along. When I said I didn't think it was a "permissions
problem" I was thinking in terms of a problem where the client attempted an
operation and was denied due to permissions on the Unix side. In fact your
work-around shows the problem is that the client simply "looks" at the
permissions and decides on it's own whether it will be able to do what it
wants, without actually attempting the action. This explains why debug logs
from afpd never showed what was going on, because there were no actual AFP
errors occurring. Somewhere in afpd's translation between the actual Unix
permissions and the AppleShare modes reported to the client something is
"lost", and the Trash folders are being mis-represented causing the client to
decide it can't do anything with the Trash.
Tan Chee Weei <ctan@pacific.net.sg> earlier speculated that it has something
to do with setting a folder to gid 0, which means "no group" in AppleShare but
something entirely different in Unix. If you let afpd create "Trash Can #N"
folders without any attempt to work around the problem, the folders end up
with rwx---rwx, and there is also an attempt by the client to set the folder
to gid 0, which afpd of course refuses to do. As I understand it, your patch
will force the permissions to be rwx-w-rwx, or maybe rwx-wSrwx, and magically
the Trash works, but only if all users are in the group that the Trash folders
belong to.
So putting the pieces together, it appears that when the client creates a
folder with gid 0 meaning "no group", then later looks at the access
privileges to that folder, it expects to see group writeability regardless of
the actual group of the current user. But with the normal afpd behavior, the
Trash folders would never be writeable by any group! So the client would look
at the Trash folders, and not seeing group writeability on them, would decide
it couldn't use the Trash at all (the logic behind that decision is still
obscure, but my guess is that it involves compatibility with previous AFP
versions).
Your solution is a lot simpler than mine, but I am concerned about universally
assigning group write privilege to all new folders. If you only have shared
volumes that must have group write anyway it's fine. But I also have afpd
sharing "private" volumes, and if group write were on folders in some of those
volumes it would seriously compromise Unix security. So in my case your fix
won't work, unless I expand it a bit so that the group write bit is only set
in certain "safe" circumstances, i.e. specifically on any folder called "Trash
Can #[0-9]*". I think the better long-term solution is to do something about
emulating the gid 0 AppleShare behavior, there has been discussion of that but
it isn't all that easy to accomplish. Until someone solves it that way, we
now have two different work-arounds one of which is probably suitable for any
particular situation.
Bob Smith
Hammett & Edison, Inc.
bsmith@h-e.com
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:10 EST