Bug 506735 - PAM audit_log_acct_message() failed: Operation not permitted
PAM audit_log_acct_message() failed: Operation not permitted
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: proftpd (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
http://bugs.proftpd.org/3257
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-18 10:25 EDT by Matt Castelein
Modified: 2009-09-24 01:09 EDT (History)
2 users (show)

See Also:
Fixed In Version: 1.3.2a-5.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-24 01:09:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proftpd configuration (4.07 KB, text/plain)
2009-08-19 11:20 EDT, Matt Castelein
no flags Details

  None (edit)
Description Matt Castelein 2009-06-18 10:25:05 EDT
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
Comment 1 Paul Howarth 2009-06-25 11:12:08 EDT
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?
Comment 2 Matthias Saou 2009-06-25 11:20:04 EDT
(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.
Comment 3 Paul Howarth 2009-06-26 10:32:10 EDT
I've submitted the patch upstream (http://bugs.proftpd.org/3257) and am working on the Fedora package now.
Comment 4 Paul Howarth 2009-07-29 04:08:02 EDT
Matthias, any comments on the proposed changes I emailed to you?
Comment 5 Matthias Saou 2009-07-30 05:08:28 EDT
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!
Comment 6 Paul Howarth 2009-07-30 07:17:49 EDT
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.
Comment 7 Fedora Update System 2009-08-03 11:31:27 EDT
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
Comment 8 Matt Castelein 2009-08-03 11:49:17 EDT
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.
Comment 9 Paul Howarth 2009-08-03 12:08:39 EDT
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.
Comment 10 Fedora Update System 2009-08-04 20:40:17 EDT
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
Comment 11 Matt Castelein 2009-08-06 11:27:19 EDT
(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?
Comment 12 Paul Howarth 2009-08-06 12:14:33 EDT
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?
Comment 13 Matt Castelein 2009-08-06 13:44:13 EDT
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.
Comment 14 Paul Howarth 2009-08-19 09:14:59 EDT
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
Comment 15 Matt Castelein 2009-08-19 10:07:14 EDT
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'
Comment 16 Paul Howarth 2009-08-19 10:11:41 EDT
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.
Comment 17 Matt Castelein 2009-08-19 10:19:25 EDT
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.
Comment 18 Paul Howarth 2009-08-19 10:32:36 EDT
I think you need to look in /var/log/audit/audit.log and /var/log/secure as well as /var/log/messages.
Comment 19 Matt Castelein 2009-08-19 10:39:08 EDT
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.
Comment 20 Paul Howarth 2009-08-19 11:04:41 EDT
Is this with the same account as before in Comment #15? And you have the vroot bits in proftpd.conf?
Comment 21 Matt Castelein 2009-08-19 11:15:36 EDT
It's the same account.. vroot? no, you're saying I need to change my config?  Is this a fix or a workaround?
Comment 22 Matt Castelein 2009-08-19 11:20:03 EDT
Created attachment 357952 [details]
proftpd configuration
Comment 23 Paul Howarth 2009-08-19 11:21:54 EDT
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.
Comment 24 Matt Castelein 2009-08-19 11:26:15 EDT
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.
Comment 25 Fedora Update System 2009-08-19 18:48:55 EDT
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
Comment 26 Fedora Update System 2009-08-20 17:02:52 EDT
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
Comment 27 Fedora Update System 2009-09-02 07:08:10 EDT
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
Comment 28 Fedora Update System 2009-09-02 20:30:22 EDT
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
Comment 29 Fedora Update System 2009-09-07 11:03:15 EDT
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
Comment 30 Fedora Update System 2009-09-08 21:49:35 EDT
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
Comment 31 Fedora Update System 2009-09-24 01:09:35 EDT
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.

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