Bug 619726 - vsftpd with Kerberos doesn't clean up Credentials Cache
vsftpd with Kerberos doesn't clean up Credentials Cache
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vsftpd (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Skala
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-30 06:24 EDT by Colin.Simpson
Modified: 2014-11-09 17:33 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-04 10:02:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2010-07-30 06:24:42 EDT
Description of problem:
When you ftp to a machine running vsftpd that uses krb5 authentication through PAM it generates a TGT credentials cache in /tmp. As expected. But this never gets removed when the ftp session ends. 

This means /tmp gets very full of (tens of) thousands of krb5cc files on a busy server.

Version-Release number of selected component (if applicable):
All versions (including RHEL 4)
(but interestingly seems to not happen on F13 using SSSD)

How reproducible:
Every time

Steps to Reproduce:
1.ftp to server and login as a kerberos user.
2.Examine the server's /tmp directory for new krb5cc_ file for this user
3.Log out of FTP
4.Check /tmp for the new krb5cc file and observer that it's still there
  
Expected results:
The credentials cache gets removed at the end of the FTP session.

Additional info:
It's not like ftpd can just throw away it's credentials cache on login, as it's possible (I guess) it may need to access say NFSv4 directories requiring krb5 authentication. 

I suppose this maybe hard to fix if vsftp has chrooted, can't remember if it does in a non-anonymous login?

A further wrinkle, on certain FTP clients that start lots of parallel sessions you end up with log entries on the KDC:

Jul 30 10:38:31 cslu2ux01 krb5kdc[5037](info): DISPATCH: repeated (retransmitted?) request from 10.100.53.144, resending previous response

, but I guess this is just expected. 

F13 not doing this with SSSD, I'd imagine points to the ultimate solution to this in later RHEL's (i.e. 6) using a smarter back end.
Comment 1 Jiri Skala 2010-08-04 10:02:15 EDT
Please, configure session_support option in the vsftpd.conf:

session_support=YES
Comment 2 Colin.Simpson 2010-08-04 10:33:03 EDT
yup that seems to work. 

Thanks

Note You need to log in before you can comment on or make changes to this bug.