[sssd PR#671][opened] PAM: use PKCS#11 URIs to restrict certificate selection
by sumit-bose
URL: https://github.com/SSSD/sssd/pull/671
Author: sumit-bose
Title: #671: PAM: use PKCS#11 URIs to restrict certificate selection
Action: opened
PR body:
"""
With the new option 'p11_uri' to the PAM responder can be used to restrict the
selection of certificates in p11_child with the help of a PKCS#11 URI.
The implementation of for the NSS version of p11_child is not available in this
PR. As you can see in the first patch the support for PKCS#11 URIs in NSS is
limited and I have to talk to NSS developers first if this will change of if it
would make more sense to use the PKCS#11 URI calls form libp11kit for the NSS
version as well.
To avoid rebase issues this PR is already on top of PR#668.
Related to https://pagure.io/SSSD/sssd/issue/3814
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/671/head:pr671
git checkout pr671
5 years, 6 months
[sssd PR#664][opened] pep8: Ignore W504 and W605 to silence warnings on Debian
by jhrozek
URL: https://github.com/SSSD/sssd/pull/664
Author: jhrozek
Title: #664: pep8: Ignore W504 and W605 to silence warnings on Debian
Action: opened
PR body:
"""
This code:
pkcs11_txt.write("library=libsoftokn3.so\nname=soft\n" +
"parameters=configdir='sql:" + config.ABS_BUILDDIR +
"/../test_CA/p11_nssdb' " +
"dbSlotDescription='SSSD Test Slot' " +
"dbTokenDescription='SSSD Test Token' " +
"secmod='secmod.db' flags=readOnly)\n\n")
pkcs11_txt.close()
Was producing warnings such as:
./src/tests/intg/test_pam_responder.py:143:22: W504 line break after binary operator
Even though it looks OK visually and conforms to pep8's written form.
Additionaly, this regular expression compilation:
Template = re.compile(
' *<template name="(\S+)">(.*?)</template>\r?\n?',
re.MULTILINE | re.DOTALL
)
Was producing a warning such as:
./src/sbus/codegen/sbus_Template.py:156:29: W605 invalid escape sequence '\S'
Since the \S literal is part of a regular expression, let's suppress
this warning as well.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/664/head:pr664
git checkout pr664
5 years, 6 months
RFC: Setting ignore_group_members=true by default
by Jakub Hrozek
Hi,
this proposal might be controversial, but I think a little discussion wouldn’t hurt :-)
tl;dr: I propose we switch the default value of ignore_group_members from False to True by default
For anyone not intimate with SSSD options, this would appear all groups to be effectivelly empty. The effect that the end user sees is that the group resolution is very fast, because only the group object, not the members have to be processed. As part of my dayjob, I’m involved in triaging RH customer cases and many of them are about performance. Ignoring the group members is quite often the first step and quite a few people are using that in production.
The reason I’m proposing this is that many calls, like getgr* issued by different command line utilities (id, ls -l, …) typically only care about the GID-to-name translation. At the same time, the list of group members is both inaccurate (because we stop at a deep enough group nesting) and really not needed except for an admin to quickly see what members belong to a group. For access control, what is really used is the result of initgroups/getgroupslist. This is the call where we care about precision, because the list of groups the user is a member of can only be set during login. But getgr* returns the list of users who are members of a group and is not really required to be precise.
Returning the full list of group members from getgr* by default is very time consuming and inefficient. While we did a lot of work on the SSSD side to speed things up, like using the timestamps cache and only actually save something to the database when the object changes and we have even more ideas floating around (e.g. don’t parse the whole LDAPResult at once, but use a lazy parsing and return the attributes on demand), just fetching the large group objects and traversing the group hierarchy is bound to be very expensive. Even if SSSD is smart and throws away the data it doesn’t need without a lot of processing, the directory server side will incur a heavy load when returning the group members.
In an ideal world, I would prefer to follow up on a suggestion made by some Suse engineers several years ago (I’m sorry I can no longer find the link nor do I remember their names..) which was to add a getgrnam2/getgrgid2 call to libc, which would only provide the GID-to-name translation and patch popular applications in distributions to use that instead of getgrnam/gegrgid. But this is such an uphill battle that I don’t think it’s very realistic to implement.
Of course, we would have to both document and make it obvious from the debug logs why are SSSD groups coming back empty, but I think the performance benefit would outweight the confusion.
For some additional details and discussion, please see e.g. https://pagure.io/389-ds-base/issue/49951
5 years, 6 months