Subject: [netatalk-admins] 1.4b2+MacOS8 patch (Trash DID & 0 gid/uid)
From: Tan Chee Weei (ctan@pacific.net.sg)
Date: Thu Aug 06 1998 - 22:45:59 EDT
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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:02 EST