[sssd PR#32][opened] Requesting a pull to SSSD:master from fidencio:wip/#3138
by fidencio
URL: https://github.com/SSSD/sssd/pull/32
Author: fidencio
Title: #32: Requesting a pull to SSSD:master from fidencio:wip/#3138
Action: opened
PR body:
"""
This patch series is intended to solve #3138 by adding a new service
that updates the confdb. As part of the series this service is used by
secrets service.
I only ran CI locally and the two secrets tests have been failing. /o\
Also, I've noticed some weird behavior, where the sssd-update-confdb
service starts for apparently no reason, when upgrading fedora
packages.
Anyways, these pieces of code really need some detailed review as it
was the first time I've been "seriously" playing with TEvent requests.
So, please, consider it more like an RFC than a well finished and
polished code.
Best Regards,
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/32/head:pr32
git checkout pr32
6 years, 1 month
Tlog integration and packages
by Nikolai Kondrashov
Hi everyone,
I'd like to continue the discussion of tlog integration, and also present you
the first release of tlog - a development preview, which has the configuration
interface necessary to implement the integration:
https://github.com/spbnick/tlog/releases/tag/v1
You're more than welcome to download RPMs, install, read tlog-rec(8) and
tlog-rec.conf(5), and experiment! Building from the Git tree and the tarball
works as well, if you're so inclined. I'm also attaching those manpages for
convenience.
Here are the integration plans so far, as discussed with Jakub on our
devconf.cz trip meetings and before on the list. Jakub, please correct me or
add details.
* We follow the route similar to that taken by SELinux rule control
implementation [1][2]. I.e. store the configuration in LDAP HBAC rules,
write to files on the client side and then specify them to tlog upon user
login.
However, I'm also rather fond of the idea of specifying the whole
configuration through an environment variable instead of through a file
referenced by an environment variable - it's not big at all, and we'll avoid
the hassle of managing the files.
I implemented support for both in tlog (was easy).
* We'll have to make nss_sss report user's shell as tlog-rec (how?) and
specify the actual shell to tlog-rec via an environment variable, through
pam_sss (with SSS_PAM_ENV_ITEM messages). I.e.:
* Nss_sss would always report tlog-rec as the user's shell.
* During login (e.g. through "login" or "sshd") pam_sss would add a variable
to the user environment, containing, or pointing at, a tlog-rec
configuration (TLOG_REC_CONF_TEXT or TLOG_REC_CONF_FILE). That
configuration would contain the user's actual shell. I can also implement
support for a separate variable just for the shell (TLOG_REC_SHELL?) to
simplify the implementation for the start.
* Tlog-rec would read the system-wide configuration and overlay it with the
one specified in the environment, adding the specific user shell, and then
would spawn it.
Please also see the draft integration design page [3] for reference.
I hope to refine and extend it in the coming weeks to match FreeIPA standards.
Please chime in and suggest, object, discuss!
Also, please report tlog bugs at https://github.com/spbnick/tlog/issues
Thank you!
Nick
[1]: http://www.freeipa.org/page/SELinux_user_mapping
[2]: http://www.freeipa.org/images/b/b9/Freeipa30_SELinuxUserMap.pdf
[3]: http://www.freeipa.org/page/Session_Recording
6 years, 6 months
[RFC] NSS tlog integration
by Nikolai Kondrashov
Hi everyone,
Please find attached proof-of-concept patches for a part of NSS integration
with tlog. Namely, addition of shell substitution for getpwnam requests.
The code is supposed to replace a user's shell with /usr/bin/tlog-rec, if
session recording is enabled for all users, if it is enabled for that
particular user, or for a group that it belongs to.
The configuration is done in a dedicated section of sssd.conf named
"session_recording", which can contain three options "scope", "users", and
"groups". Those correspond to the scope of session recording: "none", "some",
and "all", corresponding in order to: disabled session recording, session
recording enabled for the specified users/groups, and session recording
enabled for all users handled by SSSD.
An example of a configuration can be:
[session_recording]
; Disabled
scope = none
or
[session_recording]
; Enabled for everyone
scope = all
or
[session_recording]
; Enabled for some users and groups
scope = some
users = user1, user2
groups = group1, group2
The parts to be done still are adding support for getpwuid and getpwent
requests, exporting of the original shell in pam_sss, and of course cleaning
it up and doing it according to your comments and requirements.
The code has some documentation in doxygen format, which I can change later if
we decide on some other format, or no documentation at all.
Please, tell me if I'm doing anything wrong this far already, or suggest
better ways to do it.
Thank you!
Nick
P.S. I'm on PTO for two weeks starting next week, so might not be able to
answer quickly.
6 years, 9 months
[PATCH] Unit tests for pam_sss using pam_wrapper (need help with CI..)
by Jakub Hrozek
Hi,
the attached patches implement unit tests for the pam_sss module using
pam_wrapper and libpamtest. In my testing, the coverage is around 75%
with mostly the parts that require running as root being untested.
I worked on this patchset even though the features for 1.14 are in full
swing because there are several tickets that will require us to patch
pam_sss, so it's important to have the code that changes tested. In
addition, when we merge Dan's patches to use TLS with integration tests,
then we'll be able to also test authentication in integration tests
easily using libpamtest-python.
However, our CI fails for me constantly:
http://sssd-ci.duckdns.org/logs/job/42/75/fedora_rawhide/ci.html
The strange thing is that running CI locally works fine and so does make
check. Can anyone help point me in the right direction as to what should
I check next? I suspect some of the environment variables might not be
set correctly, but I don't see why..
6 years, 9 months
[PATCHES] views: properly override group member names
by Sumit Bose
Hi,
this is my suggestion to solve https://fedorahosted.org/sssd/ticket/2948
"Handle overriden name of members in the memberUid attribute".
The first two patches are for the IPA provider and make sure that all
ghost members in a group get resolved because otherwise we cannot
determine if the name is overridden or not. This adds an overhead to
group lookups, especially for larger groups but I think it is an
requirement which cannot be skipped.
The third patch adds a sysdb call to recursively resolve all
user-members of a group. Since the groups in SSSD's cache are
hierarchically organized the member attribute only contains direct
user and group members. To get all users the group members must be
resolved recursively.
Finally the forth patch applies the code-path which is already used for
non-default views to the default case as well and adds a new list of
members, with correctly overridden names (hopefully :-) which is then
used in fill_grmem(). This adds some overhead to the overall group
processing in the NSS responder (as can be seen in the test changes
because the members are returned in different order in some cases). But
I think because the of memory cache this is acceptable and might even
help to remove the memberuid attribute in future and make the memberof
plugin simpler.
I worked on an alternative approach as well which tried to make the
memberof plugin aware of the defaultOverrideName attribute. My wip tree
is at
https://fedorapeople.org/cgit/sbose/public_git/sssd.git/log/?h=memberof_d...
but so far it does not work properly. Additionally I would prefer to not
touch the memberof plugin.
bye,
Sumit
6 years, 10 months
