On 06/07/2016 01:39 PM, Nikolai Kondrashov wrote:
On 06/07/2016 02:29 PM, Nikolai Kondrashov wrote:
> On 06/07/2016 11:16 AM, Pavel Březina wrote:
>> 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].
>
> Alright, how about we introduce a new section in the configuration file,
> put these options into it:
>
> [session_recording]
> scope - string, one of: none/selected/all, default is "none"
> users - string, space-separated list of users to record,
> only valid if "scope = selected"
> groups - string, space-separated list of groups to record,
> only valid if "scope = selected"
I think we mostly use comma-separated list in sssd.
> and add a section to sssd.conf(5), or a new manpage, e.g.
> sssd-session-recording(5)?
It depends on the amount of information... If there will be lots of text
on the session recording than I think it would be better as an
individual man page otherwise we'll fine with sssd.conf section.
But yes, I think creating a new section is much better.
So it can be, for example:
[session_recording]
scope = selected
users = john mary
groups = sysops
Nick
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org