[OpenAFS] Debian - openafs -noauth problems
Thu, 25 Aug 2005 22:53:51 -0400
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 :
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
> 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
> > 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).
> > ?
> 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.)
> 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.
> > 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