On 06/06/2016 05:24 PM, 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?
We don't need to keep our hands tied, we can also introduce new section
e.g. [tlog] or [session].
OTOH, if we can't put them into the general "sssd" section, then
"nss" is
better than putting them into every domain.
Nick