On Mon, Jun 06, 2016 at 06:24:53PM +0300, Nikolai Kondrashov wrote:
On 06/06/2016 06:20 PM, Sumit Bose wrote:
On Mon, Jun 06, 2016 at 04:24:35PM +0300, Nikolai Kondrashov wrote:
Hi everyone,
After a little discussion with Dmitri and Sumit we decided that we'll need options for controlling session recording in sssd.conf, after all.
The options should be something like this:
record_sessions - string, one of: none/some/all, default is "none" record_sessions_users - string, space-separated list of users to record record_sessions_groups - string, space-separated list of groups to record
I'm not sure where we should put them. They can't be put into "nss" or "pam" sections alone, as they concern both (nss fakes the shell, pam adds enviroment variables). I would rather put them into the global "sssd" section and have fully-qualified usernames listed there, but I see that there is very little options there otherwise, so I suspect they wouldn't be welcome. Otherwise, we can put them into domain sections, but that would mean duplicating the "record_sessions" option in every one of them, which is inconvenient.
I would suggest to put them into [nss] and let the pam responder read them form there as well. My reasoning is that the faked shell returned e.g. by 'getent passwd user_name' is the most user visible change. And if anyone is irritated by this it would be good if the options responsible for this can be found in the configuration of the related responder.
This seems reasonable from the point of figuring out where the shell came from, but if I wanted to turn the recording on, why would I look into the nss section documentation?
For some features we have a separate section in the manpages (for example for failover or ID mapping) and for some larger features we have even a separate manpage (sssd-sudo). Would either make sense for the recording?
OTOH, if we can't put them into the general "sssd" section, then "nss" is better than putting them into every domain.
Nick