Red Hat Bugzilla – Bug 171792
vsftpd nfs mounted home directory chroot shell fails
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Description of problem:
Using SELINUX in permissive mode. NFS Mounted home directories. VSFTP with chroot shells. Users fail to chroot to their home directories. Unmounting the NFS and using local directories work alright. Using NFS mounted directories with SSH, and local logins also works alright. Using all of the above fails.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. NFS Mount Home Directories, Add Chroot local user options to vsftpd.
2. Attempt to login via ftp.
Actual Results: Oops on chroot
Expected Results: Successful login via FTP
getsebool -a |grep "nfs\|ftp"
allow_ftpd_anon_write --> inactive
ftp_home_dir --> active
ftpd_disable_trans --> active
ftpd_is_daemon --> active
nfs_export_all_ro --> active
nfs_export_all_rw --> active
nfsd_disable_trans --> inactive
tftpd_disable_trans --> inactive
use_nfs_home_dirs --> active
Are you saying that this does not work in permissive mode? If yes this is
probably not an SELinux problem?
Nope... It doesn't work in enforced nor in permissive... However, if I disable
SELINUX completely, it works fine...
Are you seeing any avc messages?
I am not sure what you mean by chroot directories in VSFTP.
Do you mean you simple ftp to a machine with NFS Homedirs and login as a user,
and you can not read or write files in the homedir?
Nope. I don't see any avc messages.
What I meant about chroot directories in VSFTP is shown with the following
directive in /etc/vsftpd/vsftpd.conf:
Your last statement is almost 100% correct... up to the login as a user... The
login as a user fails because it can't chroot to the NFS directory and it kicks
you out immediately (so you can't even read or write files).
If you use non-NFS mounted directories, the "chrooting" works fine... users are
locked into there personal space..
Disabling SELinux also does not resolve the problem... So it looks like your
right.. it a vsftpd problem or an nfs problem...
This bug should be relocated to vsftpd component, I'll do that now.
Bug reassigned to vsftpd component.
The NFS home directories are mounted as read-only. This causes the chroot to
fail. Remounting with read-write capabilities, permits the chroot.
Don't know how you want to classify this (as a bug or not..). Perhaps just a
man-page update. In either case, I remounted with read-write and my problems
are solved here..