pam_service_name is what you need to check - pam is an (usually) optional authorization control mechanism. And it clearly supports user change and is blocked as a possible security issue.
You did not specify your OS, but RH used to have /etc/pam.d/vsftpd that you can modify. I do not know if that is still correct or not - probably not. Just be sure to keep a backup.
Thank you for response.
I've tried vsftpd on both RHEL 6.5 and RHEL 5.7, they all had the same issue. I did check pam_service_name, but I had no clue how to fine tune it. Would you please give me some suggestions?
Forgot to mention that the vsftpd version is,
vsftpd-2.0.5-21.el5 for RHEL 5
vsftpd-2.2.2-11.el6_4.1.x86_64 for RHEL 6
[root@mastest pam.d]# more /etc/pam.d/vsftpd
--
#%PAM-1.0
session optional pam_keyinit.so force revoke
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
auth required pam_shells.so
auth include password-auth
account include password-auth
session required pam_loginuid.so
session include password-auth
[root@mastest pam.d]# more /etc/vsftpd/ftpusers
# Users that are not allowed to login via ftp
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
Do not mess with PAM unless you are in easy driving distance of the system, have a rescue CD and the technical know-how to fix it by hand. Even then, give it a couple of second thoughts. The risks of altering PAM are very high. You can easily render your system unbootable, un-login-able, or open security holes you could only discover by accident (or intentional intrusion).
Why do you need to change users after an FTP login? Why not login as the user you wanted to login as in the first place?
Why do you need to use FTP at all?
Explain your problem in more detail and we can probably find better solutions.
Thank you for reminding.
I don't have intention to alter or replace PAM actually,
I'm just thinking if any variables can be added/adjusted into vsftpd PAM file to solve USER command issue. Altering the PAM file is not necessary for me.
If there are other ways to solve the issue, that would be fine.
We have some in-house utilities worked among different domains.
Those utilities are served to users.
A user can run programs and upload data to a partially public account.
The program generates a ftp script including changing the user's account
to the public account "design" and then run the script to upload data.
The program designer uses .netrc to avoid inputing passwords
It's a little bit complicated to explain the designer's needs in detail.
I got a part of the designer's codes as below,
# upload database to the "design" account
# the "design" account is an public account with 755 permission.
if(!(-e $HOME/.netrc)) then
echo machine host login design password password >> $HOME/.netrc
chmod 600 $HOME/.netrc
else if("`grep design $HOME/.netrc`" == "") then
echo machine host login design password password >> $HOME/.netrc
endif
echo ftp host \> ftp.log \<\<\! > cts.ftp
echo user design password >> cts.ftp
echo mkdir $argv[1] >> cts.ftp
echo cd $argv[1] >> cts.ftp
echo bi >> cts.ftp
echo put ${cid}_cts.zip >> cts.ftp
echo bye >> cts.ftp
echo \! >> cts.ftp
chmod 700 cts.ftp
cts.ftp
rm -f cts.ftp
I know it's an outdated coding style since using .netrc is risky and unsafe. There are some history backgrounds out there.
We just focus on solving the issue.
Well, I found my workaround. the "ftp" command has the "-n" argument to supress using .netrc for auto-login.
That allows us to ftp connecting first and then decide login ID.
We can capitalize on this to solve our issue.
I don't know if there has better solution.
So, I may keep this post opening for a while.
That looks to me like a far better solution than playing with your PAM settings. There's just too much security risk in letting users play games with their logins after login.