I'm getting error messages in my logwatch: PAM audit_log_acct_message() failed: Operation not permitted Not sure what causes that but I don't remember seeing them before. proftpd-1.3.2-2.fc11.x86_64
I bet you're also seeing something along the lines of this: kernel: warning: `proftpd' uses 32-bit capabilities (legacy support in use) in /var/log/messages at proftpd startup time. There's a combination of things at work here. The PAM configuration for proftpd includes pam_loginuid, which attempts to log an entry to the audit log when anybody logs in. However, this requires the CAP_AUDIT_WRITE capability, which is dropped by default in proftpd (see the mod_cap documentation), hence you get the "Operation not permitted" message. So, to stop getting the message, you could either disable pam_loginuid from the proftpd PAM configuration, or you could disable the capabilities engine in proftpd: <IfModule mod_cap.c> CapabilitiesEngine off </IfModule> However, neither of these options is a good one. I have a patch I wrote some time ago that supports the retention of CAP_AUDIT_WRITE: http://trac.city-fan.org/cfo-trac/browser/proftpd/trunk/proftpd-1.3.0a-cap_audit_write.patch This works in conjunction with a configuration snippet like this: <IfModule mod_cap.c> CapabilitiesEngine on CapabilitiesSet +CAP_AUDIT_WRITE </IfModule> Patching the code and the default config should fix this issue. As for the warning about using 32-bit capabilities, this is due to a missing build requirement in the proftpd package of libcap-devel, which results in proftpd being built using the bundled version of libcap (1.5) rather than the system version (2.16), which wouldn't present this problem. Matthias, would you mind if I became co-maintainer of proftpd and fixed these issues up?
(In reply to comment #1) > Matthias, would you mind if I became co-maintainer of proftpd and fixed these > issues up? I wouldn't mind the least! Ask for the changes you'd like in the pkgdb and I'll be sure to accept them all.
I've submitted the patch upstream (http://bugs.proftpd.org/3257) and am working on the Fedora package now.
Matthias, any comments on the proposed changes I emailed to you?
As much as I dislike tabs-based indentation, everything in the spec looks sane and the %changelog very complete. I haven't looked at the default configuration file nor tested the package itself, I'll trust you on those. Feel free to apply all of those changes at least to devel for now. For all of the existing setups, I don't see anything at a first glance which could break badly, but you never know... Thanks a lot for your work!
I'm using this package in production right now on F-11 (i386) and EL-5 (x86_64) so I'm confident it at least basically works. Rawhide build is now done, and I'm inclined to build and push to testing updates for F-11 (for #506735 i.e. this bug), F-10 (for #509251), and EL-5 (for #498375). They can linger in testing for a good while unless they gets lots of positive karma.
proftpd-1.3.2a-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-2.fc11
Tried this update and I don't see the "legacy support" message anymore.. FTP session looks like this: Aug 3 11:40:46 arturo proftpd: pam_unix(proftpd:session): session opened for user xxxx by (uid=0) Aug 3 11:40:46 arturo proftpd[21383]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - USER xxxx: Login successful. Aug 3 11:41:04 arturo proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory Aug 3 11:41:04 arturo proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0 Aug 3 11:41:04 arturo proftpd: pam_unix(proftpd:session): session closed for user xxxx Aug 3 11:41:04 arturo proftpd[21383]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - FTP session closed. Anything to be done about these "Unable to open config file" or "error retrieving information about user 0" messages? Despite the message that /etc/security/pam_env.conf does not exist, it does in fact exist.
That looks rather like Bug #477120. Not convinced that commenting out the session part of the PAM file is the right thing to do but I'll have to think about that.
proftpd-1.3.2a-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8299
(In reply to comment #9) > That looks rather like Bug #477120. Not convinced that commenting out the > session part of the PAM file is the right thing to do but I'll have to think > about that. That bug was already supposedly fixed in F9, so is this a regression, or a new bug?
Well, it's not fixed out of the box. There's a comment in the PAM config file to comment out the session line if you're having issues with chroot. However, given that we have DefaultRoot on by default, this is an inconsistency (and it's been this way forever really). So we should either disable DefaultRoot by default, or comment the session line by default - but which one? I'm inclined to disable DefaultRoot. Thoughts?
Personally, I use DefaultRoot for normal user accounts to chroot into each users' home. I suppose I could use something other than PAM or just ignore the messages. I just don't like to see things not working as intended, that's all.
OK, new approach. This time I'm using mod_vroot to map /etc/security/pam_env.conf into the chroot. Works for me; can you give it a try? http://koji.fedoraproject.org/koji/taskinfo?taskID=1614603
Looks good... No errors. Aug 19 10:04:47 arturo proftpd[6694]: arturo - ProFTPD 1.3.2a (maint) (built Wed Aug 19 09:05:23 EDT 2009) standalone mode STARTUP Aug 19 10:04:51 arturo proftpd[6697]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - FTP session opened. Aug 19 10:04:55 arturo proftpd[6697]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - Preparing to chroot to directory '/home/xxxxxxxxx'
The errors actually came at session close time, not shown in your log snippet, but as I said, it works for me. If you can confirm that session close works OK and there's no other issues, I'll prepare a real update.
Hmm.. Actually I gave you everything it wrote. You're right, it used to log lines like: messages-20090809:Aug 3 14:45:10 arturo proftpd[3660]: arturo (::ffff:69.55.70.37[::ffff:69.55.70.37]) - FTP session closed. ..But it's not doing that anymore.
I think you need to look in /var/log/audit/audit.log and /var/log/secure as well as /var/log/messages.
Spoke too soon: Aug 19 10:17:06 arturo proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory Aug 19 10:17:06 arturo proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0 Aug 19 10:17:06 arturo proftpd: pam_unix(proftpd:session): session closed for user xxxx Aug 19 10:17:06 arturo proftpd[7684]: arturo (::ffff:192.168.1.18[::ffff:192.168.1.18]) - FTP session closed.
Is this with the same account as before in Comment #15? And you have the vroot bits in proftpd.conf?
It's the same account.. vroot? no, you're saying I need to change my config? Is this a fix or a workaround?
Created attachment 357952 [details] proftpd configuration
The plan is to change this bit in proftpd.conf: # Cause every FTP user except adm to be chrooted into their home directory DefaultRoot ~ !adm to this: # Cause every FTP user except adm to be chrooted into their home directory # Aliasing /etc/security/pam_env.conf into the chroot allows pam_env to # work at session-end time (http://bugzilla.redhat.com/477120) VRootEngine on DefaultRoot ~ !adm VRootAlias etc/security/pam_env.conf /etc/security/pam_env.conf Whether it's a fix or a workaround is debatable. I'd say it was a better workaround than commenting out the "session include system-auth" line from the proftpd PAM config.
OK, sorry I missed that bit. Things look good now: Aug 19 11:24:57 arturo proftpd: pam_unix(proftpd:session): session opened for user xxxx by (uid=0) Aug 19 11:24:57 arturo proftpd[14589]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - USER xxxx: Login successful. Aug 19 11:24:59 arturo proftpd: pam_unix(proftpd:session): session closed for user xxxx Aug 19 11:24:59 arturo proftpd[14589]: arturo (::ffff:127.0.0.1[::ffff:127.0.0.1]) - FTP session closed.
proftpd-1.3.2a-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-3.fc11
proftpd-1.3.2a-3.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-8810
proftpd-1.3.2a-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-4.fc11
proftpd-1.3.2a-4.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9234
proftpd-1.3.2a-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-5.fc11
proftpd-1.3.2a-5.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9394
proftpd-1.3.2a-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.