Hello,
Apologies for the long delay. I forgot about this issue as I got busy.
> I upgraded from -19 to -21 this morning, built and installed
> openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb
> using m-a as usual, and it still works.
>
Ok.
>
> > >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
> > >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied
> > >>
> > > This look like the user you authenticate as, simply doesn't have the
> > > required permissions to access the directory.
> >
> > Impossible. I can ssh into the server with the same username and password
> > without any issues. I use rsync to do regular (every 1 hour) backups to
> this
> > directory ( a process that is cumbersome, which is why I am looking to
> set
> > up my openafs client).
>
> All right. Your problem *is* client-side, then. Could you look at the
> output of "klist -a -n" and verify that your AFS service ticket is for
> the right address? (Addressless is usually OK.) NAT gateways sometimes
> interfere.
>
$ klist -a -n
Ticket cache: FILE:/tmp/krb5cc_457671
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
10/27/08 09:17:57 10/28/08 09:17:57 krbtgt/[EMAIL PROTECTED]
Addresses: (none)
10/27/08 09:18:01 10/28/08 09:17:57 [EMAIL PROTECTED]
Addresses: (none)
Kerberos 4 ticket cache: /tmp/tkt457671
klist: You have no tickets cached
Appears to be addressless. I tried this with my own firewall down (not that
has anything to do with what you were talking about - just wanted to
eliminate a possible point of failure).
>
> > I cannot cd into my own directory, so I ssh'ed into the server and issued
> fs
>
> Which authentication method did you use with ssh? Does GSSAPI work?
>
I have never really looked into this. I believe that I have ssh-krb5 or some
such thing installed. A quick look inside my /etc/ssh/sshd_config on the
client indicates "GSSAPIAuthentication yes" is set.
> > listacl :
> >
> > $ fs listacl
> > Access list for . is
> > Normal rights:
> > systems:backup rl
> > www-hosts l
> > system:administrators rlidwka
> > XYZABC rlidwka
>
> Looks good. One question, though: is the server you ran this on a member
> of www-hosts ?
I have no idea (it does host www directories for users). How do I find out ?
>
>
> > The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root
> > (tested both through the local /afs tree and by ssh'ing to the server and
> > doing a cd ..). I do not recall what this was when things were working
> fine
> > (never needed to check), but is this normal (sounds fishy) ? In a
> different
> > cell, a long time ago, I seem to vaguely recall that the directory was
> owned
> > by the user in question.
>
> The UID that owns the volume root has implicit "a" permission on all
> directories in the volume. That would let you recover from a "fs setacl
> $HOME XYZABC none" without having to bother the AFS administrators. But
> since the ACL explicitly grants you full access, you should have full
> access --- as long as your token is valid.
>
> > To test if this was messing up things, I cd'ed to
> > /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command :
> >
> > $ cd XYZABC/Private
> > bash: cd: XYZABC/Private: Permission denied
>
> So you were trying to access /afs/
> YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ?
>
Yes.
>
> Was this on the server or on your client? If on the client (as your
> other statements are suggesting), it simply restates that your token
> is not being accepted. If on the server, I'd want to see the ACL on
> that subdirectory (and know whether the server is in www-hosts).
This was on the client. On the server, I have no issues accessing anything
that I own.
>
>
> > This is more nonsense as ~/Private holds my backups :) Maybe the fact
> that I
> > do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that
> command.
>
> I don't see how that would work as an explanation.
Shooting in the dark with my ignorance as an able ally :)
>
>
> > The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is
> obviously
> > XYZABC.
>
> Not so obviously since you said that the top-level directory is owned by
> root, not by XYZABC. You could be locked out of a subdirectory by its ACL.
>
When I login to the server through ssh, I see the following :
drwxr-xr-x 6 XYZABC XYZABC 2048 Oct 27 09:24 Private
I guess I should have included that instead of simply stating that I can
read/write to the directory etc. You can read/write to any directory without
being the owner if you have the right ACL's / unix file permissions.
> My impression is that the token you got on your client is either invalid
> or belongs to a different AFS user. The explanations I can think of are
I simply fail to see how it can belong to a different AFS user. The UID is
the same and the username used is the same for the attempt to get tokens,
and for the successful login to the server (as well as the ownership of the
subdirectories like above).
Maybe you should explain why you continue to suspect this ?
>
> (a) that you are behind a NAT and your token is for the wrong address;
Addressless above.
>
> (b) that you're obtaining the token via Kerberos cross-realm and it's
> really for user [EMAIL PROTECTED] (in which case you could try
> fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC [EMAIL PROTECTED] all
> on the server where you do have access, or learn how to authenticate to
> the correct realm in the first place).
The realm listed in the token is YYY.EDU. To just check against any mess up
of this sort, I logged in to the server using ssh. Issued klist -a -n ON the
SERVER :
$ klist -a -n
Ticket cache: FILE:/tmp/krb5cc_457671_Rdt7da
Default principal: [EMAIL PROTECTED]
Valid starting Expires Service principal
10/27/08 09:32:49 10/27/08 19:32:48 krbtgt/[EMAIL PROTECTED]
renew until 10/27/08 19:32:48
Addresses: <an actual IP address>
Kerberos 4 ticket cache: /tmp/tkt457671_QToYEM
Principal: [EMAIL PROTECTED]
Issued Expires Principal
10/27/08 09:32:49 10/27/08 19:27:49 [EMAIL PROTECTED]
10/27/08 09:32:49 10/27/08 19:32:49 [EMAIL PROTECTED]
Notable differences - its not addressless and kerberos 4 tickets were issued
as well.
>
> Can't the helpdesk at YYY.EDU help you with this?
>
I will definitely ask them (though most of them are windows addled unix
ignoramuses - this is one your more "modern" IT departments) once I have
exhausted all chances of the problem being at my end. Thanks for your help
and patience so far. Any suggestions would be greatly appreciated.
With regards.
