On 03/04/2016 12:54 PM, Jakub Hrozek wrote:
I was playing with tlog yesterday and for the 'local configuration' I
suggest we start small and avoid adding too many options, because we'd
have to support them for a long time.

Agreed.

It seems to me that all the options except the user's shell could just
be set in the global tlog configuration. Maybe, if some users complain
that they would like some per-user configs, tlog could offer a
/etc/tlog.d directory where a file named after the user would override
some settings, but I wouldn't go there before we hear some demand
myself..

Yes, I wouldn't like tlog to have that kind of mechanism. At least not until
we get feedback from users about how they would prefer to use it.

I was even wondering if it wasn't easiest to always set the original
shell as a PAM env variable if a shell is overriden? If we did that, we
could just use the existing options to override the shell either
globally for all users or using the local overrides. If we don't want to
set the env variable always, we could special-case tlog-rec, but I'm not
a big fan of special-casing..

I too would prefer to have an env variable set always than have a special
case. I.e. it would require setting TLOG_REC_CONF_TEXT to:

    {"shell": "ACTUAL_JSON_ESCAPED_USER_SHELL"}

As an alternative I can add support for a TLOG_REC_SHELL variable which value
wouldn't need escaping. Perhaps I'll do that in any case as it can be useful
for others.

If having users local-override the shell to tlog-rec is suitable for the
configuration approach for the start, then that should work.

Nick
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

Reply via email to