[OpenAFS] Debian - openafs -noauth problems

[Madhusudan Singh]

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