On Wed, Dec 07, 2016 at 01:39:54PM +0200, Nikolai Kondrashov wrote: > On 08/30/2016 02:21 PM, Sumit Bose wrote: > > On Mon, Aug 29, 2016 at 05:18:58PM -0400, Simo Sorce wrote: > > > On Mon, 2016-08-29 at 22:47 +0200, Sumit Bose wrote: > > > > About Simo's concern. If there are groups defined in the > > > > session_recording configuration you look up those groups with > > > > cache_req_group_by_name_send(). As long as the groups are in the cache > > > > and not expired they are returned directly from the cache. I think > > > > this lookup cannot be avoided because in theory the groups name, be it > > > > the original name or an override name, might change. And you want to > > > > be sure that the name listed in the configuration is still a valid > > > > group name. > > > > > > My concern is that an initgroups call can be quite expensive in certain > > > domains where a user is a member of many groups. > > > If we really want to check memberships based on session recording > > > configuration *at query time* rather than at storing time, I would think > > > it would be more efficient to resolve only the group memberships of the > > > groups listed in the session recording configuration, and then check if > > > the user is member of any of those groups. > > > > > > Given in general this kind of access is geared toward auditing the work > > > of small groups of people (admins with root access or similar), it would > > > probably be more efficient than calling initgroups, as it will end up > > > pulling a less data, less often. > > > > > > If session recording is invoked often those groups will be cached so > > > very few lookups would be made even if many different users log into the > > > system. If you call initgroups instead you may end up updating several > > > dozen groups for each user login. > > > > > > What do you think ? > > > > I share your concerns but I think we are between a rock and a hard place > > here. For AD e.g. I think we have quite a efficient way to do initgroups > > with the tokenGroups request and hopefully will have the PAC with > > S4U2Self soon. Group lookups on AD might be more costly due to nested > > groups. > > > > Additionally we have to take the ignore_group_members options into > > account which might be enabled in environments with a larger number of > > users and groups. > > > > As mentioned in my previous mail I would recommend to only do an > > initgroups request to the backend if SYSDB_INITGR_EXPIRE is exprired and > > not the user entry (SYSDB_CACHE_EXPIRE). Currently the timeout for both > > is configured with entry_cache_user_timeout. But we can add an option > > which would allow to set a higher timeout to SYSDB_INITGR_EXPIRE so that > > initgroups in the backend is called more rarely. This might mitigate the > > situation a bit. > > > > Unfortunately we cannot rely on the forced initgroups request we do > > during authentication because "all" applications (I haven't checked all > > but it is a very typical pattern) call getpwnam() first and then call > > pam_authenticate(). And chances are high that they just use the shell > > returned by this getpwnam(). > > > > While thinking about it a session recording attribute in the user entry > > as you suggested might help in the following way (maybe this is even > > what you suggested but I didn't understood it while reading :-): > > > > - attribute present: > > * getpw* requests in the NSS responder will return the result > > according to the value of the attribute > > * only initgroups requests will update the attribute > > - attribute not present: > > * all requests will set the attribute but only if SYSDB_INITGR_EXPIRE > > is expired a plain user request is replaced by an initgroups > > request to the backends > > > > I would prefer that the handling of this attribute happens in the NSS > > responder because I think the backends should not be aware of this > > "application specific" attribute. > > > > So only the first getpwnam() for a user might have extra costs (besides > > the refresh of the session recording groups which should typically be > > covered by the mid-point refresh). > > > > What do you think? > > Simo, I know this was a long time ago, but could you please answer Sumit? > > AFAIU, he suggests we don't change the approach in general, but only do > replace a user info request with initgroups if SYSDB_INITGR_EXPIRE has > elapsed. > > Sumit, I like your suggestion regarding the attribute, but what we're going to > do with local overrides? E.g. what if a group listed in the groups to record > was renamed locally? How would it work?
Local overrides are treated in the same way as the non-default IPA overrides. So there should be not difference handling them. bye, Sumit > > Thank you. > > Nick _______________________________________________ sssd-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
