On 05/27/2016 04:24 PM, Sumit Bose wrote:
On Fri, May 27, 2016 at 02:00:12PM +0300, Nikolai Kondrashov wrote:
> On 05/26/2016 12:36 PM, Sumit Bose wrote:
>> On Mon, May 23, 2016 at 10:26:37PM +0300, Nikolai Kondrashov wrote:
>>> On 05/20/2016 02:50 PM, Sumit Bose wrote:
>>>> On Fri, May 20, 2016 at 01:54:33PM +0300, Nikolai Kondrashov wrote:
> Right. Thank you for the explanation, Sumit. I heard about ID views, but I
> didn't think they also implement overrides. IIRC, the original idea suggested
> by SSSD developers was to use local overrides only.
Basically overrides from IPA and local overrides are the same only the
data source is different. Please note that both are mutually exclusive.
On IPA clients you should define the overrides on the IPA server. In
other environments, e.g. on a AD client, local overrides can be used.
Ah, I didn't think so. What happens if I have an override from non-default
view and (try to) set local overrides at the same time? How about default
view?
> Using ID views for this actually sounds great to me. However, as
I know little
> of them, I'd like someone else to check if that will be fine regarding overall
> design and intended use.
>
> Martin, Jakub, perhaps you can comment?
>
> Otherwise, Sumit, would this kind of logic do for retrieving the actual
> (original) user shell:
>
> if ORIGINALAD_PREFIX SYSDB_SHELL is set, use it,
> else use SYSDB_SHELL
There are 2 cases to consider
1. DOM_HAS_VIEWS(domain)
This is the case where a view other than the default view is defined on
IPA or the local overrides are used. Here the override shell from the
view is OVERRIDE_PREFIX SYSDB_SHELL. So if tlog is activated this
attribute should contain /bin/tloc-rec. The original/default shell can
be found in SYSDB_SHELL in this case (it can be empty). If, in the IPA
case, tlog is activated in the default view of the user as well,
SYSDB_SHELL will contain /bin/tloc-rec as well. In this case you have to
look at ORIGINALAD_PREFIX SYSDB_SHELL which contains the shell read from
AD or is empty. As mentioned before /bin/sh should be used in the shell
is still empty after processing the shell related SSSD options.
2. !DOM_HAS_VIEWS(domain)
This is the default case, i.e. no IPA view or local override is applied.
But there still might be an override in the IPA default view. So you
should still check if SYSDB_SHELL contains /bin/tloc-rec in this case
and tlog is activated. If it is, you can find the shell from AD in
ORIGINALAD_PREFIX SYSDB_SHELL. As before if this is empty, process SSSD
options and finally replace a still empty shell with /bin/sh.
I think it would be good to set the environment variable only if tlog is
activated for the user. Otherwise people will start asking sooner or
later why we set the variable unconditionally. If you call the
unmodified version of get_shell_override() it should return the
/bin/tloc-rec if tlog is activated. If you now call get_shell_override()
where instead of
user_shell = sss_view_ldb_msg_find_attr_as_string(dom, msg, SYSDB_SHELL, NULL);
if (!user_shell) {
....
you call
if (tlog_mode) {
user_shell = ldb_msg_find_attr_as_string(dom, msg, SYSDB_SHELL, NULL);
if (user_shell != NULL && strcmp(user_shell, "/bin/tloc_rec")
== 0) {
user_shell = ldb_msg_find_attr_as_string(dom, msg, ORIGINALAD_PREFIX SYSDB_SHELL,
NULL);
}
} else {
user_shell = sss_view_ldb_msg_find_attr_as_string(dom, msg, SYSDB_SHELL, NULL);
}
if (!user_shell) {
/* Check whether there is a default shell specified */
if (dom->default_shell) {
return talloc_strdup(mem_ctx, dom->default_shell);
} else if (nctx->default_shell) {
return talloc_strdup(mem_ctx, nctx->default_shell);
}
if (tlog_mode) {
return talloc_strdup(mem_ctx, "/bin/sh");
} else {
return NULL;
}
}
it should basically do what I tried to describe above.
First of all, thank you Sumit for continuing to explain everything to me so
patiently, and in detail :)
I think I understand better how this works and what you mean now.
I'll try to summarize where the shell can be stored, please correct me if I'm
wrong:
Shell is specified in Shell is stored in
--------------------------- -------------------------------------------
Account SYSDB_SHELL / ORIGINALAD_PREFIX SYSDB_SHELL
Default view SYSDB_SHELL
Other view/local override OVERRIDE_PREFIX SYSDB_SHELL
Now, first thing, is I don't want to add any kind of shell value
interpretation, i.e. to check whether the shell is tlog or not. This would
overload the meaning of the shell value, be too "magic" and surprising for
admins, plus it wouldn't account for tlog-rec being installed somewhere else,
or under a different name. It would be a quirky feature, basically a
heuristic, and heuristics are always hard to get right and maintain. And once
we implement it, I'm afraid we'll have to keep it around, making SSSD code
even more complex.
It is also apparent to me now, that the override stack is complex and adding
another feature on top of it would be burdensome. Both for developers to
maintain and for admins to understand.
If we're going to implement tlog-rec activation using overrides, I'd rather
have only the last level supported. I.e. other view/local override, which
would only require passing SYSDB_SHELL to tlog-rec (if I understood everything
right). An argument against also employing default view can be that its
intended use is not to override, but to augment AD data, AFAIK.
Regarding adding the environment variable only when needed, I agree that its
appearance will raise questions. One option can be adding it only if the shell
is overriden. I.e. if SYSDB_SHELL != OVERRIDE_PREFIX SYSDB_SHELL. Another
option can be to add an explicit configuration variable enabling that, with
proper documentation and everything.
However, another question here is what we're going to do with that feature
when the intended central configuration mechanism is implemented? Are we going
to remove it, or are we going to be stuck with it forever?
The final and ultimate alternative can be forgoing SSSD changes altogether for
the initial implementation of Session Recording. I plan to implement getting
the shell to start from the argv[0] tlog-rec was invoked with. I.e.
Symlink to tlog-rec Shell to be invoked by tlog-rec
----------------------- -------------------------------
tlog-rec-shell-bash bash
tlog-rec-shell-zsh zsh
tlog-rec-shell-csh csh
etc.
This way the sysadmins will not be able to pass the actual user shell to
tlog-rec, but will override it by specifying one of the shells above. However,
how many people actually use other shells, and what prevents them from putting
their favorite shell to the specified shell's rc files, if necessary?
Alternatively, admins can add specific views for those few users.
This can be good enough for the start.
Nick