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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org