Description of problem: Seems like PAM rules are not available: Dec 19 18:15:15 server proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory Dec 19 18:15:15 server proftpd: PAM audit_log_acct_message() failed: Operation not permitted Yet file is available: # ls -la /etc/security/pam_env.conf -rw-r--r-- 1 root root 2980 2008-02-20 08:02 /etc/security/pam_env.conf Could be this issue: http://forums.proftpd.org/smf/index.php?topic=3558.0 ProFTPd indeed uses DefaultRoot directive which chroots system calls: /etc/proftpd.conf: DefaultRoot ~ psacln This could be confusing PAM. I would advise looking into PAM configuration to ensure that it can work correctly in chroot. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Updating to version 9 and also F10 does this too! Only with chmod user.
I've tried this on Fedora 10 with the default configuration from proftpd-1.3.1-6.fc10.x86_64 and am unable to reproduce the problem. I do see my local user chrooted by default, as well as an selinux problem to list $HOME, but no PAM problem... Could it be that you are using a custom configuration with changes that could be causing this? Could you please try with the default configuration to see if it makes a difference? Another workaround I can think of would be to use mod_auth_unix.c if you don't need anything in particular from what PAM provides.
I patched the issue up by: /etc/pam.d/proftpd # session include system-auth This stopped the alert. All I was getting in /var/secure was: Dec 21 06:09:35 server proftpd: pam_unix(proftpd:session): session opened for user x by (uid=0) Dec 21 06:09:35 server proftpd[22982]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - USER x: Login successful. Dec 21 06:09:35 server proftpd[22982]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - Preparing to chroot to directory '/var/www/vhosts/x.com' Dec 21 06:09:39 server proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory Dec 21 06:09:39 server proftpd: PAM audit_log_acct_message() failed: Operation not permitted Dec 21 06:09:39 server proftpd: pam_unix(proftpd:session): session closed for user x Dec 21 06:09:39 server proftpd[22982]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - FTP session closed. I then put in a empty file in the chrooted domain: /var/www/vhosts/name/etc/security/pam_env.conf /var/www/vhosts/name/etc/environment This then shut it up but still got this error: Dec 24 19:15:56 server proftpd: pam_unix(proftpd:session): session opened for user x by (uid=0) Dec 24 19:15:56 server proftpd[19712]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - USER x: Login successful. Dec 24 19:15:56 server proftpd[19712]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - Preparing to chroot to directory '/var/www/vhosts/x.com' Dec 24 19:16:00 server proftpd: PAM audit_log_acct_message() failed: Operation not permitted Dec 24 19:16:00 server proftpd: pam_unix(proftpd:session): session closed for user x Dec 24 19:16:00 server proftpd[19712]: localhost6.localdomain6 (10.0.0.1[10.0.0.1]) - FTP session closed. So my final fix was to edit /etc/pam.d/proftpd and stop the session include system-auth
I think the "proftpd: PAM audit_log_acct_message() failed: Operation not permitted" error might be syslog related : Have you set up everything needed for syslog to work inside the chroot? IIRC you'll need at least /dev/log. If that's the problem, then it's not really a bug nor something that can be fixed inside the Fedora proftpd package... If you don't want to use any of the features PAM has to offer, maybe you could try switching to the plain "shadow" authentication in case that makes things easier inside the chroot. I'm unsure what to do to "fix" this. Would the following change in /etc/pam.d/proftpd be enough? : [...] # Comment the following line if you are having PAM issues with chrooted users session include system-auth session required pam_loginuid.so
Hi Matthias, Yes I found commenting out: # session include system-auth Does resolve this and would be nice to update the /etc/pam.d/proftpd so its done. Thanks! David
I've added that comment. I won't build/push new proftpd package just for that, so the change will appear with the next changes/updates.
I'm about to issue an update (not for F-9 though, which is now EOL) that addresses this problem in a different way, using mod_vroot. See Bug #506735 if you're interested.