On Wed, Jul 23, 2014 at 03:38:13PM +0200, Jakub Hrozek wrote:
==== PAM responder ====
The PAM responder can drop privileges after startup. The files that the PAM
responder reads (sysdb, confdb, PAM public pipe) and writes (debug logs,
PAM pipe) will be owned by the sssd user.
In order to keep the privileged pipe only owned by the root user, we
would open the pipe prior to becoming user and pass the file descriptor.
As we're testing the patches with Michal, we realized one thing that
I didn't check when creating the design.
The pam_sss.so module explicitly checks if the PAM pipe (private or not)
is owned by UID 0. Because we initially wanted to let the non-private
PAM pipe be owned by the SSSD user, this check fails. Please note the
public pipe has permissions 0666, so the ownership doesn't matter that
much, 'others' are always allowed to read and write to the pipe.
So we have two options:
1) Let the public PAM pipe be owned by root and create it prior to
dropping privileges
+ No changes to the client code
- a bit messy responder initialization where the PAM responder
would create both pipes itself. All other responders could
still rely on the shared setup code.
2) Extend the check in the PAM module so that both UID 0 and UID of
the SSSD user are allowed.
+ Nicer responder code
- Touches client code. Please note that I'm not sure if PAM
modules are loaded on every PAM conversation or not. If they
stay loaded for the duration of the application (like the NSS
module), then this option is not viable at all.
Thanks for your opinions.