On Wed, Sep 07, 2016 at 02:34:19PM +0300, Nikolai Kondrashov wrote: > On 09/07/2016 02:18 PM, Sumit Bose wrote: > > On Wed, Sep 07, 2016 at 01:28:12PM +0300, Nikolai Kondrashov wrote: > > > Hi Sumit, > > > > > > Just wanted to tell you I still need an answer to the below. > > > > ah, sorry, I think I missed this question while discussing the group > > lookups with Simo in the other thread. > > No problem, happens to everyone, thanks for answering :) > > > > Thanks! > > > > > > Nick > > > > > > On 08/19/2016 07:39 PM, Nikolai Kondrashov wrote: > > > > Now I'm again approaching the implementation of tlog integration in > > > > pam_sss, > > > > and as planned, I need to get the actual user shell to put it into > > > > TLOG_REC_SHELL environment variable upon opening of the session. > > > > > > > > However, the get_shell_override, which does all the hops and tricks to > > > > get it, > > > > requires nss_ctx, which belongs to NSS responder, specifically various > > > > shell-related configuration settings > > > > (override_shell/allowed_shells/vetoed_shells/etc_shells). I.e. > > > > essentially the > > > > PAM responder needs to be an NSS responder to get it. > > > > > > > > To me it seems that there is no exit but to finally put that override > > > > machinery into a library, instead of having it directly in the NSS > > > > responder. > > > > > > > > Am I wrong? Is there perhaps another way? > > > > Do you have any suggestion how to best do it? > > > > I would move get_shell_override() to > > src/responder/common/responder_utils.c and replace the nss responder > > context in the parameter list by a new struct which contains all the > > shell related elements currently kept directly in the nss context. This > > struct should be defined in the common responder code as well so that > > the PAM responder can use it as well and add it to its own context. > > Finally, to avoid code duplication I would put the code which reads all > > the shell related options in nss_get_config() for a new common all with > > initializes the new struct with the values from the configuration and > > add this call to pam_process_init() so that the PAM responder knows > > about the options as well. Now you should be able to call > > get_shell_override from the PAM responder as well. > > This is similar to what I had in mind. Although, I'd like to extract all the > *_override functions together in this manner, if you don't mind.
sure, please go ahead. This would it also make it easier to write unit-tests for those calls (hint, hint, hint :-). bye, Sumit > > Nick _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
