Subject: Permissions and Groups problem

From: Greg Lincoln <[email-masked]>
Date: Tue, 01 Aug 2000 10:35:47 -0700

It seems like I write about permissions a lot, but it's a real issue, here.

Netatalk is not recognizing any user as being a part of any group other than
the one it was created as, from what I can see. I'm apparently not finding
something that needs to be changed, but what? Doesn't the authentication
still run from the system? I''m running ...asun2.1.3-7 and Redhat Linux 6.2,
with shadow PW and PAM installed.

Authentication is working great, and logins are all working like they're
supposed to. I'm still not getting afpd authentications logged in messages,
or anywhere else I can find.

The real problem is if I change a user's default group, netatalk *only*, not
the rest of the system, doesn't recognize it, no matter how many times I
start and stop the server, reboot the machine, or check ownership of
everything. It's like netatalk is keeping its own passwd file, but I
certainly wouldn't know where. I've looked at all passwd, group, and *shadow
files and they all reflect the change to the user, but netatalk refuses to.
So the user continues under the same group as before. Folders only viewable
by group1 are being viewed by a user that only has setting to group2.

I would appreciate any help or insight into this matter.

Graciously,

___________________________________
Greg Lincoln, Creative Director
Southwest Strategies, LLC

[email-masked]
858.597.7555

---

From: Tom Fitzgerald <[email-masked]>
Date: Tue, 01 Aug 2000 15:09:08 -0400

> with shadow PW and PAM installed.

The permissions handling isn't the same as the authentication handling,
so you may be looking in the wrong place....  The afpd will run with the
group membership it finds in /etc/group at the time it (afpd) starts up.
The group list from /etc/group is matched against the single group
that the file or directory is in, to see if the user should have
permission to access it.

Is there some chance you have NIS or NIS+ messing things up?  And
there's no chance that the user accidentally got two entries in
/etc/group, is there?

> or anywhere else I can find.

The authentication stuff is logged as 'daemon.info' to the syslog, so
if your /etc/syslog.conf has

daemon.info      /var/log/messages

(with a tab between the fields, of course) then you should be able to
find it in /var/log/messages.  You should be getting data like this
(though this is at daemon.debug so may be more verbose than normal):

Jun 27 14:12:33 archfile.mit.edu afpd[3651]: dhx login: tfitz
Jun 27 14:12:33 archfile.mit.edu afpd[3651]: 0.08KB read, 0.07KB written
Jun 27 14:12:33 archfile.mit.edu afpd[218]: server_child[2] 3651 done
Jun 27 14:14:53 archfile.mit.edu afpd[3656]: ASIP session:548(2) from 
18.80.2.232
Jun 27 14:24:58 archfile.mit.edu afpd[3706]: randnum/rand2num login: tfitz
Jun 27 14:24:58 archfile.mit.edu afpd[3706]: login tfitz (uid 18719, gid 
101)
Jun 27 14:24:58 archfile.mit.edu afpd[3706]: notice: fixing up 
byte-swapped v1 magic/version.
Jun 27 14:27:50 archfile.mit.edu afpd[3706]: logout tfitz

> by group1 are being viewed by a user that only has setting to group2.

Could you post or send the user's lines from /etc/passwd and /etc/group,
and the ls -l of the directory the user isn't supposed to be in?

---

From: Greg Lincoln <[email-masked]>
Date: Wed, 02 Aug 2000 07:50:54 -0700

> that the file or directory is in, to see if the user should have
Seems I have a theory. Could it be that for whatever compiling reason that
netatalk ONLY recognizes the groups that were present during compiling? I've
been spending a good portion of this afternoon troubleshooting,
painstakingly trying to figure out what I'm doing wrong. I've finally
figured out that if I create a group now and assign it to a user, that user
cannot access the privileges of that group. However, if I do everthing
exactly the same but assign a user to a group that has existed even before
the netatalk installation/compile, it works perfectly. Furthermore, it seems
as if it works from the name of the group as well, not the number, so if the
name of the group is changed, the permissions are no longer valid.

Any ideas? Am I on the right track to figuring out my permissions headache?
Where should I turn? Again, running ...asun2.1.3-7 and RH Linux 6.2.

Thanks.