[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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.
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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.
--
/ Alexander Bokovoy
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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. ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 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"}'
> >
> >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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 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"}'
> >
> >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?
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 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"}'
>>
>>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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 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"}'
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: Configuring tlog from SSSD
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 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"}'
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
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
