[OpenAFS] AFS behaviour with seteuid() - bug?

[David Geirsson]

Hi all,

First of all I'd like to apologise if I am in error with regards to my
understanding of these things - I'm not much familiar with seteuid().

I recently set up an AFS cell for a local network (only two users
mounting the AFS, but close to 1TB of data. I am very happy with the
switch, and everything except one thing is now working.

That one thing is FTP. I provide read-only access to the AFS share to a
group of users through FTP. I have vsftpd set up with its own user
database (I do not want to create local accounts for these users). I do
not want to force these users to use kerberos-aware ftp clients, and I
would much prefer to not create kerberos principals and AFS users for
them either - they all have the same privileges.

What I did was to create an 'ftp' user in kerberos and AFS, and extract
its kerberos key. I then have a small script in a cron job for the ftp
user that obtain kerberos tickets and AFS tokens. This part works, the
ftp user has valid AFS tokens and can read the share. Users on the FTP
are all mapped to the local ftp user, and should therefore use its AFS
tokens. However, when I FTP in and try to obtain a directory listing,
vsftpd returns a 'cannot change directory' error. I made a small test
program that calls setuid() to the FTP user, and reads a file from the
AFS share, and it succeeds. However, once a process calls setuid, it
cannot regain its privileges. For this reason I tried seteuid(), which
does allow a process to regain its privileges after doing nonprivileged
processing. This is what I believe vsftpd uses. When the test program is
modified to use seteuid(), the open() call on the AFS file fails.

My question is: Is this correct behaviour? Shouldn't the AFS client be
listening to the effective UID with regards to which tokens to use?

Sorry for the length, and thank you all for the great program that is
OpenAFS.

With kind regards,
-- 
David Steinn Geirsson
Reykjavik, Iceland
+354 8696608
davidgeirs@gmail.com