vsftpd / pam issue

[coredump]

I'm having a little issue with vsftpd on 7.1-release.

My plans are:

1 - Permit local users in the "trusted" group to login via ftp and be chrooted into their relevant home paths.
2 - Permit virtual users as listed in a pwdfile (htpasswd created) file to login and be chrooted to /home/virtual/{$USER} where {$USER} is their login name
3 - Permit anonymous access (read-only) to /home/anonftp
4 - Deny root

Now, the problem I have in requiring users to be in the "trusted" group. It seems the the pam_group line is not being considered at all here - the question is ... why?

Files:

/etc/pam.d/vsftpd

auth requisite pam_nologin.so
auth sufficient /usr/local/lib/pam_pwdfile.so pwdfile /usr/local/etc/vsftpd.passwords
auth requisite pam_group.so no_warn group=trusted
auth required pam_unix.so
account required pam_permit.so


/usr/local/etc/vsftpd.passwords

alice:4TfZSeqr.rG8k
bob:7eyopIN7Xq086


/usr/local/etc/vsftpd.conf

ftpd_banner=Welcome...
anonymous_enable=YES
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
anon_upload_enable=NO
anon_world_readable_only=YES
anon_root=/home/anonftp
local_enable=YES
chroot_local_user=YES
secure_chroot_dir=/usr/share/empty
listen=YES
virtual_use_local_privs=NO
write_enable=YES
connect_from_port_20=YES
pam_service_name=vsftpd
guest_enable=YES
user_sub_token=$USER
local_root=/home/virtual/$USER
hide_ids=YES
background=YES

[anomie]

It seems the the pam_group line is not being considered at all here - the question is ... why?

Can you describe your test cases and what led you to that conclusion?

I'm definitely not a pam expert, but I'm a little curious about your rule ordering. "auth sufficient" will break the processing chain and return success (if it passes), and it just so happens to be immediately before the pam_group rule.

So IMO more info is needed here.

[coredump]

The sufficient rule here as you say terminates immediately upon success, however in this case, it is for "virtual" users - ie - those that I have added to the /usr/local/etc/vsftpd.passwords file.

Assuming the user is not listed in this file, the requirements - to my thinking - state that the user should a) be a normal (local) unix user AND b) in the "trusted" group.

So assume "alice" supplies the correct credentials... she will be passed on via pam_pwdfile immediately - no further processing being needed.

However, myself, "coredump" upon supplying the correct credentials I will fail the pam_pwdfile and continue processing with the pam_group and pam_unix lines. Assuming I'm a trusted user (and I really ought to be), in theory I should be authorized however, I'm not being permitted access.

Removing the requirements for the "trusted" group membership lines allows all local unix accounts (including root which I *really* don't want) into the the system.

I've tried swapping the pam_group / pam_unix lines around -- not just in order by also requisite/required control flags but to no avail.

[anomie]

Well, your rules seem logical based on what you're describing and what I have (http://www.freebsd.org/doc/en/articles/pam/pam-freebsd-modules.html) read (http://www.freebsd.org/cgi/man.cgi?query=pam_group&sektion=8).

In the absence of other (more specific) advice, what I would do in your shoes is start tinkering with pam_group further. For example, what if you passed it the arguments deny group=wheel root_only. (Since that seems to be one of your primary goals.) Does that have the desired effect?

[coredump]

Yes, it does prevent root access however it's not an ideal solution.


[root@twotwenty /]$ ftp root@twotwenty
Connected to twotwenty.
220 Welcome
331 Please specify the password.
Password:
********* LONG DELAY HERE *********
530 Login incorrect.
ftp: Login failed.
ftp> exit
221 Goodbye.


I've no idea what the delay is here, and my concerns are that even accepting a root account may be in error. (This also applies to local users no in the trusted group).

I think my concept of using pam itself here may very well be in error as the [ftp] server can perform the duties sufficiently well with it's own acl's (perhaps in conjunction with a little shell scripting).

Perhaps I'll rethink these ideas and look into a simpler ACL based management purely at the ftp server and leave pam until I can add some debugging statements into the relevant pam modules in an effort to trace exactly what's happening.