[OpenAFS] Debian - openafs -noauth problems

[Russ Allbery]

Madhusudan Singh <singh.madhusudan@gmail.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>