Madhusudan Singh <[EMAIL PROTECTED]> writes: > Let us refer to :
> http://www.openafs.org/pages/doc/AdminGuide/auagd018.htm#HDRWQ503 > This provides a command by command reference for setting up individual > user accounts on AFS. For my users, I decided to create a user group > (bgroup) for future scalability (we might have users later who would > have different set of permissions or ACLs). > #pts creategroup bgroup > I skipped the kas create commands since I am using the KDC for > authentication. Right. > (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. > 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. 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. 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. 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. > 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. (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.) 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. > 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. > 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. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
