Subject: Re: [netatalk-admins] SOLVED(?): Shared Trash Problem
From: Neil McAllister (nmcallister@primo.com)
Date: Wed Aug 26 1998 - 18:40:47 EDT
>On Tue, Aug 25, 1998, 21:18:15 Neil McAllister wrote:
Good to hear from you Bob -- I'm new on this list so I'm never sure who
from the archives is still around, reading.
>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.
Right! A pretty "non-Unix" type of thing to do. I find myself wondering
what it means, though... in terms of HFS file permissions, what is the
AppleShare Client checking for?
>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.
On my system, the Trash Can #xx files were getting created with permissions
drwx--S---. At least, that is when I create the root "Network Trash
Folder" myself by hand, as I explained. I think they may have been
"inheriting" different permissions when I let an AppleShare Client create
that root folder.
With my hack, they are now getting created drwx-wS---. And yep, magically
it works. I haven't been able to get my head around what potential
security problems this could present... can you give an example of how one
of your private shares could be compromised by this? My server is pretty
much public-access, with a Guest account that has read-only privilege. I
can't find a reference that explains what you can do with a write-only
directory on a Unix machine.
Now, here's one thing that I haven't done enough experimentation on: does
it really matter if the file is group writeable, or is it enough that it
just be writeable by the current afpd process?
> if group write were on folders in some of those
>volumes it would seriously compromise Unix security.
That's of course an issue for some people. My box is really just a big ole
drive space for Mac clients, I'm not allowing any Unix logins. Coming at
it strictly from the Mac-emulated metaphor, it doesn't seem to pose any
problems for me.
>I think the better long-term solution is to do something about
>emulating the gid 0 AppleShare behavior
By gid 0 behavior, do you mean that one file permission bit I read about
that means "blank permissions" or somesuch? Some of these things seem like
they'd start to take up a whole lot of overhead in emulation.
Anyway, my fix is a hack for sure, but still a major clue I think, for the
smart people to figure out a real solution.
-- Neil McAllister, Systems Administrator Primo Angeli Inc., San Francisco, CA, USA http://www.primo.com mailto:nmcallister@primo.com
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:10 EST