On 06/08/2015 05:01 PM, Sam Varshavchik wrote:
> That's another option. If that's all that pam session is used for, is to
> invoke the pam_mkhomedir.so module, this should work.
That's probably not a great idea while the pam configurations include
system-auth. It's standard setup on CentOS 7 looks like:
session optional pam_keyinit.so revoke
I don't understand the kernel keyring system entirely, but I think this
will connect authdaemond to the user's login keyring if one exists. The
documentation doesn't indicate if this connection is closed.
authdaemond might end up with a persistent connection to user data.
session required pam_limits.so
This will cause authdaemond to get whatever limits are configured for
the user who logs in. close() won't revert that change.
-session optional pam_systemd.so
The docs for pam_systemd make this look expensive, if nothing else.
session [success=1 default=ignore] pam_succeed_if.so
service in crond quiet use_uid
session required pam_unix.so
Logs that the user logged in/out.
session optional pam_sss.so
Docs don't indicate what this module does for session.
It might work better if authdaemond forked and ran the session bits in
the child process? But especially with systemd, it's worth benchmarking
the number of auth calls / second authdaemond can handle with and
without the session calls.
------------------------------------------------------------------------------
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
