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
> 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
> 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
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.
> Thank you.