Subject: [netatalk-admins] 1.4b2+MacOS8 patch (Trash DID & 0 gid/uid)

From: "Tan Chee Weei" <[email-masked]>
Date: Fri, 07 Aug 1998 11:45:59 +0900

Running plain 1.4b2 with Mac OS 8 patch
I've been slowly going through the behaviour of afpd with regards to the
trash issue
brought up in earlier threads.  One thing I discovered and would like others
to confirm
is whether the Network Trash Folder's DID should always be set to 3 and if
so, should
volume->v_lastdid be reset to 3 in afp_closevol.  I discovered that when a
volume is mounted,
afp_openvol is first called.  The Trash folder's DID is "primed to 3".  The
volume is then
closed via afp_closevol and reoppened again. On the second invocation of
afp_openvol,
the priming of the Trash folder causes a directory struct with DID set to
whatever v_lastdid's
value is which is now > 3.  Is this what is intended or is it the intention
that the Trash Folder's
DID is always 3?  If so, shouldn't the v_lastdid's value be reset to 3 in
afp_closevol just like
when it was first initialized?  Anyone see anything wrong with this?

Another thing that doesn't seem to be addressed by afpd is how to handle
requests to set a directory's
uid/gid to 0.  In afpd, a uid/gid refers to no ownership, ie. it doesn't
belong to anyone or
anygroup.  Obviously, all attempts to chown to a gid of 0 would fail and
thus not occur.
(This explains why I get  an "afpd{???]: setdirownwer: chown -1/0 Network
Trash Folder: ..." 
message in /var/adm/debug)
The trash folder is first created (if it doesn't exist) with gid=0, ie. not
owned by anyone. That is
why its perms are set to rwx---rwx.  If the gid is indeed able to be set to
a group that doesn't belong to
any users, this would work as the world perms would be used.  Unfortunately,
what happens is that the
chown with gid=0 fails and the group remains as that for the user. 
Subsequent mounts by others
of the same group would be unable to get access to the folder as their group
perms are ---.  Users
belonging to another group would be alright as world perms are set to rwx. 
The same applies
to files/directories created within Network Trash Folder to manage trash. 
The same would 
apply to setting a uid of 0.

One idea is whether to have afpd map uid/gids of 0 to some uid/gid on the
unix side that no
one is a member of, eg. nobody/nogroup.  That would have the same effect. 
Problem is,
if a user is not a member of the group, his afpd process with his effective
ids would not be able
to chown to a gid he is not a member of.  Does afpd do any switching of gids
to say root to
perform any privilege work?  This could be one thing it could do in such a
case and then switch
the effective gid back to the user's real gid.  Not sure if this is possible
or poses any security problems.
I assume it could be accomplished since afpd is a root invoked process.

Another solution, although messier would be to control how permissions are
set, ie. group perms
for gid=0 would inherit the perms from world.  However, I seem to feel some
info is probably
lost in doing this.

Will next look into why the Network Trash Folder shows up as visible for
other users other
than the owner and then the problem with Trash Can #n for n > 2, after
resolving the current issues.

Comments/corrections/ideas most welcomed.  Thanks.

CW

---

From: [email-masked] (Bob Smith, Hammett & Edison, Inc.)
Date: Fri, 07 Aug 1998 15:30:12 -0700

On Thu, Aug 6, 1998, 19:45:59 Tan Chee Weei wrote:

>On the second invocation of afp_openvol, the priming of the Trash folder
>causes a directory struct with DID set to whatever v_lastdid's value is which
>is now > 3.  Is this what is intended or is it the intention that the Trash
>Folder's DID is always 3?

As far as I know, there is nothing magic about DID 3.  I think the whole point
is to have the "Network Trash Folder" get a _persistent_ DID.  Whatever DID it
is getting, the sequence of events in afpd is always the same so the DID is
always the same, and that's all that really matters.

>requests to set a directory's uid/gid to 0. ... The trash folder is first
>created (if it doesn't exist) with gid=0, ie. not owned by anyone.  That is
>why its perms are set to rwx---rwx.

Aha, I always wondered about that odd permission setting!  Maybe this explains
the whole problem - the same permissions initially appear on "Trash Can #n"
sub-folders, meaning that the Mac expects to always have write privilege to
all the sub-folders regardless of who they belong to.  But on the other hand,
I'm sure I tried setting everything to 777, and that didn't fix the problem. 
Hmm.

>Does afpd do any switching of gids to say root to perform any privilege work?
>This could be one thing it could do in such a case and then switch the
>effective gid back to the user's real gid.  Not sure if this is possible or
>poses any security problems.

It is certainly possible, and it just as certainly creates a potential
security hole!  It would have to be done _very_ carefully.

>other users other than the owner and then the problem with Trash Can #n for
>n > 2, after resolving the current issues.

Glad to see someone else trying to crack this little problem, I haven't had
any time lately to spend on it.  But if you find a possible fix I'll be happy
to test it for you!

Bob Smith
Hammett & Edison, Inc.
[email-masked]