Subject: Re: [netatalk-admins] SOLVED(?): Shared Trash Problem
From: Michael M Han (han@windy.ckm.ucsf.edu)
Date: Wed Aug 26 1998 - 22:05:02 EDT
Previously...
>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.
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.
>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
>[snip]
>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?
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.
>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.
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.
>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.
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 (han@library.ucsf.edu)
No one is interested in my underpants
- The collected wisdom of Bart Simpson
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:11 EST