On 02/01/2017 10:39 AM, 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.

The patch uses wrong function, please use cache_req_initgroups_by_name(). (I'm sorry I didn't notice this earlier, I really barely read it in the private mail).


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

The timeout is there to ensure that we don't go to id provider too often (default 5 seconds) since PAM prefer to always go there and does not obey entry expiration time.

The whole point of this is to perform initgroups to refresh user's membership, we are not interested in the result.

The most generic solution here is to give cache_req the ability (parameter) to choose whether we wan't to go to data provider first and ignore expiration time and make the caller responsible for this decision.

The seconds solution is to create new initgroups plugin for PAM with bypass_cache = true and decide in PAM if it is called or not.

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.

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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to