Subject: Re: [netatalk-admins] SOLVED(?): Shared Trash Problem

From: Neil McAllister <[email-masked]>
Date: Wed, 26 Aug 1998 15:40:47 -0700

>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:[email-masked]

---

From: Michael M Han <[email-masked]>
Date: Wed, 26 Aug 1998 19:05:02 -0700

Previously...
>"inheriting" different permissions when I let an AppleShare Client create

Actually, AS Client's probably asking for 700 and 2000, being 2000,
comes along for the ride. I don't think Macs have any knowledge
of/interest in the high Unix mode bits.

>[snip]

I did some checking and when I tried any of the following modes: 2710,
2720, 2730, 2750, 2760, 2770; everything seemed quite happy. Note that
2740 did not work. Also tried 0700 which didn't work either. And
playing with the "other" bits (*any* combination) didn't do anything
either. This was on Solaris 2.6, and the parent "Network Trash Folder"
was mode 2777.

>they'd start to take up a whole lot of overhead in emulation.

gid 0 refers to the fact that Mac file permissions can be set without
owner and/or group info. You'll see this most often with the top level
Network Trash Folder, where Macs create the folder 707, gid 0. This,
to a Mac, is the functional equivalent of 777. With Unix, it's quite a
different beast, especially because Unix won't set gid 0, so the gid
remains the primary gid of he creator, oftentimes locking out the
entire netatalk user group out of the Trash.

>smart people to figure out a real solution.

Very interesting indeed. I'm not a smart person, but it's definitely
one of the best leads I've seen here on this problem. So, my question
is this: Are the Macs understanding the mode Unix returns: 700; owner
is someone else; group is or isn't the current user; differently from
the way Unix understands? What exactly is the Mac's problem with
netatalk's trash? I seem to recall hearing something here that
indicated that the Mac doesn't try very hard to look around the trash
before deciding it can't do trash, leading me to believe it's some
form of unilateral and erroneous decision the Macs are coming to...

In any event, a workaround would be to catch clients as they create
folders named "Trash Can #*" and be sure to do 710 or 720 instead of
the 700 the Mac requests. Or catch them setting the mode, if Macs do
this separately from the actual creating of the directory -- can't
remember which. It'd probably be a fairly simple conditional to hack
in. This doesn't have such wide security repurcussions as making ORing
all files 020. Any takers on this workaround?
_________
mike ([email-masked])
No one is interested in my underpants
 - The collected wisdom of Bart Simpson

---

From: [email-masked]
Date: Thu, 27 Aug 1998 01:03:29 -0400

> >emulating the gid 0 AppleShare behavior

First give 0 gid whatever permissions "other" has.  That may be enough,
since afpd tends not to complain about many gid mis-match problems.  If
not, then if you're on a system that either inherits gid's from the
containing directory (BSD), or permits chowns (some SYSV) then you're
all good.

:wes

---

From: a sun <[email-masked]>
Date: Thu, 27 Aug 1998 10:26:09 -0700 (PDT)

wasn't all this figured out ages ago? it's definitely somewhere down
there on my "to fix" list. i didn't realize people were so concerned
about the trash can. fyi, there are currently two problems with the
trash can:
	 1) unix <-> afp permission mapping isn't quite right, and
	 2) byte locks don't quite work.

in any case, i guess i'll move #1 up on my todo list. 

-a