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
> > > 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
> > > 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
> > > 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
> > >
> > > 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 :-).