On 02/01/2017 11:41 AM, Sumit Bose wrote:
On Wed, Feb 01, 2017 at 10:39:07AM +0100, Fabiano Fidêncio wrote:
> I've done a first WIP patch for this matter but Jakub pointed out the
> approach is not correct as the PAM doesn't use the cache the same way
> as other responders do.
>
> Differently from the other responders, PAM tries to conatct the Data
> Provider on almost every request.
>
> Looking at the code, what's done is:
> - While looping the domains in pam_check_user_search():
> - call pam_initgr_check_timeout()
> - in case the timeout is still valid:
> - get the entry from sysdb
> - otherwise
> - call the data provider first
>
> As the using cache_req code for PAM responder has two main goals
> (decrease code duplicaton and make it possible to log in with a
> shortname to a trusted domain) Jakub suggested to, maybe write a new
> cache_req plugin (specifically for PAM?) and decrease the number of
> duplicated code by just reusing this new code from cache_req.
>
> The main reason behind his idea is that he thinks we want to keep the
> pam_initgr_check_timeout() while looping the domains in the cache_req
> code.
Would it be possible to manage the hash table used by
pam_initgr_check_timeout() and friends outside of the cache_req code and
add some new _FORCE cache_req types like CACHE_REQ_INITGROUPS_FORCE
which can be used by the PAM responder if the given user in not in hash
table anymore?
What I have in mind:
Prerequisites:
1) PAM manages the hash table with timeouts it self, no change here. It
uses logon name as key.
2) Cache_req has the ability to talk to dp first per caller decision
(already there as plugin decision)
Changes in cache_req:
1) Add bypass_cache parameter into cache_req_data and create a setter
for it.
2) Alter cache_req_search_send:281
if (!cr->plugin->bypass_cache) { --> if (!cr->plugin->bypass_cache
&&
!cr->data->bypass_cache) {
Changes in PAM:
1) Call cache_req initgroups
2) If timeout is not set, set data->bypass_cache = true (talk dp first)
3) If timeout is set, set data->bypass_cache = false (search cache first)
bye,
Sumit
>
> So, as I'm not that much familiar with none of those two pieces of
> code ... I'd like to know what's Pavel Březina opinion on these ideas.
>
> Best Regards,
> --
> Fabiano Fidêncio
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
_______________________________________________
sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org