1.9.5 upstream release
by Jakub Hrozek
Hi,
as soon as #1880 is fixed, I would like to release 1.9.5 upstream. I
think there is enough important fixes to trigger the release and already
some maintainers have been asking for the release.
Are there any other bugs to fold into the release? The current list of
tickets closed (also closed as invalid or worksforme) can be found here:
https://fedorahosted.org/sssd/query?group=status&milestone=SSSD+1.9.5
And the full list of commits can be read from git when on the sssd-1-9
branch:
$ git shortlog sssd-1_9_4..HEAD
10 years, 7 months
[PATCH] Fix krbcc dir creation issue with MIT krb5 1.11
by Lukas Slebodnik
ehlo,
In krb5-libs 1.11, function krb5_cc_resolve verify if credential cache dir
exists. If it doesn't exist, than it will be created. We
have to ensure, that it will be created with right uid, gid and permissions.
There is check in krb_auth_send, whether cached user data in ldb contains
SYSDB_CCACHE_FILE attribute. If it is available, then old ccache is checked in
function check_old_ccache. Gdm clean user directory (in /run/user/)
after logout. This is the reason why SYSDB_CCACHE_FILE attribute was found
in ldb cache and directory did not exist and then in function krb5_cc_resolve
was created with wrong permissions.
Patch attached.
LS
10 years, 7 months
resolv-tests failing
by Yassir Elley
I did a fresh "git clone" from master earlier today on a Fedora 19 VM. The source code builds fine, but "make check" is reporting that a test named "resolv-tests" is failing.
Regards,
Yassir.
===================================
sssd 1.9.92: ./test-suite.log
===================================
# TOTAL: 24
# PASS: 23
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: resolv-tests
==================
Network tests disabled. Rerun with the "-n" option to run the full suite of tests
Running suite(s): resolv
Leak report for ../src/tests/resolv-tests.c:719:
full talloc report on 'struct resolv_test_ctx' (total 664 bytes in 11 blocks)
struct resolv_ctx contains 352 bytes in 6 blocks (ref 0) 0x12a81c0
struct tevent_timer contains 80 bytes in 1 blocks (ref 0) 0x12a8e30
struct fd_watch contains 128 bytes in 2 blocks (ref 0) 0x12a8fc0
struct tevent_fd contains 88 bytes in 1 blocks (ref 0) 0x12a9050
struct resolv_request contains 104 bytes in 2 blocks (ref 0) 0x12a8db0
struct tevent_timer contains 80 bytes in 1 blocks (ref 0) 0x12a8cf0
struct tevent_context contains 280 bytes in 4 blocks (ref 0) 0x12a7ef0
struct epoll_event_context contains 40 bytes in 1 blocks (ref 0) 0x12a8130
struct std_event_glue contains 112 bytes in 2 blocks (ref 0) 0x12a7fe0
struct tevent_ops contains 80 bytes in 1 blocks (ref 0) 0x12a8070
80%: Checks: 5, Failures: 1, Errors: 0
../src/tests/common_check.c:54:F:RESOLV Tests:test_resolv_free_req:0: ../src/tests/resolv-tests.c:719: memory leaks detected, 312 bytes still allocated
10 years, 7 months
[PATCH] Allocate PAM DP request data on responder context
by Jakub Hrozek
https://fedorahosted.org/sssd/ticket/1869
Currently the private data passed to the PAM request is a structure
allocated on the client context. But in the odd case where the back end
would be stopped or stuck until the idle timeout hits, the DP callback.
This patch introduces a new structure allocated on responder context,
whose only purpose is to live as long as the request is active.
The attached patch is mostly a workaround, I think the correct fix would
be to start using a tevent_req-styled request structure similar to the one we
use in the NSS responder, but we've seen users hitting this problem even
on RHEL5 with sssd-1-5 recently, so I would like to fix the problem in
some way. If this patch is accepted, I'll file a ticket to convert the
PAM responder to a tevent_req interface for better manageability.
10 years, 7 months
[PATCH] DHASH: minor fixes
by Ondrej Kos
Patch is attached.
Ondra
--
Ondrej Kos
Associate Software Engineer
Identity Management
Red Hat Czech
10 years, 7 months