how to enable local user on localhost vsftpd?

[david m]

But disabling SELinux protection for individual daemons is possible, or so it should:
http://docs.fedoraproject.org/en-US/...-securitylevel

[jpollard]

Nope. What that entry is referring to is disabling SELinux. You might note that the entry doesn't give any boolean flag name to use...

You can define additional local policies, and give those defined labels to daemons....

But they are still operating under SELinux rules.

Unless you are very familiar with what SELinux is doing, creating such policies will usually result in a more insecure system.

[Annorax64]

I had the same issue, and I had to set the following SEBool entries:

# setsebool ftp_home_dir on
# setsebool allow_ftpd_full_access on

Additionally, I had to add the following to vsftpd.conf:

check_shell=NO

I also added the following to /etc/shells (but not sure this is necessary or not):

/bin/bash

Hope it helps!

[jpollard]

Well... adding the /bin/bash would/should have eliminated the need for "check_shell=NO", and using the "check_shell=NO" would have eliminated the need to add bash to the /etc/shells.

Missing /bin/bash from the file /etc/shells is a known bug. It is supposed to be there.

The advantage of checking shells prevents an odd hacking attack where a user account has a shell that does strange things. It hasn't happened in a long time.

[Annorax64]

Thanks for the explanation. I was wondering if that was the case, so I added the little disclaimer to the second item. I agree that check_shells should probably be put back in again and I will.

Thanks!

[vsftpdhelp]

Had the same problem, finally figuring out the solution

I had in the passwd file (/etc/passwd) the shell (information after last colon) set to /bin/true, which was not in /etc/shells.
It appears that vsftpd check that the user is existing and have permission to log-on (with a valid shell) and that was my problem.

I did that way, to not let /bin/sh because of the risk user can log in using SSH (or telnet).

# grep myuser /etc/passwd
myuser:x:1001:1001:FTP user,,,,Upload file:/usr/local/custom:/bin/true
# grep /bin/true /etc/shells
#

Adding /bin/true to the valid list of shell's command in /etc/shells resolved my situation.
Maybe it's not /bin/true for you, you migth want to check the shell is in the /etc/shells also, and if no, to insert it.

The solution above will let you have an user with ftp permission but no shell permission.

[jpollard]

Actually, it lets the user login, but because /bin/true exits immediately, the user is also logged out.

You should get a record of each login as a valid login.

[vsftpdhelp]

I don't think /bin/true get ever executed. In fact if i remove it from /etc/shells i got :

Thu Apr 11 18:29:41 2013 [pid 30943] [myuser] FAIL LOGIN: Client "127.0.0.1"
and as FTP code
530 Login incorrect.

Otherwise i got
Thu Apr 11 18:30:14 2013 [pid 30957] [myuser] OK LOGIN: Client "127.0.0.1"
and FTP code
230 Login successful.

SSH or telnet would execute it, because it's aims to be interactive, not ftpd

[jpollard]

ftpd includes its own command interpreter - all it looks for is a valid shell...and not "nologin".

[vsftpdhelp]

To conclude, as mentionned previously, i ran into the same issue that check_shell is done for :

check_shell
Note! This option only has an effect for non-PAM builds of vsftpd. If disabled, vsftpd will not check /etc/shells for a valid user shell for local logins.

Default: YES

taken from https://security.appspot.com/vsftpd/vsftpd_conf.html

But because I tried with check_shell=NO in my vsftpd.conf, without success, and that would be the proper solution, i let my system hack of adding my "/bin/true" (or whatever is your shell command in /etc/passwd file) into /etc/shells
I should say i don't have any SELinux system as discussed previously so that wasn't the issue here.



Note:
The shell command associated with the user has no purpose to be executed. As you said previously, it would generate potentially bad behaviour of triggering execution from a ftp log-on, whereas you have no way to execute shell command from FTP connection.
I gave it a try and it's not executed (replaced /bin/true with a logger).

Originally Posted by jpollard

Actually, it lets the user login, but because /bin/true exits immediately, the user is also logged out.

As for technical details, I checked the code source. My results state that inside vsf_sysdep_check_auth() called from handle_local_login() (from file privops.c, use for local login obviously), you can see how it is evaluated.
getpwnam(user).pw_shell (reading the member's shell in /etc/passwd) is not executed but is compared against libc's getusershell() (which is reading the content of /etc/shells). The shell path is not used anywhere else in the source code.