打开/etc/selinux/config 将selinux=enforcing或permissive改成disabled。 记得要重新启动服务器! 当然还要断定以下标题: 1、用户是否被 vsftpd 限制登录, 比如用户名在 /etc/ftpusers 中,并被禁止登录了

打开/etc/selinux/config

将selinux=enforcing或permissive改成disabled。

记得要重新启动服务器!

当然还要断定以下标题:

1、用户是否被 vsftpd 限制登录, 比如用户名在 /etc/ftpusers 中,并被禁止登录了

2、vsftpd.conf 中是否打开了pam认证的选项 (自己编译安装的时候常由于这个出错) (看vsftpd.conf中是否有pam_service_name=ftp或vsftpd.到底是哪个要看

PAM模块的服务文件/etc/pam.d下是谁.我的是ftp且它的配置如下:

#%PAM-1.0

auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed

auth required /lib/security/pam_unix.so shadow nullok

auth required /lib/security/pam_shells.so

account required /lib/security/pam_unix.so

session required /lib/security/pam_unix.so

假如/etc/ftpusers有的用户将被deny

3、相干文件夹的权限是否准确

关于“vsftpd 部分本地用户不能登录,部分可以”的标题,

系统中本来就有的本地帐号都不能登录,我的/etc/vsftpd/vsftpd.conf文件的配置如下:

local_enable=YES

write_enable=YES

chroot_local_user=YES

pam_service_name=vsftpd

/etc/pam.d/vsftpd存在且正常。

登录时错误信息都是一样的:

500 OOPS: cannot change directory:/home/***x

Login failed.

421 Service not available, remote server has closed connection

他们的home目录都是/home/***x。/home和/home/***x的权限都是755。

以上这些帐号都不能ftp登录,这些都是平常经常应用的,可以用shell登录的。

我新创立了一个usr1帐号

# useradd -G test -d /tmp/usr1 usr1

能ftp登录,他的home为/tmp/usr1,在/分区上。而/home我是mount到/dev/hda9上的。

#mount

/dev/hdb1 on / type ext3 (rw)

/dev/hda9 on /home type ext2 (rw)

所以,我料想:是否是由于/home分区的原因,而造成“主目录在/home分区的帐号”都不能登录呢?

为了验证以上假想,我试着再创立了一个帐号

useradd -G test -d /home/usr3 usr3

/home, /home/usr3 的权限都是755。

usr3 ftp登录失败。

500 OOPS: cannot change directory:/home/usr3

Login failed.

421 Service not available, remote server has closed connection

至此,我感到可以断定是由于/home分区的原因,而造成“主目录在/home分区的帐号”都不能登录。

参考文章:

I finished my second upgrade to Fedora Core 4. Not everything is ironed out yet with the build of course. But one thing is for sure a lot has happened to the RedHat I knew before.

I must say of all the changes, for me the nicest addition is the new SELinux extensions. For deep background on the reasons for and theory of SELinux read, The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments

The more I work with SELinux the more I realize I need to know about it, and how exactly it does all its stuff. It certainly changes things relating to users, directories and access. As I am starting to learn it, I'm sure I'm doing things the hard-way. :)

The major difference, so far for me, in Red Hat's SELinux is the way ftp is handled. vsftpd is still the server which is great. However, it seems to be designed to run as a daemon rather than invoked via xinet.d. If you grab a working copy of the xinet.d file for vsftpd you can invoke it via xinet.d wrapper. I did my first server upgrade in this manner. The current one I am trying as a daemon. I certainly think I will miss some of the features that the xinet.d wrapper brings, and may yet return to it.

Of all the issues I saw most notable is if you want to enable chroot directory's outside of the normal /home/*** vsftpd. These will fail with a

500 OOPS: cannot change directory: /mnt/***xx

I was able to use ftp if I logged in with an account with a directory in /home, but once I set a user account to have a home drive outside of /home (in this case on a mounted secondary disk) vsftpd barfs the above.

I found information at the NSA that indicates you can disable SELinux protection of the ftp daemon.

setsebool -P ftpd_disable_trans 1

This seems a bit drastic. It certainly works for now though.

I think ultimately the issue resides with policies, but as SELinux policies are new to me, it will take time before it all gets sorted out. As I spend time with the new SELinux extensions in Fedora Core 4 I will keep you updated on my thoughts and configuration lessons.

解决措施:

# setsebool ftpd_disable_trans 1

# service vsftpd restart

我用的是FC4,按照你上一帖子里的方法试了,马上就解决了。所以,可以断定原因就在SELinux