Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???
I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line options
Ideally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'
Later it might grow into something like this:
TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
The above would require implementing JSON string escaping, but it's not difficult and pretty much the same as C string escaping everyone's familiar with (see http://json.org).
The alternatives are:
* Supplying all the possible options via separate environment variables. That would require documenting them separately.
* Having an environment variable containing command-line options instead. However, the latter would require handling word-splitting and unquoting the same way shell does, and that's non-trivial without asking an actual shell to do it. Whereas tlog already has a JSON parser.
So would the above be suitable for SSSD? Would pam_sss be OK with passing more parameters, than just the shell to start? Do you have any other ideas, objections? Please write!
Thank you.
Sincerely, Nick
On Wed, Jan 27, 2016 at 01:18:16PM +0200, Nikolai Kondrashov wrote:
Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line optionsIdeally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'
Is there a reason to pass this from pam_sss? Do you need this in the user's PAM environment?
I admit I don't know how tlog works internally, but I liked the initial idea of https://fedorahosted.org/sssd/ticket/2893 where we would specify the shell that would be wrapped by tlog. That way, we would also know we need to invoke tlog at all.
btw should tlog be configurable only globally or per-user?
Later it might grow into something like this:
TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'The above would require implementing JSON string escaping, but it's not difficult and pretty much the same as C string escaping everyone's familiar with (see http://json.org).
The alternatives are:
* Supplying all the possible options via separate environment variables. That would require documenting them separately. * Having an environment variable containing command-line options instead. However, the latter would require handling word-splitting and unquoting the same way shell does, and that's non-trivial without asking an actual shell to do it. Whereas tlog already has a JSON parser.So would the above be suitable for SSSD? Would pam_sss be OK with passing more parameters, than just the shell to start? Do you have any other ideas, objections? Please write!
Thank you.
Sincerely, Nick
[1] https://github.com/spbnick/tlog _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 01/27/2016 03:29 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 01:18:16PM +0200, Nikolai Kondrashov wrote:
Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line optionsIdeally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'Is there a reason to pass this from pam_sss? Do you need this in the user's PAM environment?
To me it seems the easiest way. We can't dictate the user shell's command-line options, we can only affect the environment. For simplicity's sake perhaps we can just give pam_sss opaque strings to put into user's environment, so it doesn't have to piece all the parameters together itself?
I admit I don't know how tlog works internally, but I liked the initial idea of https://fedorahosted.org/sssd/ticket/2893 where we would specify the shell that would be wrapped by tlog. That way, we would also know we need to invoke tlog at all.
I read the ticket then, and again now, but I'm not sure what idea you refer to. Could you please elaborate?
When we discussed this in autumn, we kind of agreed that passing the actual shell to start via an environment variable would be a good idea. Have I confused, or am I missing something?
btw should tlog be configurable only globally or per-user?
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Thanks!
Nick
On (27/01/16 15:59), Nikolai Kondrashov wrote:
On 01/27/2016 03:29 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 01:18:16PM +0200, Nikolai Kondrashov wrote:
Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line optionsIdeally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'Is there a reason to pass this from pam_sss? Do you need this in the user's PAM environment?
To me it seems the easiest way. We can't dictate the user shell's command-line options, we can only affect the environment. For simplicity's sake perhaps we can just give pam_sss opaque strings to put into user's environment, so it doesn't have to piece all the parameters together itself?
I admit I don't know how tlog works internally, but I liked the initial idea of https://fedorahosted.org/sssd/ticket/2893 where we would specify the shell that would be wrapped by tlog. That way, we would also know we need to invoke tlog at all.
I read the ticket then, and again now, but I'm not sure what idea you refer to. Could you please elaborate?
When we discussed this in autumn, we kind of agreed that passing the actual shell to start via an environment variable would be a good idea. Have I confused, or am I missing something?
btw should tlog be configurable only globally or per-user?
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP? Is somewhere described detailed info about tlog options? or maybe a design page?
LS
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
Is somewhere described detailed info about tlog options? or maybe a design page?
No design page yet. We can consider this thread the start of discussion :) The first message gives a list of possibilities.
Nick
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
LS
On 01/28/2016 12:24 PM, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
I think I understand the idea and perhaps storing configuration on a webservice is fine. However, aren't we forgoing all the management functionality LDAP provides by putting the configuration on a webservice?
I mean per-user, per-group, per-host, per-whatever configuration? Wouldn't that require reimplementing them in that webservice? I don't really know much about how that operates, and maybe that's fine, though.
Then, it just feels wrong to give the lowly recording tool the direct knowledge of and the direct access to the management system at large. Doesn't this bypass all the configuration management channels and don't we lose control here? I.e. caching, offline mode, possible local overrides, etc.?
Also, this means tlog would download this configuration on every session start, which wouldn't scale that well on hosts with many users, where sssd could cache that instead.
Still, I guess this is good enough for the start.
Nick
On (28/01/16 20:29), Nikolai Kondrashov wrote:
On 01/28/2016 12:24 PM, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
I think I understand the idea and perhaps storing configuration on a webservice is fine. However, aren't we forgoing all the management functionality LDAP provides by putting the configuration on a webservice?
I mean per-user, per-group, per-host, per-whatever configuration? Wouldn't that require reimplementing them in that webservice? I don't really know much about how that operates, and maybe that's fine, though.
Actually it would be a huge simplification. You will have many profiles/configuration available via webservice users and groups will have stored in LDAP just a name of profile/configuration. So sssd would provide names of profiel instead of compicated structured configration in tesxt (json, yaml, xml ...)
As I mentioned erarlier such appoach was discussed with GNOME team and integration with FreeIPA/sssd. Alexander Bokovoy might know more detail. Maybe it will be described in his FOSDEM presentation.
tlog can be a different use-case but it still worth to consider such approach. Especialy if we could reuse exiting code/projects from GNOME.
LS
On 01/29/2016 10:41 AM, Lukas Slebodnik wrote:
On (28/01/16 20:29), Nikolai Kondrashov wrote:
On 01/28/2016 12:24 PM, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
I think I understand the idea and perhaps storing configuration on a webservice is fine. However, aren't we forgoing all the management functionality LDAP provides by putting the configuration on a webservice?
I mean per-user, per-group, per-host, per-whatever configuration? Wouldn't that require reimplementing them in that webservice? I don't really know much about how that operates, and maybe that's fine, though.
Actually it would be a huge simplification. You will have many profiles/configuration available via webservice users and groups will have stored in LDAP just a name of profile/configuration. So sssd would provide names of profiel instead of compicated structured configration in tesxt (json, yaml, xml ...)
As I mentioned erarlier such appoach was discussed with GNOME team and integration with FreeIPA/sssd. Alexander Bokovoy might know more detail. Maybe it will be described in his FOSDEM presentation.
tlog can be a different use-case but it still worth to consider such approach. Especialy if we could reuse exiting code/projects from GNOME.
Alright, perhaps. I'll try to talk to Alexander when I have a chance and we can discuss this further on our tlog integration meeting, which we're trying to schedule.
Nick
On Fri, 29 Jan 2016, Nikolai Kondrashov wrote:
On 01/29/2016 10:41 AM, Lukas Slebodnik wrote:
On (28/01/16 20:29), Nikolai Kondrashov wrote:
On 01/28/2016 12:24 PM, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
I think I understand the idea and perhaps storing configuration on a webservice is fine. However, aren't we forgoing all the management functionality LDAP provides by putting the configuration on a webservice?
I mean per-user, per-group, per-host, per-whatever configuration? Wouldn't that require reimplementing them in that webservice? I don't really know much about how that operates, and maybe that's fine, though.
Actually it would be a huge simplification. You will have many profiles/configuration available via webservice users and groups will have stored in LDAP just a name of profile/configuration. So sssd would provide names of profiel instead of compicated structured configration in tesxt (json, yaml, xml ...)
As I mentioned erarlier such appoach was discussed with GNOME team and integration with FreeIPA/sssd. Alexander Bokovoy might know more detail. Maybe it will be described in his FOSDEM presentation.
tlog can be a different use-case but it still worth to consider such approach. Especialy if we could reuse exiting code/projects from GNOME.
Alright, perhaps. I'll try to talk to Alexander when I have a chance and we can discuss this further on our tlog integration meeting, which we're trying to schedule.
This is not covered in my talk but I'd check with GNOME guys on how far they are with Fleet Commander work to see if we can re-use it here.
On Thu, 2016-01-28 at 11:24 +0100, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
Having tlog load data over a network would make it a lot more complex and expose an attack surface. It would also fail for offline cases.
For IPA integration we will also probably want to store this data in LDAP, and not have to invent a new webservice, new authorization engine and so on and so forth.
Simo.
On 02/04/2016 09:45 AM, Simo Sorce wrote:
On Thu, 2016-01-28 at 11:24 +0100, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
Having tlog load data over a network would make it a lot more complex and expose an attack surface.
+1.
It would also fail for offline cases.
Yes. In complete loss of connectivity this is not much useful (messages wouldn't be delivered, but cached and I'm not sure what happens after space runs out), there are still cases where only the configuration server would be down.
For IPA integration we will also probably want to store this data in LDAP, and not have to invent a new webservice, new authorization engine and so on and so forth.
+1.
Nick
On (04/02/16 03:45), Simo Sorce wrote:
On Thu, 2016-01-28 at 11:24 +0100, Lukas Slebodnik wrote:
On (27/01/16 16:30), Nikolai Kondrashov wrote:
On 01/27/2016 04:17 PM, Lukas Slebodnik wrote:
You mention many options which could be possibly passed to tlog. e.g. TLOG_REC_CONF='{ "shell": "/bin/bash", "warning": "WARNING! Your session is being recorded!\n", "latency": 10, "writer": "syslog", "syslog": { "facility": "authpriv", "level": "info" } }'
Where will be these option stored? In LDAP?
No idea yet. Some of them definitely will, but likely not all.
In this case I would prefer to have the simplest change in sssd as possible. https://fedorahosted.org/sssd/ticket/2893
SSSD should just enforce using tlog as a shell and provide name of profile. This profile will be used by tlog to download configuration (json) from webservice. The similar approach was discussed with IPA integration with GNOME. IIRC there is already POC; Alexander might know more.
Having tlog load data over a network would make it a lot more complex and expose an attack surface.
What is the problem with https + webservice? We already have FreeIPA certificate on ipa enroled machines. and IIUC tlog should be mainly used with FreeIPA.
It would also fail for offline cases.
If you download complicated conffiguration via web service you would probably already save it somewhere. It will be cached. SSSD will still provide unique identifier of configuration. If it is already avialable then there's nothing to download from web service. If Server was offline then sssd would not be able to download either. I'm sorry but storing jomplicated json file in LDAP does not seems to me as the right approach. And merging complicated json files in sssd does not look to me as the ideal solution either.
LS
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
On 01/27/2016 03:29 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 01:18:16PM +0200, Nikolai Kondrashov wrote:
Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line optionsIdeally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'Is there a reason to pass this from pam_sss? Do you need this in the user's PAM environment?
To me it seems the easiest way. We can't dictate the user shell's command-line options, we can only affect the environment. For simplicity's sake perhaps we can just give pam_sss opaque strings to put into user's environment, so it doesn't have to piece all the parameters together itself?
yes, pam_sss should get SSS_PAM_ENV_ITEM messages and no do any logic on its own. See e.g. k5c_attach_ccname_msg().
bye, Sumit
I admit I don't know how tlog works internally, but I liked the initial idea of https://fedorahosted.org/sssd/ticket/2893 where we would specify the shell that would be wrapped by tlog. That way, we would also know we need to invoke tlog at all.
I read the ticket then, and again now, but I'm not sure what idea you refer to. Could you please elaborate?
When we discussed this in autumn, we kind of agreed that passing the actual shell to start via an environment variable would be a good idea. Have I confused, or am I missing something?
btw should tlog be configurable only globally or per-user?
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Thanks!
Nick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
On 01/27/2016 04:28 PM, Sumit Bose wrote:
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
To me it seems the easiest way. We can't dictate the user shell's command-line options, we can only affect the environment. For simplicity's sake perhaps we can just give pam_sss opaque strings to put into user's environment, so it doesn't have to piece all the parameters together itself?
yes, pam_sss should get SSS_PAM_ENV_ITEM messages and no do any logic on its own. See e.g. k5c_attach_ccname_msg().
Ah, cool! Thanks, Sumit :) Now we need only decide what we'll pass that way and how.
Nick
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
On 01/27/2016 03:29 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 01:18:16PM +0200, Nikolai Kondrashov wrote:
Hi everyone,
I'm starting implementing tlog [1] configuration interfaces and would like to know what you'd like to use best in SSSD.
Among tlog parameters are:
Path to the shell to start The text for the warning about the session being recorded Logging latency, seconds - how long to cache recorded data before logging Maximum log message payload, bytes Log target (file / syslog / perhaps journald later) Log target options: file: path syslog: facility level journald: ???I guess out of these only a few would be controlled by SSSD.
I'd like to have three interfaces implemented:
Configuration file in /etc, in JSON (tlog needs it anyway) Environment variable(s) Command-line optionsIdeally, all the parameters should be controllable from any of them, but the setting priority would be as above.
Our main use case for the start would require faking tlog as the shell in nss_sss, passing the real shell in pam_sss via an environment variable and letting the administrator configure the rest via the configuration file. Command-line interface would be used to support "login" asking for login shell, ssh doing the same and passing commands to execute, and testing.
Later we might want to add more parameters passed via pam_sss and environment variables.
SSSD may also choose to write the tlog config file, but I think that it's better to leave that for the administrators and only use environment variable(s) from pam_sss instead.
Regarding that, I'm actually thinking about simply accepting the same data as configuration file provides via an environment variable. I.e. in JSON. It wouldn't need to be complete, and will be overlaid on top of what was read from the configuration file. So for the start pam_sss would need to pass this, for example:
TLOG_REC_CONF='{"shell": "/bin/bash"}'Is there a reason to pass this from pam_sss? Do you need this in the user's PAM environment?
To me it seems the easiest way. We can't dictate the user shell's command-line options, we can only affect the environment. For simplicity's sake perhaps we can just give pam_sss opaque strings to put into user's environment, so it doesn't have to piece all the parameters together itself?
I admit I don't know how tlog works internally, but I liked the initial idea of https://fedorahosted.org/sssd/ticket/2893 where we would specify the shell that would be wrapped by tlog. That way, we would also know we need to invoke tlog at all.
I read the ticket then, and again now, but I'm not sure what idea you refer to. Could you please elaborate?
When we discussed this in autumn, we kind of agreed that passing the actual shell to start via an environment variable would be a good idea. Have I confused, or am I missing something?
OK, maybe I forgot this or wasn't part of the discussion.
btw should tlog be configurable only globally or per-user?
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Could the local overrides be a good way to configure the per-user attributes since the infrastructure is already there?
On 01/27/2016 04:44 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Could the local overrides be a good way to configure the per-user attributes since the infrastructure is already there?
If you mean using sss_override, then I'm not sure it will help. Although it is likely I don't understand it well.
Pam_sss should still pass the original shell to tlog, likely supplied with SSS_PAM_ENV_ITEM messages, as Sumit describes. However if it was overriden, where would we get it from? Plus, we'll still have to have custom code which will send that SSS_PAM_ENV_ITEM message.
While this is something we definitely need to solve, the main question of this thread was which way you'd like these environment variables be encoded and also if you'd like to push all the configuration through them or perhaps push some of it through the configuration file.
Do you have any preference?
Thank you.
On Wed, Jan 27, 2016 at 05:28:25PM +0200, Nikolai Kondrashov wrote:
On 01/27/2016 04:44 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Could the local overrides be a good way to configure the per-user attributes since the infrastructure is already there?
If you mean using sss_override, then I'm not sure it will help. Although it is likely I don't understand it well.
Pam_sss should still pass the original shell to tlog, likely supplied with SSS_PAM_ENV_ITEM messages, as Sumit describes. However if it was overriden, where would we get it from? Plus, we'll still have to have custom code which will send that SSS_PAM_ENV_ITEM message.
While this is something we definitely need to solve, the main question of this thread was which way you'd like these environment variables be encoded and also if you'd like to push all the configuration through them or perhaps push some of it through the configuration file.
Do you have any preference?
I was thinking we could push whether tlog is enabled at all for this user or not via the local overrides.
On 01/27/2016 06:12 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 05:28:25PM +0200, Nikolai Kondrashov wrote:
On 01/27/2016 04:44 PM, Jakub Hrozek wrote:
On Wed, Jan 27, 2016 at 03:59:10PM +0200, Nikolai Kondrashov wrote:
I guess some options would need to be configurable only globally, e.g. the latency and maximum payload. Others might be per-machine (or distro), e.g. the log target and options. And some definitely per-user, e.g. the shell.
For the start we can have only the shell configurable through sssd somehow and leave the rest to local config files. We can add the rest later, but I'm trying to prepare the tlog configuration interface for that.
Could the local overrides be a good way to configure the per-user attributes since the infrastructure is already there?
If you mean using sss_override, then I'm not sure it will help. Although it is likely I don't understand it well.
Pam_sss should still pass the original shell to tlog, likely supplied with SSS_PAM_ENV_ITEM messages, as Sumit describes. However if it was overriden, where would we get it from? Plus, we'll still have to have custom code which will send that SSS_PAM_ENV_ITEM message.
While this is something we definitely need to solve, the main question of this thread was which way you'd like these environment variables be encoded and also if you'd like to push all the configuration through them or perhaps push some of it through the configuration file.
Do you have any preference?
I was thinking we could push whether tlog is enabled at all for this user or not via the local overrides.
Hmm, provided tlog configuration is always exported via pam_sss with the actual shell (not the overriden one), this might work for the start. However, eventually, when we implement centralized configuration, this will need to change, if I understand correctly.
Nick
sssd-devel@lists.fedorahosted.org
-
Alexander Bokovoy -
Jakub Hrozek -
Lukas Slebodnik -
Nikolai Kondrashov -
Simo Sorce -
Sumit Bose