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.
What do you think about any of the above?
Thanks!
Nick
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 recordI'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.
bye, Sumit
What do you think about any of the above?
Thanks!
Nick
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 recordI'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?
OTOH, if we can't put them into the general "sssd" section, then "nss" is better than putting them into every domain.
Nick
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 recordI'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
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, defaultis "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
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, defaultis "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"
and add a section to sssd.conf(5), or a new manpage, e.g. sssd-session-recording(5)?
Nick
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, defaultis "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"and add a section to sssd.conf(5), or a new manpage, e.g. sssd-session-recording(5)?
So it can be, for example:
[session_recording] scope = selected users = john mary groups = sysops
Nick
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, defaultis "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 = sysopsNick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 06/07/2016 02:45 PM, Pavel Březina wrote:
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.
Ah, OK, that's also fine.
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.
Alright, we can start with a section in sssd.conf(5) and if it grows, move it to a separate page.
But yes, I think creating a new section is much better.
Great! I like it too, although it feels a bit like an overkill for just these three options. Let's see what others will say.
Nick
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Nikolai Kondrashov -
Pavel Březina -
Sumit Bose