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?
Thank you.
Nick
_______________________________________________
sssd-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
