This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 477120 - proftpd - PAM configuration to ensure that it can work correctly in chroot - before F8 support closed please
proftpd - PAM configuration to ensure that it can work correctly in chroot - ...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: proftpd (Show other bugs)
9
i686 Linux
low Severity urgent
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-19 03:23 EST by David
Modified: 2009-08-19 18:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-06 05:09:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David 2008-12-19 03:23:22 EST
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:
Comment 1 David 2008-12-23 16:34:53 EST
Updating to version 9 and also F10 does this too!  Only with chmod user.
Comment 2 Matthias Saou 2008-12-24 10:43:45 EST
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.
Comment 3 David 2008-12-27 04:20:51 EST
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
Comment 4 Matthias Saou 2009-01-02 08:04:15 EST
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
Comment 5 David 2009-01-03 02:15:24 EST
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
Comment 6 Matthias Saou 2009-01-06 05:09:29 EST
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.
Comment 7 Paul Howarth 2009-08-19 18:47:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.