| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
INFO: Installed packages:
Start: build phase for sssd-1.15.4-0.el7.src.rpm
Start: build setup for sssd-1.15.4-0.el7.src.rpm
error: unmatched (
error: unmatched (
error: /builddir/build/SPECS/sssd.spec:56: bad %if condition
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Weak dependencies are intentionally disabled. If we need them
then they should be explicitly specified because they are not weak.
Resolves:
https://pagure.io/SSSD/sssd/issue/2809
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Directory is part of make list SSSD_USER_DIRS and therefore
should have such owner&mode also in spec file
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
| |
Provide information for administrators and users to utilize
SSSD systemtap infrastructure.
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run this script using stap as root and Ctrl-C to print the summary
report
stap -v /usr/share/sssd/systemtap/dp_request.stp
This script will use the data provider request probe markers to provide
elapsed time of each request and more information about the slowest
request in the summary report.
Resolves:
https://pagure.io/SSSD/sssd/issue/3061
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
https://fedoraproject.org/wiki/Packaging:UnownedDirectories
sh$ rpm -qf /usr/lib64/sssd/conf/ /usr/lib64/sssd/conf/sssd.conf
file /usr/lib64/sssd/conf is not owned by any package
sssd-common-1.15.3-2.fc27.x86_64
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
| |
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to provide FleetCommander[0] integration, a session provider
has been introduced for IPA. The design of this feature and more
technical details can be found at [1] and [2], which are the design
pages of both freeIPA and SSSD parts.
As there's no way to test freeIPA integration with our upstream tests,
no test has been provided yet.
Is also worth to mention that the name "deskprofile" has been chosen
instead of "fleetcmd" in order to match with the freeIPA plugin. It
means that, for consistence, all source files, directories created,
options added, functions prefixes and so on are following the choice
accordingly.
[0]: https://wiki.gnome.org/Projects/FleetCommander
[1]: https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki
[2]: https://docs.pagure.org/SSSD.sssd/design_pages/fleet_commander_integration.html
Resolves:
https://pagure.io/SSSD/sssd/issue/2995
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
| |
It was removed from epel
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's ensure that running `make intgcheck-*` doesn't fail when done
locally.
As --with-session-recording=/bin/false is now set in the Makefile.am,
there's no need to set it in contrib/ci/configure.sh. Thus, the option
has been removed from there.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
| |
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
| |
Add basic tests for all base combinations of session recording
configuration options.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The file kcm_default_ccache must enable KCM ccache by default
without any modification of the file.
/etc/krb5.conf.d/ is fedora/el7 specific and it is not allowed to
enable or start systemd services in scriptlets. It would result in
broken krb5 configuration. Therefore krb5 configuration snippet was
moved from /etc/krb5.conf.d/ -> /usr/share/sssd-kcm. And each downstream
distribution should enable systemd services + change krb5 configuration
in it's own way.
Reviewed-by: Stephen Gallagher <sgallagh@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
|
|
| |
This reverts commit 35f29b17699c3d52f77857c530300318b14148f8.
Workaround is not required anymore.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a bug in valgrind < 3.13 which override some log files
and therefore there was missing errors for shell wrappers generated
by libtool for dummy-child.
https://bugs.kde.org/show_bug.cgi?id=162848
We could add more suppressions for errors/leaks in bash to our suppression
file but dummy child is built just for test purposes. Another possible solution
would to avoid linking dummy-child with internal libraries; So libtool
would not generate shell wrapper for dummy-child.
But the simplest think is to ignore all errors for dummy-child.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with rpm 4.11, it is possible to install the license using
a new file macro %license, this will separate the license files from documents
and install them in a special directory in /usr/share
rpm -q -l -p ./sssd-1.15.3-0.el7.x86_64.rpm
/usr/share/licenses/sssd-1.15.3
/usr/share/licenses/sssd-1.15.3/COPYING
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rpm macro python_provide is defined only in fedora and epel.
This is the reason why we have fallback definition in the beginning of
spec file otherwise build on rhel would fail.
This macro is defined in file /usr/lib/rpm/macros.d/macros.python
provided by package python-rpm-macros.
sh$ rpm -qf /usr/lib/rpm/macros.d/macros.python
python-rpm-macros-3-20.fc26.noarch
sh$ grep python_provide /usr/lib/rpm/macros.d/macros.python
%python_provide() %{lua:
print("%python_provide: ERROR: ")
But this package is not installed in minimal chroot and therefore
build dependencies cannot be extracted from spec file.
sh$ mock --clean --shell 'rpm -q python-rpm-macros' 2>/dev/null
package python-rpm-macros is not installed
sh$ mock --shell 'rpm --eval "%{python_provide python-test}"' 2>/dev/null
%{python_provide python-test}
sh$ mock --resultdir . --rebuild sssd-1.15.3-0.fc26.src.rpm
...
error: line 295: Unknown tag: %{python_provide python2-sssdconfig}
...
This is the reason why it has to be used conditionally in fedora as it is shown
in example common spec file in python fedora packaging guidelines
http://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file
sh$ rpm -q --whatrequires python-rpm-macros
python2-devel-2.7.13-5.fc26.x86_64
python3-devel-3.6.0-22.fc26.x86_64
This patch reduce differences between upstream and fedora spec file.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
| |
We do it for other libraries.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
| |
It's a cosmetic change to group similar files together (e.g. man pages).
The same order is in fedora downstream spec file.
It simplifies comparison of changes between spec files.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
| |
This patch also moved sss_certmap.5 from sssd-common to libsss_certmap
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Patch also fixes location of translated manual pages
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
Resolves:
https://pagure.io/SSSD/sssd/issue/3327
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
| |
The sssd-ifp.service was installed even though sssd_ifp
was not installed on systemd.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
| |
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
|
|
| |
@see also
https://bugzilla.redhat.com/show_bug.cgi?id=1260190
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
| |
It was mainly aimed for time when stable CentOS and
rhel nightly had different versions of krb5.
Anyway, rhel7.0 and rhel <= 6.6 are already out of support
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
|
|
|
|
|
|
|
| |
We require newer libcurl version than is available on rhel6. We don't
ship secrets responder in rhel6 so we just disable its build.
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
| |
Adds a new KCM responder ccache back end that forwards all requests to
sssd-secrets.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
|
|
|
|
|
| |
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
| |
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for the KCM server to work with ccaches stored in different
locations, implement a middle-man between the KCM server and the ccache
storage.
This module has asynchronous API because we can't assume anything about
where the ccaches are stored.
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the initial build of the Kerberos Cache Manager responder (KCM).
This is a deamon that is capable of holding and storing Kerberos
ccaches. When KCM is used, the kerberos libraries (invoked through e.g.
kinit) are referred to as a 'client' and the KCM deamon is referred to
as 'server'.
At the moment, only the Heimdal implementation of Kerberos implements the
KCM server:
https://www.h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html
This patch adds a KCM server to SSSD.
In MIT, only the 'client-side' support was added:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
This page also describes the protocol between the client and the server.
The client is capable of talking to the server over either UNIX sockets
(Linux, most Unixes) or Mach RPC (macOS). Our server only implements the
UNIX sockets way and should be socket-activated by systemd, although can
in theory be also ran explicitly.
The KCM server only builds if the configuration option "--with-kcm" is
enabled. It is packaged in a new subpackage sssd-kcm in order to allow
distributions to enable the KCM credential caches by installing this
subpackage only, without the rest of the SSSD. The sssd-kcm subpackage
also includes a krb5.conf.d snippet that allows the admin to just uncomment
the KCM defaults and instructs them to start the socket.
The server can be configured in sssd.conf in the "[kcm]" section.
By default, the server only listens on the same socket path the Heimdal
server uses, which is "/var/run/.heim_org.h5l.kcm-socket". This is,
however, configurable.
The file src/responder/kcm/kcm.h is more or less directly imported from
the MIT Kerberos tree, with an additional sentinel code and some
comments. Not all KCM operations are implemented, only those that also
the MIT client implements. That said, this KCM server should also be
usable with a Heimdal client, although no special testing was with this
hybrid.
The patch also adds several error codes that will be used in later
patches.
Related to:
https://pagure.io/SSSD/sssd/issue/2887
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this library it would be possible to map certificates and users not
only by adding the full certificate to the user's LDAP object but by
adding e.g. only parts like the issuer and subject name. Additionally
the library is also able to flexible select/match certificates based on
values in the certificate.
Details about mapping and matching rules can be found in the included
man page.
Related to https://pagure.io/SSSD/sssd/issue/3050
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
| |
In order to test the curl integration code, this patch adds a
command-line tool and tests that it's possible to drive a conversation
with the secrets responder using the tool.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's ensure that in case a responder is explicitly configured in the
sssd.conf its socket won't even start.
The patchset introduces a new binary that will be distributed and will
be called before starting the responders' sockets, ensuring the sockets
will only start in case the responder is supposed to be socket-activated
and its been configured accordingly. Otherwise the responders' socket
startup will fail with a quite helpful debug message leading the admins
to choose between using systemd or not and what has to be done to achieve
their desire.
This suggestion came from Sumit Bose.
The reason for adding a new binary instead of a simple python script is
to avoid dragging unnecessary dependencies to sssd-common package.
Resolves:
https://pagure.io/SSSD/sssd/issue/3300
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
| |
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
|
|
|
|
|
|
| |
The new provider needs a man page.
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new provider type "files". The provider watches the UNIX password
and group databases for changes using inotify and propagates its
contents to the sysdb.
The files provider is only built on platforms that support the inotify
interface, polling or loading the entries on-deman is not supported.
During initialization, the files are loaded from the environment
variables SSS_FILES_PASSWD and SSS_FILES_GROUP, defaulting to
/etc/passwd and /etc/group respectively. Loading the files from
environment variables is mostly implemented for tests that need to load
nss_wrapped files.
The files provider is a bit different from other provider types in the
sense that it always enumerates full contents of the database.
Therefore, the requests from Data Provider are always just replied to
with success. Enumerating the contents is done in full at the moment,
all users and all groups are removed and added anew. Modifying the
passwd and group databses should be rare enough for this to be
justified and we can optimize the code later.
Since with large databases, the cache update might take a bit of time,
we signal the responders to disable the files domain once we receive the
inotify notification and re-enable the files domain after the update is
finished. The idea is that the NSS configuration would still contain
"files" after "sss" so that if the domain is disabled, libc would fall
back to a direct "files" lookup.
Resolves:
https://fedorahosted.org/sssd/ticket/3262
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responders socket-activatable (or,
in the IFP case, dbus-activatable), let's make the IFP responder ready
for this by providing its systemd's units.
Related:
https://fedorahosted.org/sssd/ticket/2243
Resolves:
https://fedorahosted.org/sssd/ticket/3129
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make Sudo responder ready for this by providing its systemd's units.
In case the administrators want to use Sudo responder taking advantage
of socket-activation they will need to enable sssd-sudo.socket and
after a restart of the sssd service, the Sudo socket will be ready
waiting for any activity in order to start the Sudo responder. Also,
the Sudo responder must be removed from the services line on sssd.conf.
The Sudo responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make SSH responder ready for this by providing its systemd's units.
In case the administrators want to use SSH responder taking advantage
of socket-activation they will need to enable sssd-ssh.socket and after
a restart of the sssd service, the SSH socket will be ready waiting for
any activity in order to start the SSH responder. Also, the SSH
responder must be removed from the services line on sssd.conf.
The SSH responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the effort of making all responder socket-activatable, let's
make PAM responder ready for this by providing its systemd's units.
In case the administrators want to use PAM responder taking advantage
of socket-activation they will need to enable sssd-pam.socket and after
a restart of the sssd service, the PAM socket will be ready waiting for
any activity in order to start the PAM responder. Also, the PAM
responder must be removed from the services line on sssd.conf.
The PAM responder service is binded to the SSSD service, which means
that the responder will be restarted in case SSSD is restarted and
shutdown in case SSSD is shutdown/crashes.
PAM responder, differently from the others, is a special case as it has
two sockets and its private sockets must be owned by root and must have
a specifc permission (0600). It's not new, though, and it's following
what has been already done in the project..
Related:
https://fedorahosted.org/sssd/ticket/2243
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>
Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>
|