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