Re: [SSSD] SUDO responder/cache behavior - r00tkit

On 07/28/2011 07:22 AM, arun scaria wrote: > Hi all, > I'v created my write-up on SUDO responder/cache behavior at > https://fedorahosted.org/sssd/wiki/DesignDocs/SudoSupport/SudoResponderCacheBehavior. > I'd love to hear your opinion on it. Please take a review and comment. > One question: How do

Re: [SSSD] [PATCH] libipa_hbac: Support case-insensitive comparisons with UTF8

On 07/27/2011 10:32 PM, Stephen Gallagher wrote: > This patch adds a new build requirement on SSSD: libunistring. > > ACK attached is a unit test I used to test the patch. Contains a couple of selected case folds from different unicode pages. Also a negative test of casefolding "I" to "dotless

Re: [SSSD] SUDO responder/cache behavior - r00tkit

On Thu, Jul 28, 2011 at 2:10 PM, Gowrishankar Rajaiyan wrote: > On 07/28/2011 07:22 AM, arun scaria wrote: > > Hi all, > > I'v created my write-up on SUDO responder/cache behavior at > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SudoSupport/SudoResponderCacheBehavior > . > > I'd love to hear

Re: [SSSD] [PATCH] libipa_hbac: Support case-insensitive comparisons with UTF8

On 28.07.2011 14:42, Jakub Hrozek wrote: > On 07/27/2011 10:32 PM, Stephen Gallagher wrote: >> This patch adds a new build requirement on SSSD: libunistring. >> >> > > ACK > > attached is a unit test I used to test the patch. Contains a couple of > selected case folds from different unicode pages

Re: [SSSD] [PATCH] libipa_hbac: Support case-insensitive comparisons with UTF8

On 27.07.2011 23:32, Stephen Gallagher wrote: > This patch adds a new build requirement on SSSD: libunistring. ACK. There is also need to update spec file. -- / Alexander Bokovoy ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fed

Re: [SSSD] [PATCH] libipa_hbac: Support case-insensitive comparisons with UTF8

On 28.07.2011 16:36, Alexander Bokovoy wrote: > On 27.07.2011 23:32, Stephen Gallagher wrote: >> This patch adds a new build requirement on SSSD: libunistring. > ACK. > > There is also need to update spec file. Ignore this comment, I missed update to spec somehow. -- / Alexander Bokovoy

Re: [SSSD] SUDO responder/cache behavior - r00tkit

On 07/28/2011 06:58 PM, arun scaria wrote: > > > On Thu, Jul 28, 2011 at 2:10 PM, Gowrishankar Rajaiyan > wrote: > > On 07/28/2011 07:22 AM, arun scaria wrote: > > Hi all, > > I'v created my write-up on SUDO responder/cache behavior at > > > > https:

[SSSD] fd leak in sssd_pam

Hej, I am noticing an fd leak with the /usr/lib/sssd/sssd_pam helper program (affected versions: 1.4.1--1.5.11). As is usual with weird bugs, this happens on one machine while it does not on another, but it at least it is reproducible on the one :) What I observe is that for every authenticatio

Re: [SSSD] [PATCHES] Sysdb refactoring

On 07/20/2011 12:58 PM, Jan Zelený wrote: > I'm sending several patches with the sysdb refactoring. Originally, I was > planning one more step - to change return type from int to errno_t where it > was convenient. If someone wants to do it, feel free. Otherwise I'm going to > make the patch myse

[SSSD] [PATCH] Wrong paramater to sysdb_attrs_add_uint32

While reviewing Jan's sysdb patches I noticed that a call to sysdb_attrs_add_uint32() I added recently is wrong. The reason the code worked and the compiler did not complain was simple - there's only one place that calls sdap_store_group_with_gid() and it passes group_attrs for mem_ctx. If we ever

Re: [SSSD] [PATCH] Wrong paramater to sysdb_attrs_add_uint32

On Thu, 2011-07-28 at 17:56 +0200, Jakub Hrozek wrote: > While reviewing Jan's sysdb patches I noticed that a call to > sysdb_attrs_add_uint32() I added recently is wrong. > > The reason the code worked and the compiler did not complain was simple > - there's only one place that calls sdap_store_g

[SSSD] [PATCH] Remove incorrect private variable

This caused no ill effects, since it wasn't used in the callback. However, it is a layering violation (especially since req is freed in the callback) From 8581c46c5836e7eb355d9878f0b6829c59ee2852 Mon Sep 17 00:00:00 2001 From: Stephen Gallagher Date: Thu, 28 Jul 2011 13:28:51 -0400 Subject: [PATCH

Re: [SSSD] fd leak in sssd_pam

On Thu, 2011-07-28 at 17:37 +0200, Jan Engelhardt wrote: > Hej, > > > I am noticing an fd leak with the /usr/lib/sssd/sssd_pam helper program > (affected versions: 1.4.1--1.5.11). As is usual with weird bugs, this > happens on one machine while it does not on another, but it at least it > is re

Re: [SSSD] [PATCH] Remove incorrect private variable

On Thu, Jul 28, 2011 at 01:30:44PM -0400, Stephen Gallagher wrote: > This caused no ill effects, since it wasn't used in the callback. > However, it is a layering violation (especially since req is freed > in the callback) Ack ___ sssd-devel mailing list

[SSSD] [PATCH] Fix FD leak in pam_sss.so

Attached patch that makes sure we alays close the socket on modeule unloading. It is defined in common.c so all clients that use that file get it, so nss_sss.so has it as well. Ticket #942 Simo. -- Simo Sorce * Red Hat, Inc * New York >From b28d5e5f7eddf504cbe36cff1ddba5b240822668 Mon Sep 17 00

[SSSD] [PATCH] Converge accept_fd_handler and accept_priv_fd_handler

These two functions were almost identical. Better to maintain them as a single function. From 28a2e83fabacb7aa0154c9980bdedbf5314c7da8 Mon Sep 17 00:00:00 2001 From: Stephen Gallagher Date: Thu, 28 Jul 2011 15:32:30 -0400 Subject: [PATCH] Converge accept_fd_handler and accept_priv_fd_handler Thes

Re: [SSSD] [PATCHES] Sysdb refactoring

> On 07/20/2011 12:58 PM, Jan Zelený wrote: > > I'm sending several patches with the sysdb refactoring. Originally, I was > > planning one more step - to change return type from int to errno_t where > > it was convenient. If someone wants to do it, feel free. Otherwise I'm > > going to make the pat

Re: [SSSD] [PATCH] Wrong paramater to sysdb_attrs_add_uint32

On 07/28/2011 06:32 PM, Stephen Gallagher wrote: > On Thu, 2011-07-28 at 17:56 +0200, Jakub Hrozek wrote: >> While reviewing Jan's sysdb patches I noticed that a call to >> sysdb_attrs_add_uint32() I added recently is wrong. >> >> The reason the code worked and the compiler did not complain was sim