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
