Thanks for the highly detailed response. > > (Am I correct in assuming that all I need to do here is to add some > > pam_krb related entries in /etc/pam.d/common-auth ?) > > Correct. You want to install libpam-krb5 and libpam-openafs-session and > call the former in common-auth and common-session and the latter in > common-session. We can get into more detail if you want specifics on > order and configuration there.
That would be nice. > > Step 12 suggests that I use the AFS id for setting the ownership of the > > mountpoints for the users. Now this sounds fishy to me. The ID in the > > argument to chown usually corresponds to the system groups (not AFS > > groups). > > I'm confused by the above sentence, since you start by talking about UIDs > (the AFS ID) and then you started talking about groups. Perils of multi-tasking :) I meant to refer to system users IDs. > > To create a user account in AFS, use pts createuser. If you don't care > what UID they get assigned, you can omit the ID and AFS will assign one, > but you will then want to use that same UID in your local password file > (or equivalent). I generally prefer to explicitly assign the UID since I > usually have some UID convention that I'm trying to follow that AFS > doesn't know about. One question here : My setup : Realm A User set b \in B (cell omega - uses A for authentication) User set c \in C (a foreign cell that also uses A for authentication) b is a (very small) proper subset of c. I would like (this is not essential, but preferable) to allow clients to do some client-side configuration (I was previously advised on this list that it is possible) so as to allow them to be simultaneously authenticated to B and C (their passwords are obviously identical). In such a scenario, does it matter if the UIDs of members of the set b are the same as their UIDs in set c ? > > Once you've done pts createuser, you should be able to add the user to > ACLs with fs setacl and add them to AFS groups with pts adduser. > > But, anyway, that's an aside. Back to step 12. When you create user home > directories in AFS, you want to chown the top of that user volume to the > user. This is because AFS grants implicit administrator rights to the > user whose AFS ID (shown by pts examine) is the Unix owner of the top > level of the volume, so if the user accidentally messes up an fs setacl > command, they can add themselves back to the ACL without having to bother > an administrator. I think I understand all this clearly. > > To do this, you use the command specified there and chown the directory to > the AFS ID of the user. > > > But I went ahead anyways. The AFS ID of user m_singh is 1, while for > > another user heidel, it is 43114. As I expected, a listing of the > > directories reveals : > > > > #pwd > > /afs/omega.domain.edu/user > > #ls -l > > drwxrwxrwx 2 daemon root 2048 2005-08-25 16:38 m_singh > > drwxrwxrwx 2 43114 root 2048 2005-08-25 16:45 heidel > > Right. NSS lookups on your local system won't know about PTS and > therefore won't know how to map UIDs in AFS to usernames, so you'll get > strange results for anything that doesn't match your local passwd file or > other NSS source. Most of us who have been running AFS for a while have > just gotten used to this and don't notice any more, but in general you > want to have the UIDs that AFS uses match as closely as possible the UIDs > that you put in your passwd file. I do not intend to have any of the users in b (see above) in the local /etc/passwd but instead have them all authenticate via MIT Kerberos 5 mechanism. > > > Now, I had added both m_singh and heidel to bgroup (pts adduser username > > bgroup) . So, is the upshot of all this the following : > > > > There must be a system group corresponding to the pts group for each > > such group and an additional chgrp command must be issued (in contrast > > to the suggestions in the guide). > > > > ? > > No. > > Groups are different than users. The UID associated with a file or > directory matters a *little* bit in AFS, only for the UID that owns the > top level of a volume. GIDs, however, are *completely* ignored by AFS > (with the exception of setgid binaries, and even then it's the kernel > that's noticing, not AFS itself). So don't worry about AFS groups at all; > there's no reason to ever try to express AFS groups in the Unix GID and > you basically will never need to run chgrp in AFS. Thanks for clearing that up. > > (You'll observe, for instance, that AFS group IDs are negative, so you > can't even chgrp a file in AFS to match any AFS group.) True ! > > To see who has access to the files in a directory in AFS, including > groups, use fs listacl. Those are the permissions that actually matter. The 7 ACLs instead of the 3 unix permission bits. > > > I am still not sure what to do about the ownership of the directories - > > the system UID's seem to be trumping the AFS UID's in AFS space. > > No, that's just ls mapping UIDs to names for display purposes. Remember, > in the file system (AFS, local disk, any Unix file system), what's stored > as the Unix owner and group of a file is the numeric UID and GID. The > *names* that are shown by ls are purely an artifact of the numeric mapping > defined by NSS on the system (usually /etc/passwd lookups) and don't have > any effect on access control. Only the numbers *really* matter. True. > > > In addition, how does one change the AFS UID of a member of > > system:administrators ? (Such as m_singh above) ? > > That m_singh is a member of system:administrators makes no difference to > how you would change the AFS UID. The answer is, you can't (at least so > far as I know; I welcome correction from anyone else). You have to create > a new user with a different name and the new UID, add it to the AFS groups > that the old user was in, delete the old user, and then pts rename the new > user to the old user. I think it actually may be somewhat difficult for > you to do this, because in order to do it you need to be able to > authenticate as a different user who's also in system:administrators or > you'll lose access when you pts delete the old user and then won't be able > to finish the renaming of the new user to something that matches the > Kerberos principal. This may be a bit tricky when you don't control the > KDC and can't create a new principal. I might have a few questions here later depending upon your response to my query above. With regards, MS _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info