Hi Sumit,
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?
Thanks a lot!
Nick
Hi Sumit,
Just wanted to tell you I still need an answer to the below.
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?
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.
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.
HTH
bye, Sumit
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.
Nick
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
On 08/19/2016 06:39 PM, Nikolai Kondrashov wrote:
Hi Sumit,
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.
All of these seems to be just simple sssd.conf options, feel free to get them with confdb api. See nss_get_config().
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.
This would be awesome though :-)
On 09/07/2016 01:48 PM, Pavel Březina wrote:
On 08/19/2016 06:39 PM, Nikolai Kondrashov wrote:
Hi Sumit,
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.
All of these seems to be just simple sssd.conf options, feel free to get them with confdb api. See nss_get_config().
Well, these are not only options, but also logic that interprets them, and I don't want to essentially copy the corresponding code from NSS responder to PAM responder.
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.
This would be awesome though :-)
Yes, I would like that too, but I'd like to wait for Sumit's response :)
Nick
sssd-devel@lists.fedorahosted.org
-
Nikolai Kondrashov -
Pavel Březina -
Sumit Bose