[OpenAFS] AFS behaviour with seteuid() - bug?
Sergio Gelato
Sergio.Gelato@astro.su.se
Wed, 6 Sep 2006 09:36:30 +0200
* David Geirsson [2006-08-11 14:11:52 +0000]:
Your message seems to have been delayed almost four weeks. I assume you
aren't subscribed to the list.
> 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.
Did you try setting up a PAG and running both vsftpd and your token
refresher in that PAG? This won't work with a cron job, but is easy to
do from the script that starts vsftpd. Something along the lines of
(while kinit -k ftp.keytab ; do sleep 20000; done) &
vsftpd
should do the trick.
> 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?
I'll let someone else answer that.