Bug 951728

Description of problem:
Jason Burgess noticed (in https://bugzilla.redhat.com/show_bug.cgi?id=809214#c30) the following messages in system logs:

Apr 11 23:12:28 localhost dbus[594]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.174" (uid=505 pid=6971 comm="proftpd: ftpuser- 192.168.1.10: IDLE") interface="org.freedesktop.login1.Manager" member="ReleaseSession" error name="(unset)" requested_reply="0" destination="org.freedesktop.login1" (uid=0 pid=578 comm="/usr/lib/systemd/systemd-logind ")

Note that logind's DBus method ReleaseSession is called from pam_systemd's pam_sm_close_session implementation.

So the error message tells us that a proftpd process tried to close a PAM session (i.e. by calling pam_session_close()) while running as a user other than root (uid=505).

This is incorrect use of PAM by proftpd. Both pam_open_session() and pam_close_session() must be called as root and in the same process.

Version-Release number of selected component (if applicable):
proftpd-1.3.4c-1.fc18

How reproducible:
always

Steps to Reproduce:
1. Start proftpd using the package's default config.
2. Login into FTP as a user, then log out.
3. journalctl -b | grep Reject
  
Actual results:
The above error message proving that pam_close_session was called by unprivileged process.

Expected results:
No error message. PAM session correctly closed.

Additional info:
From looking at proftpd sources I found that proftpd works roughly like this:

accept()
fork()
in the child {
    pam_auth() { /* in mod_auth_pam */
       pam_open_session()
    }
    drop privileges

    ...work..

    auth_pam_exit_ev() {  /* in mod_auth_pam */
       PRIVS_ROOT  /* tries to regain root privileges */
       pam_close_session()
    }
}

PRIVS_ROOT does not have the desired effect because session.disable_id_switching is set. It is set by mod_cap. This leads us to an ugly but effective workaround: Use "CapabilitiesEngine off" in the config file to disable mod_cap.

A proper fix should likely consist of adding another fork(), where the parent would open the PAM session, wait for the child to exit, then close the session. The child would drop privileges and would never have to regain them.

This view on using PAM sessions is supported for example by:
Tomáš Mráz, the PAM maintainer, in an old discussion about a similar issue in OpenSSH:
https://bugzilla.mindrot.org/show_bug.cgi?id=926#c21
Lennart Poettering, more recently about PAM handling in xrdp:
https://bugzilla.redhat.com/show_bug.cgi?id=821569#c23