[sssd PR#477][opened] SYSDB: Return EOK in case a non-fatal issue happened
by fidencio
URL: https://github.com/SSSD/sssd/pull/477
Author: fidencio
Title: #477: SYSDB: Return EOK in case a non-fatal issue happened
Action: opened
PR body:
"""
There may be the case where we aren't able to merge the timestamps from
the fast ts db, which are treated as non-fatal issues. In case it
happens, let's return EOK instead of propagating the non-fatal error.
NOTE: I'm not sure whether it's an issue or not, but I've realized that while taking a look at a covscan issue found downstream.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/477/head:pr477
git checkout pr477
6 years, 3 months
Requesting help with files provider ticket 3402 implementation
by Justin Stephenson
Hello,
I have been working on this ticket[1] to allow selection of file paths
for alternate passwd and group files to be used with the files provider.
First, just to make sure I am not completely on the wrong track I would
like to ask for someone to take a quick look at the current
work-in-progress code I have here in my SSSD fork to validate that it
matches up with the expected implementation.
https://github.com/SSSD/sssd/compare/master...justin-stephenson:jstephen-...
Second, assuming I am not completely off track I would appreciate any
help on a code problem I am having here when sf_init() gets called to
setup watches on the passwd_files and group_files lists, the list values
are corrupted or inaccessible. I started off with the code from the
function files_init_alt_files() inside sssm_files_init() directly and
everything works as expected, the problem started when I moved the code
into this separate function.
The list values are retrieved from the new alt_passwd_files and
alt_group_files options or default to /etc/passwd and /etc/group files.
Inside sssm_files_init() I am able to access the correct values of each
string element in the list but when sf_init() is called the list is
corrupt or I am performing some undefined behavior that I cannot determine.
The debug log look something like this in my testing when three
different files are provided to the new conf options.
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found passwd file: [/etc/passwd].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found passwd file: [/opt/testpasswd].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found passwd file: [/usr/passwd].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found group file: [/etc/group].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found group file: [/opt/testgroup].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sssm_files_init] (0x0400):
Found group file: [/usr/group].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up passwd watch on [/etc/passwd].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 17
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 2
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [_snotify_create] (0x0400):
Added a watch for /etc/passwd with inotify flags 0xD88 internal flags
0x1 using function fn after delay 0.0
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up passwd watch on [`<DE><F6>^]hU].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 18
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch -1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [_snotify_create] (0x0400):
Added a watch for `<DE><F6>^]hU with inotify flags 0xD88 internal flags
0x1 using function fn after delay 0.0
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up passwd watch on [/etc/passwd].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 19
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 2
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [_snotify_create] (0x0400):
Added a watch for /etc/passwd with inotify flags 0xD88 internal flags
0x1 using function fn after delay 0.0
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up group watch on [/etc/group].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 20
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 2
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [_snotify_create] (0x0400):
Added a watch for /etc/group with inotify flags 0xD88 internal flags 0x1
using function fn after delay 0.0
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up group watch on [^Q].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 21
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch -1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [_snotify_create] (0x0400):
Added a watch for ^Q with inotify flags 0xD88 internal flags 0x1 using
function fn after delay 0.0
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [sf_init] (0x0400): Setting
up group watch on [/usr/group].
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened inotify fd 22
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened file watch 1
(Wed Dec 20 10:02:48 2017) [sssd[be[files]]] [snotify_watch] (0x2000):
Opened directory watch 2
Lastly, if there are other considerations I have missed here regarding
files provider logic please let me know and i'll work on it.
Any input is much appreciated, thank you.
[1] https://pagure.io/SSSD/sssd/issue/3402
Kind regards,
Justin Stephenson
6 years, 4 months
RFC: SSSD 1.16.1 release contents
by Jakub Hrozek
Hi Timo, Howard and sssd-devel list,
Per Timo’s request (which makes sense also in general as we didn’t release for some time), we’d like to release the 1.16.1 upstream tarball before the Christmas break. Because I don’t want to plan any important work for the last week before Christmas, the tentative date we’re thinking about is December 15th. Would that work for you or would it disrupt any of your distributions schedule?
As per the contents, the only ticket that must be included in the remaining week are fixes for regressions:
https://pagure.io/SSSD/sssd/roadmap?status=Open&tag=regression&milestone=...
Are there any other tickets that you think should be fixed in 1.16.1?
btw the plan for us is to triage the (ridiculously long) 1.16.1 milestone by the beginning to only include user-facing bugs, move other tickets (RFEs/internal changes) to later releases and switch the 1.16.x release stream to bugfix-only. All the user-facing tickets that won’t make the 1.16.1 cut would be moved to 1.16.2. I think we should do at least one more 1.16 release, but whether we do more would also depend on you distribution schedule..see also my other e-mail about SSSD 2.0..
Thanks for your help!
6 years, 4 months
Design document: A tool to print access control report for IPA clients
by Jakub Hrozek
Hi,
below is a short design page about a new sssctl command that prints the
IPA HBAC rules cached on an IPA client. If there are no comments, I'll
open a PR against the docs repository.
Generate an access control report for IPA domains
=================================================
Related ticket(s):
------------------
https://pagure.io/SSSD/sssd/issue/2840
Problem statement
-----------------
Some environments require, for auditing reasons, to generate an access
control report on the IPA client itself. While it can be argued that
generating these reports on the IPA servers instead would provide a nicer
experience, the audits requirement sometimes need a tool to be run on the
host.
Use cases
---------
As an owner of an IPA client I need to know which users have access to
this client. I want to run a tool on the host and get a report who can
access it.
The reports must contain information about HBAC rules. In future, SUDO
rules would be nice to have as well.
Overview of the solution
------------------------
A new ``sssctl`` command called ``access-report``. will be added. This
command will only be implemented for IPA domains for now, other domain
types will just return an error.
The functionality of the command will first trigger PAM access control
call to force refresh of the rules and subsequently print all HBAC rule
objects from the cache.
Configuration changes
---------------------
None, only the new tool will be implemented.
Implementation details
----------------------
In order to trigger the refresh of rules by ``sssd_be`` process, the tool
will call ``pam_acct_mgmt(3)``. The ``user`` and ``service`` that are used in
that call will have sensible defaults (e.g. ``admin`` and ``system-auth``)
but the tool will also offer command-line switches to override both.
In addition, the tool will have a switch to operate purely from cache.
For printing the rules, the tool will simply call ``ldb_search``,
retrieve all objects of objectclass ``ipaHbacRule`` and then print the RDN
value of ``memberUser`` (for users and user groups), ``memberService``
(for services and service groups) and ``category``. By default, groups
will not be unrolled, because the ``getgrnam`` interface limits the group
nesting by default, therefore it is better to just print the group name,
not all the group members.
The tool must also print the output in both human-readable and
machine-readable formats. For machine readable output, JSON is the best
choice, since the KCM responder already depends on ``libjansson.``
How To Test
-----------
Run ``sssctl access-report`` on an IPA client with different HBAC rules
stored in the cache. Make sure all options produce the desired results.
How To Debug
------------
Debug messages will be added to the tool itself. To compare the output
with the cache contents, the ``ldbsearch`` tool can be used. The ``ipa``
administration tool can be used to display the server-side HBAC rules.
Authors
-------
* Jakub Hrozek
6 years, 4 months
[sssd PR#379][opened] CI: Enable pep8 check
by fidencio
URL: https://github.com/SSSD/sssd/pull/379
Author: fidencio
Title: #379: CI: Enable pep8 check
Action: opened
PR body:
"""
As said by the commit log, this PR enables pep8 check in our CI.
I really would appreciate to hear @lslebodn's feedback on the patch itself, so I can revisit the commit dropped by @jhrozek that fixes all pep8 warnings and have it added to this series.
Anyways, the feedback I'm looking for is basically: Is this patch desired? Is this the right approach? If not, what would you suggest?
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/379/head:pr379
git checkout pr379
6 years, 4 months
