On 02/26/2016 12:37 PM, Jakub Hrozek wrote:
>On Thu, Feb 25, 2016 at 03:09:25PM +0200, Nikolai Kondrashov wrote:
>>I'd like to continue the discussion of tlog integration, and also present
you
>>the first release of tlog - a development preview, which has the configuration
>>interface necessary to implement the integration:
>>
>>
https://github.com/spbnick/tlog/releases/tag/v1
>>
>>You're more than welcome to download RPMs, install, read tlog-rec(8) and
>>tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball
>>works as well, if you're so inclined. I'm also attaching those manpages
for
>>convenience.
>
>OK, I will try to find some time to experiment with tlog, but probably
>won't happen until next week, though.
Thanks, Jakub!
>>Here are the integration plans so far, as discussed with Jakub on our
>>devconf.cz trip meetings and before on the list. Jakub, please correct me or
>>add details.
>>
>>* We follow the route similar to that taken by SELinux rule control
>> implementation [1][2]. I.e. store the configuration in LDAP HBAC rules,
>> write to files on the client side and then specify them to tlog upon user
>> login.
>
>This was an idea we had during a conversation on devconf. I think it
>would be nice to also bring this idea up with the IPA developers on the
>freeipa-devel list to get more feedback.
Alright. I need to see and understand how this works myself before I
can discuss this productively, though. So I'd better start digging into it.
It seems I'll have to implement it myself, so I'll have to know it anyway :)
>> However, I'm also rather fond of the idea of specifying the whole
>> configuration through an environment variable instead of through a file
>> referenced by an environment variable - it's not big at all, and we'll
avoid
>> the hassle of managing the files.
>>
>> I implemented support for both in tlog (was easy).
>>
>>* We'll have to make nss_sss report user's shell as tlog-rec (how?) and
>> specify the actual shell to tlog-rec via an environment variable, through
>> pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.:
>
>We already can override the user's shell on a global basis from the
>config file and on a per-user basis with local overrides (or even IPA
>overrides on an IPA client)
But we can't have these overrides configured centrally, on the IPA server?
Otherwise they won't be called "local", right? If so, then this can only
work
for a tech preview and even then it would be better to have central
configuration.
>>
>> * Nss_sss would always report tlog-rec as the user's shell.
>
>That would work with the user overrides. pam_sss would also have to pass
>on the actual user's shell if the original shell was tlog, right?
Yes.
>>
>> * During login (e.g. through "login" or "sshd") pam_sss
would add a variable
>> to the user environment, containing, or pointing at, a tlog-rec
>> configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That
>> configuration would contain the user's actual shell.
>
>Just to be clear, the user's actuall shell wouldn't be bart of the tlog
>configuration, just passed on from sssd to tlog, right?
Tlog has global configuration (/etc/tlog/tlog-rec.conf) which specifies a
shell to start. Which is /usr/bin/bash by default. However, whatever we pass
through the environment overrides that.
Sssd doesn't need to change the global configuration at all. *All* parameters
present there can be overriden through the environment variables mentioned
above.
>About the config file, should we add a sssd option to specify a tlog config?
If it's global, i.e. for all users/groups, then it doesn't make much sense, as
the sysadmin can just change the global tlog config.
>Also, can tlog fall-back to some compiled-in global config file in case
>no particular config file is needed? (Can tlog work with just the global
>config file and the user's original shell?)
Sure, it doesn't require those environment variables to be present. It will
spawn the shell specified in its global config file. However, it would have no
way of knowing what the *intended* user shell is.
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.
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..
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..