Hide Forgot
Description of problem: When trying to login as anonymous user to gssftp daemon I got Login failed. I tried to allow allow_ftpd_anon_write, ftp_home_dir and allow_ftpd_full_access booleans, neither of it helped. Version-Release number of selected component (if applicable): selinux-policy-3.7.19-93.el6.noarch krb5-appl-servers-1.0.1-2.el6.i686 How reproducible: 100% Steps to Reproduce: 1. turn on kerberos gssftp daemon 2. login as anonymous user Actual results: .[root@i386-6s-m1 ~]# ftp `hostname` Connected to i386-6s-m1.ss.eng.bos.redhat.com. 220 i386-6s-m1.ss.eng.bos.redhat.com FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Credentials cache file '/tmp/krb5cc_0' not found GSSAPI error: initializing context GSSAPI authentication failed Name (i386-6s-m1.ss.eng.bos.redhat.com:root): anonymous 331 Guest login ok, send ident as password. Password: 550 Can't open PAM session. Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> bye audit.log: time->Wed Jun 15 09:09:33 2011 type=SYSCALL msg=audit(1308143373.006:30826): arch=40000003 syscall=4 success=no exit=-13 a0=4 a1=f148d8 a2=38 a3=ffffffff items=0 ppid=31336 pid=31352 auid=14 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4611 comm="ftpd" exe="/usr/kerberos/sbin/ftpd" subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1308143373.006:30826): avc: denied { compute_user } for pid=31352 comm="ftpd" scontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=security ---- time->Wed Jun 15 09:09:33 2011 type=SYSCALL msg=audit(1308143373.006:30827): arch=40000003 syscall=4 success=no exit=-13 a0=4 a1=f148d8 a2=32 a3=ffffffff items=0 ppid=31336 pid=31352 auid=14 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4611 comm="ftpd" exe="/usr/kerberos/sbin/ftpd" subj=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1308143373.006:30827): avc: denied { compute_user } for pid=31352 comm="ftpd" scontext=unconfined_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:security_t:s0 tclass=security # ausearch -m AVC -ts recent | grep ftp | audit2allow #============= ftpd_t ============== allow ftpd_t security_t:security compute_user; /var/log/secure Jun 15 09:09:33 i386-6s-m1 ftpd[31352]: pam_unix(gssftp:session): session opened for user ftp by (uid=0) Jun 15 09:09:33 i386-6s-m1 ftpd[31352]: pam_selinux(gssftp:session): Unable to get valid context for ftp Expected results: # ftp `hostname` Connected to i386-6s-m1.ss.eng.bos.redhat.com. 220 i386-6s-m1.ss.eng.bos.redhat.com FTP server (Version 5.60) ready. 334 Using authentication type GSSAPI; ADAT must follow GSSAPI accepted as authentication type GSSAPI error major: Unspecified GSS failure. Minor code may provide more information GSSAPI error minor: Credentials cache file '/tmp/krb5cc_0' not found GSSAPI error: initializing context GSSAPI authentication failed Name (i386-6s-m1.ss.eng.bos.redhat.com:root): anonymous 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> bye 221 Goodbye. Additional info: Same on RHEL5 works without problems
This looks like pam_selinux is being called within gssftp's pam stack.
It is, yes.
Well it should not, shouldn't it just use the /etc/pam.d/ftpd?
Well there's no /etc/pam.d/ftpd, and we wouldn't want to be dragging a different FTP server onto the system with a file dependency. Does the vsftpd configuration look right?
That one works, (Well at least I have never seen this bug).
Good enough. I'll just grab a copy of the file from source control and use it.
The GSSAPI-aware FTP server and its configuration are actually in the krb5-appl package in 6; changing assigned component.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1706.html