date:20161124

[SSSD] Re: Design document - Socket-activatable responders

2016-11-24 Thread amit kumar

Hey fabiano,

There are couple of spelling mistakes(*Bo**ld*) on DesignDoc Page:
https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders

consists in marking the service as started, increasing the services'
counter, getting the responder's *configuratiom*, <
he change in the responders' common code is quite trivial, just *chnage*
the sss_process_init code to call activate_unix_sockets()  <

Thanks

On 11/25/2016 04:34 AM, Fabiano Fidêncio wrote:
> On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio  wrote:
>> The design page is done [0] and it's based on this discussion [1] we
>> had on this very same mailing list. A pull-request with the
>> implementation is already opened [2].
>>
>> [0]: 
>> https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders
>> [1]: 
>> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/
>> [2]: https://github.com/SSSD/sssd/pull/84
> Well, PR#94: https://github.com/SSSD/sssd/pull/94
>
>> The full text of c here:
>>
>> = Socket Activatable Responders =
>>
>> Related ticket(s):
>>  * https://fedorahosted.org/sssd/ticket/2243
>>  * https://fedorahosted.org/sssd/ticket/3129
>>
>> === Problem statement ===
>> SSSD has some responders which don't have to be running all the time,
>> but could be socket-activated instead in platforms where it's
>> supported. That's the case, for instance, for the IFP, ssh and sudo
>> responders.
>> Making these responders socket-activated would provide a better use
>> experience, as these services could be started on-demand when a client
>> needs them and exist after a period of inactivity. Currently the admin
>> has to explicitly list all the services that might potentially be
>> needed in the `services` section and the processes have to be running
>> all the time.
>>
>> === Use cases ===
>>
>>  sssctl  
>> As more and more features that had been added depending on the IFP
>> responder, we should make sure that the responder is activated on
>> demand and the admins doesn't have to activate it manually.
>>
>>  KCM 
>> The KCM responder is only seldom needed, when libkrb5 needs to access
>> the credentials store. At the same time, the KCM responder must be
>> running if the Kerberos credentials cache defaults to `KCM`.
>> Socket-activating the responder would solve both of these cases.
>>
>>  autofs 
>> The autofs responder is typically only needed when a share is about to
>> be mounted.
>>
>> === Overview of the solution ===
>> The solution agreed on the mailing list is to add a new unit for each
>> one of the responders. Once a responder is started, it will
>> communicate to the monitor in order to let the monitor know that it's
>> up and the monitor will do the registration of the responder, which
>> basically consists in marking the service as started, increasing the
>> services' counter, getting the responder's configuratiom, adding the
>> responder to the service's list.
>> A configurable idle timeout will be implemented in each responder, as
>> part of this task, in order to exit the responder in case it's not
>> used for a few minutes.
>>
>> === Implementation details ===
>> In order to achieve our goal we will need a small modification in
>> responders' common code in order to make it ready for
>> socket-activation, add some systemd units for each of the responders
>> and finally small changes in the monitor code in order to manage the
>> new activated service.
>>
>> The change in the responders' common code is quite trivial, just
>> chnage the sss_process_init code to call activate_unix_sockets()
>> istead of set_unix_socket(). Something like:
>> {{{
>> -ret = set_unix_socket(rctx, conn_setup);
>> +ret = activate_unix_sockets(rctx, conn_setup);
>> }}}
>>
>> The units that have to be added for each responder must look like:
>>
>> sssd-@respon...@.service.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder
>> Documentation=man:sssd.conf(5)
>> Requires=sssd.service
>> PartOf=sssd.service
>> After=sssd.service
>>
>> [Install]
>> Also=sssd-@responder@.socket
>>
>> [Service]
>> ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files
>> }}}
>>
>> sssd-@respon...@.socket.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder socket
>> Documentation=man:sssd.conf(5)
>>
>> [Socket]
>> ListenStream=@pipepath@/@responder@
>>
>> [Install]
>> WantedBy=sockets.target
>> }}}
>>
>> Some responders may have more than one socket, which is the case of
>> PAM, so another unit will be needed.
>>
>> sssd-@respon...@-priv.socket.in:
>> {{{
>> [Unit]
>> Description=SSSD @responder@ Service responder private socket
>> Documentation=man:sssd.conf(5)
>>
>> [Socket]
>> ListenStream=@pipepath@/private/@responder@
>>
>> [Install]
>> WantedBy=sockets.target
>> }}}
>>
>> Last but not least, the IFP responder doesn't have a socket. It's
>> going to be D-Bus

[SSSD] [sssd PR#92][comment] UTIL: Fix compilation of sss_utf8 with libunistring

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/92
Title: #92: UTIL: Fix compilation of sss_utf8 with libunistring

fidencio commented:
"""
Please, include some info in the commit message about how the breakage was 
noticed.
Is this part of the "Fixing SSSD build on FreeBSD"? Was this found using some 
"non-usual" configure option?

Also, the whole series about "Fixing SSSD build on FreeBSD" could have been 
sent together instead of one patch per PR.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/92#issuecomment-262854746
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#92][+Changes requested] UTIL: Fix compilation of sss_utf8 with libunistring

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/92
Title: #92: UTIL: Fix compilation of sss_utf8 with libunistring

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#91][comment] sssctl: Fix missing declaration

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/91
Title: #91: sssctl: Fix missing declaration

fidencio commented:
"""
Please, mention that the breakage was noticed when building SSSD on FreeBSD on 
this patch as well.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/91#issuecomment-262854618
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#91][+Changes requested] sssctl: Fix missing declaration

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/91
Title: #91: sssctl: Fix missing declaration

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][+Accepted] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][comment] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

fidencio commented:
"""
Acked-by: Fabiano Fidêncio 
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/90#issuecomment-262854577
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#88][+Accepted] SYSDB: Remove unused prototype from header file

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/88
Title: #88: SYSDB: Remove unused prototype from header file

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#88][comment] SYSDB: Remove unused prototype from header file

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/88
Title: #88: SYSDB: Remove unused prototype from header file

fidencio commented:
"""
Acked-by: Fabiano Fidêncio 
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/88#issuecomment-262854516
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: Design document - Socket-activatable responders

2016-11-24 Thread Fabiano Fidêncio

On Thu, Nov 24, 2016 at 2:33 PM, Fabiano Fidêncio  wrote:
> The design page is done [0] and it's based on this discussion [1] we
> had on this very same mailing list. A pull-request with the
> implementation is already opened [2].
>
> [0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders
> [1]: 
> https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/
> [2]: https://github.com/SSSD/sssd/pull/84

Well, PR#94: https://github.com/SSSD/sssd/pull/94

>
> The full text of c here:
>
> = Socket Activatable Responders =
>
> Related ticket(s):
>  * https://fedorahosted.org/sssd/ticket/2243
>  * https://fedorahosted.org/sssd/ticket/3129
>
> === Problem statement ===
> SSSD has some responders which don't have to be running all the time,
> but could be socket-activated instead in platforms where it's
> supported. That's the case, for instance, for the IFP, ssh and sudo
> responders.
> Making these responders socket-activated would provide a better use
> experience, as these services could be started on-demand when a client
> needs them and exist after a period of inactivity. Currently the admin
> has to explicitly list all the services that might potentially be
> needed in the `services` section and the processes have to be running
> all the time.
>
> === Use cases ===
>
>  sssctl  
> As more and more features that had been added depending on the IFP
> responder, we should make sure that the responder is activated on
> demand and the admins doesn't have to activate it manually.
>
>  KCM 
> The KCM responder is only seldom needed, when libkrb5 needs to access
> the credentials store. At the same time, the KCM responder must be
> running if the Kerberos credentials cache defaults to `KCM`.
> Socket-activating the responder would solve both of these cases.
>
>  autofs 
> The autofs responder is typically only needed when a share is about to
> be mounted.
>
> === Overview of the solution ===
> The solution agreed on the mailing list is to add a new unit for each
> one of the responders. Once a responder is started, it will
> communicate to the monitor in order to let the monitor know that it's
> up and the monitor will do the registration of the responder, which
> basically consists in marking the service as started, increasing the
> services' counter, getting the responder's configuratiom, adding the
> responder to the service's list.
> A configurable idle timeout will be implemented in each responder, as
> part of this task, in order to exit the responder in case it's not
> used for a few minutes.
>
> === Implementation details ===
> In order to achieve our goal we will need a small modification in
> responders' common code in order to make it ready for
> socket-activation, add some systemd units for each of the responders
> and finally small changes in the monitor code in order to manage the
> new activated service.
>
> The change in the responders' common code is quite trivial, just
> chnage the sss_process_init code to call activate_unix_sockets()
> istead of set_unix_socket(). Something like:
> {{{
> -ret = set_unix_socket(rctx, conn_setup);
> +ret = activate_unix_sockets(rctx, conn_setup);
> }}}
>
> The units that have to be added for each responder must look like:
>
> sssd-@respon...@.service.in:
> {{{
> [Unit]
> Description=SSSD @responder@ Service responder
> Documentation=man:sssd.conf(5)
> Requires=sssd.service
> PartOf=sssd.service
> After=sssd.service
>
> [Install]
> Also=sssd-@responder@.socket
>
> [Service]
> ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files
> }}}
>
> sssd-@respon...@.socket.in:
> {{{
> [Unit]
> Description=SSSD @responder@ Service responder socket
> Documentation=man:sssd.conf(5)
>
> [Socket]
> ListenStream=@pipepath@/@responder@
>
> [Install]
> WantedBy=sockets.target
> }}}
>
> Some responders may have more than one socket, which is the case of
> PAM, so another unit will be needed.
>
> sssd-@respon...@-priv.socket.in:
> {{{
> [Unit]
> Description=SSSD @responder@ Service responder private socket
> Documentation=man:sssd.conf(5)
>
> [Socket]
> ListenStream=@pipepath@/private/@responder@
>
> [Install]
> WantedBy=sockets.target
> }}}
>
> Last but not least, the IFP responder doesn't have a socket. It's
> going to be D-Bus activated and some small changes will be required on
> its D-Bus service unit.
> {{{
> -Exec=@libexecdir@/sssd/sss_signal
> +Exec=@libexecdir@/sssd/sssd_@responder@
> }}}
>
> And, finally, the code in the monitor side will have to have some
> adjustments in order to properly deal with an empty list of services
> and, also, to register the service when it's started.
>
> As just the responders' will be socket-activated for now, the service
> type will have to exposed and passed through sbus when calling the
> RegistrationService method and the monitor will have to properly do
> the registration of the

[SSSD] [sssd PR#94][opened] Enable {socket,dbus}-activation for responders

2016-11-24 Thread fidencio

   URL: https://github.com/SSSD/sssd/pull/94
Author: fidencio
 Title: #94: Enable {socket,dbus}-activation for responders
Action: opened

PR body:
"""
This series fixes [#2243](https://fedorahosted.org/sssd/ticket/2243), 
[#3129](https://fedorahosted.org/sssd/ticket/3129) and 
[#3245](https://fedorahosted.org/sssd/ticket/3245) following what was discussed 
in the 
[ML](https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/)
 and summed up at 
[this](https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders)
 design document.

The approach taken was the less intrusive possible and keeps the backward 
compatibility.

[PR#84](https://github.com/SSSD/sssd/pull/84) was closed due to my lack of 
skills with github. :-\
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/94/head:pr94
git checkout pr94
From 2ea7727fd6c0c2b23a273fc0dd755405a7db94e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 16 Nov 2016 17:21:54 +0100
Subject: [PATCH 01/21] MONITOR: Expose the monitor's services type
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Let's expose the monitor's service type so it can be passed by the
services to the RegisterService method.

It will be needed in the future, for socket-activation of the
responders, as we will need to differentiate the cases where the
service being registered is still not in the list of the services but is
still a valid case because it was just socket-activated.

Related:
https://fedorahosted.org/sssd/ticket/2243

Signed-off-by: Fabiano Fidêncio 
---
 src/monitor/monitor.c| 5 -
 src/monitor/monitor_interfaces.h | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c
index 935febb..23b0f79 100644
--- a/src/monitor/monitor.c
+++ b/src/monitor/monitor.c
@@ -91,11 +91,6 @@ int cmdline_debug_microseconds;
 
 struct svc_spy;
 
-enum mt_svc_type {
-MT_SVC_SERVICE,
-MT_SVC_PROVIDER
-};
-
 struct mt_svc {
 struct mt_svc *prev;
 struct mt_svc *next;
diff --git a/src/monitor/monitor_interfaces.h b/src/monitor/monitor_interfaces.h
index 8a9e4fe..9004801 100644
--- a/src/monitor/monitor_interfaces.h
+++ b/src/monitor/monitor_interfaces.h
@@ -35,6 +35,11 @@
 
 #define SSSD_SERVICE_PIPE "private/sbus-monitor"
 
+enum mt_svc_type {
+MT_SVC_SERVICE,
+MT_SVC_PROVIDER
+};
+
 int monitor_get_sbus_address(TALLOC_CTX *mem_ctx, char **address);
 int monitor_common_send_id(struct sbus_connection *conn,
const char *name, uint16_t version);

From c4b002fe793b95ad42b9a68b6d72eae974b575b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 16 Nov 2016 17:32:10 +0100
Subject: [PATCH 02/21] MONITOR: Pass the service type to the RegisterService
 method
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Passing the service type to the RegisterService method will help us in
the future, for socket-activation, as we will need to differentiate
cases where the service being registered is still not in the services'
list but is a valid case and has to be added there as it was
socket-activated.

Related:
https://fedorahosted.org/sssd/ticket/2243

Signed-off-by: Fabiano Fidêncio 
---
 src/monitor/monitor.c   | 2 ++
 src/monitor/monitor_interfaces.h| 3 ++-
 src/monitor/monitor_sbus.c  | 6 --
 src/providers/data_provider_be.c| 2 +-
 src/responder/common/responder_common.c | 4 ++--
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c
index 23b0f79..969b854 100644
--- a/src/monitor/monitor.c
+++ b/src/monitor/monitor.c
@@ -227,6 +227,7 @@ static int client_registration(struct sbus_request *dbus_req, void *data)
 struct mt_svc *svc;
 DBusError dbus_error;
 dbus_uint16_t svc_ver;
+dbus_uint16_t svc_type;
 char *svc_name;
 dbus_bool_t dbret;
 int ret;
@@ -245,6 +246,7 @@ static int client_registration(struct sbus_request *dbus_req, void *data)
 dbret = dbus_message_get_args(dbus_req->message, _error,
   DBUS_TYPE_STRING, _name,
   DBUS_TYPE_UINT16, _ver,
+  DBUS_TYPE_UINT16, _type,
   DBUS_TYPE_INVALID);
 if (!dbret) {
 DEBUG(SSSDBG_CRIT_FAILURE,
diff --git a/src/monitor/monitor_interfaces.h b/src/monitor/monitor_interfaces.h
index 9004801..986bac5 100644
--- a/src/monitor/monitor_interfaces.h
+++ b/src/monitor/monitor_interfaces.h
@@ -42,7 +42,7 @@ enum mt_svc_type {
 
 int monitor_get_sbus_address(TALLOC_CTX *mem_ctx, char **address);
 int monitor_common_send_id(struct

[SSSD] [sssd PR#84][closed] Socket-activation of SSSD responders

2016-11-24 Thread fidencio

   URL: https://github.com/SSSD/sssd/pull/84
Author: fidencio
 Title: #84: Socket-activation of SSSD responders
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/84/head:pr84
git checkout pr84
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#84][synchronized] Socket-activation of SSSD responders

2016-11-24 Thread fidencio

   URL: https://github.com/SSSD/sssd/pull/84
Author: fidencio
 Title: #84: Socket-activation of SSSD responders
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/84/head:pr84
git checkout pr84
From 1c6a539d8a858b38414e4cf95c378ab14617ad4d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 16 Nov 2016 17:21:54 +0100
Subject: [PATCH 01/14] MONITOR: Expose the monitor's services type
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Let's expose the monitor's service type so it can be passed by the
services to the RegisterService method.

It will be needed in the future, for socket-activation of the
responders, as we will need to differentiate the cases where the
service being registered is still not in the list of the services but is
still a valid case because it was just socket-activated.

Related:
https://fedorahosted.org/sssd/ticket/2243

Signed-off-by: Fabiano Fidêncio 
---
 src/monitor/monitor.c| 5 -
 src/monitor/monitor_interfaces.h | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c
index 935febb..23b0f79 100644
--- a/src/monitor/monitor.c
+++ b/src/monitor/monitor.c
@@ -91,11 +91,6 @@ int cmdline_debug_microseconds;
 
 struct svc_spy;
 
-enum mt_svc_type {
-MT_SVC_SERVICE,
-MT_SVC_PROVIDER
-};
-
 struct mt_svc {
 struct mt_svc *prev;
 struct mt_svc *next;
diff --git a/src/monitor/monitor_interfaces.h b/src/monitor/monitor_interfaces.h
index 8a9e4fe..9004801 100644
--- a/src/monitor/monitor_interfaces.h
+++ b/src/monitor/monitor_interfaces.h
@@ -35,6 +35,11 @@
 
 #define SSSD_SERVICE_PIPE "private/sbus-monitor"
 
+enum mt_svc_type {
+MT_SVC_SERVICE,
+MT_SVC_PROVIDER
+};
+
 int monitor_get_sbus_address(TALLOC_CTX *mem_ctx, char **address);
 int monitor_common_send_id(struct sbus_connection *conn,
const char *name, uint16_t version);

From 5739e4a45ddb3d3808a0a63b8f30a0bb94ab7756 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= 
Date: Wed, 16 Nov 2016 17:32:10 +0100
Subject: [PATCH 02/14] MONITOR: Pass the service type to the RegisterService
 method
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Passing the service type to the RegisterService method will help us in
the future, for socket-activation, as we will need to differentiate
cases where the service being registered is still not in the services'
list but is a valid case and has to be added there as it was
socket-activated.

Related:
https://fedorahosted.org/sssd/ticket/2243

Signed-off-by: Fabiano Fidêncio 
---
 src/monitor/monitor.c   | 2 ++
 src/monitor/monitor_interfaces.h| 3 ++-
 src/monitor/monitor_sbus.c  | 6 --
 src/providers/data_provider_be.c| 2 +-
 src/responder/common/responder_common.c | 4 ++--
 5 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/monitor/monitor.c b/src/monitor/monitor.c
index 23b0f79..969b854 100644
--- a/src/monitor/monitor.c
+++ b/src/monitor/monitor.c
@@ -227,6 +227,7 @@ static int client_registration(struct sbus_request *dbus_req, void *data)
 struct mt_svc *svc;
 DBusError dbus_error;
 dbus_uint16_t svc_ver;
+dbus_uint16_t svc_type;
 char *svc_name;
 dbus_bool_t dbret;
 int ret;
@@ -245,6 +246,7 @@ static int client_registration(struct sbus_request *dbus_req, void *data)
 dbret = dbus_message_get_args(dbus_req->message, _error,
   DBUS_TYPE_STRING, _name,
   DBUS_TYPE_UINT16, _ver,
+  DBUS_TYPE_UINT16, _type,
   DBUS_TYPE_INVALID);
 if (!dbret) {
 DEBUG(SSSDBG_CRIT_FAILURE,
diff --git a/src/monitor/monitor_interfaces.h b/src/monitor/monitor_interfaces.h
index 9004801..986bac5 100644
--- a/src/monitor/monitor_interfaces.h
+++ b/src/monitor/monitor_interfaces.h
@@ -42,7 +42,7 @@ enum mt_svc_type {
 
 int monitor_get_sbus_address(TALLOC_CTX *mem_ctx, char **address);
 int monitor_common_send_id(struct sbus_connection *conn,
-   const char *name, uint16_t version);
+   const char *name, uint16_t version, uint16_t type);
 int monitor_common_res_init(struct sbus_request *dbus_req, void *data);
 
 errno_t sss_monitor_init(TALLOC_CTX *mem_ctx,
@@ -50,5 +50,6 @@ errno_t sss_monitor_init(TALLOC_CTX *mem_ctx,
  struct mon_cli_iface *mon_iface,
  const char *svc_name,
  uint16_t svc_version,
+ uint16_t svc_type,
  void *pvt,
  struct sbus_connection **mon_conn);
diff --git

[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/89
Title: #89: nss: rewrite nss responder so it uses cache_req

lslebodn commented:
"""
Congratulation you broke integration tests on all distributions.
```
ldap_local_override_test.py::test_regr_2790_override FAILED
test_memory_cache.py::test_getgrnam_simple_with_mc FAILED
test_memory_cache.py::test_getgrnam_membership_with_mc FAILED
test_memory_cache.py::test_invalidation_of_gids_after_initgroups FAILED
test_memory_cache.py::test_initgroups_without_change_in_membership FAILED
test_netgroup.py::test_remove_step_by_step FAILED
test_netgroup.py::test_removing_nested_netgroups FAILED
test_netgroup.py::test_offline_netgroups FAILED
```

and uninitialized variable is used.
```
src/responder/nss/nss_protocol_svcent.c: In function ‘nss_protocol_fill_svcent’:
src/responder/nss/nss_protocol_svcent.c:134:15: error: ‘num_aliases’ may be 
used uninitialized in this function [-Werror=maybe-uninitialized]
 aliases = talloc_zero_array(mem_ctx, struct sized_string, num_aliases + 1);
   ^
src/responder/nss/nss_protocol_svcent.c:121:14: note: ‘num_aliases’ was 
declared here
 uint32_t num_aliases;
  ^~~
  CC   src/responder/nss/nss_iface.o
```
Maybe it's related to failures in integration tests.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/89#issuecomment-262825019
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#89][+Changes requested] nss: rewrite nss responder so it uses cache_req

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/89
Title: #89: nss: rewrite nss responder so it uses cache_req

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#93][synchronized] SSH: Use default_domain_suffix for users' authorized keys

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/93
Author: jhrozek
 Title: #93: SSH: Use default_domain_suffix for users' authorized keys
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/93/head:pr93
git checkout pr93
From fd07958646485a50298fd17f98f3250f80699eab Mon Sep 17 00:00:00 2001
From: Jakub Hrozek 
Date: Thu, 24 Nov 2016 18:07:56 +0100
Subject: [PATCH] SSH: Use default_domain_suffix for users' authorized keys

In commit eeecc48d22a28bb69da56f6ffd8824163fc9bf00 we disabled
default_domain_suffix for the SSH responder, but in a wrong way -- we
disabled the functionality completely, also for users, not only for
computers. This might have been correct at the time, since SSH keys in ID
overrides are a relatively new feature, but it's definitely not correct
in general.

Instead, this patch restores the use of default_domain_suffix, but only
for looking up public keys of users, not of computers.
---
 src/responder/ssh/sshsrv_cmd.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/responder/ssh/sshsrv_cmd.c b/src/responder/ssh/sshsrv_cmd.c
index ab721d6..2e64893 100644
--- a/src/responder/ssh/sshsrv_cmd.c
+++ b/src/responder/ssh/sshsrv_cmd.c
@@ -36,7 +36,8 @@
 #include "responder/ssh/sshsrv_private.h"
 
 static errno_t
-ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx);
+ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx,
+  char *default_domain);
 
 static errno_t
 ssh_user_pubkeys_search(struct ssh_cmd_ctx *cmd_ctx);
@@ -57,7 +58,7 @@ sss_ssh_cmd_get_user_pubkeys(struct cli_ctx *cctx)
 cmd_ctx->cctx = cctx;
 cmd_ctx->is_user = true;
 
-ret = ssh_cmd_parse_request(cmd_ctx);
+ret = ssh_cmd_parse_request(cmd_ctx, cctx->rctx->default_domain);
 if (ret != EOK) {
 goto done;
 }
@@ -107,7 +108,7 @@ sss_ssh_cmd_get_host_pubkeys(struct cli_ctx *cctx)
 cmd_ctx->cctx = cctx;
 cmd_ctx->is_user = false;
 
-ret = ssh_cmd_parse_request(cmd_ctx);
+ret = ssh_cmd_parse_request(cmd_ctx, NULL);
 if (ret != EOK) {
 goto done;
 }
@@ -681,7 +682,8 @@ ssh_host_pubkeys_update_known_hosts(struct ssh_cmd_ctx *cmd_ctx)
 }
 
 static errno_t
-ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx)
+ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx,
+  char *default_domain)
 {
 struct cli_protocol *pctx;
 struct ssh_ctx *ssh_ctx;
@@ -754,6 +756,8 @@ ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx)
 return EINVAL;
 }
 c += domain_len;
+} else {
+domain = default_domain;
 }
 
 DEBUG(SSSDBG_TRACE_FUNC,
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#93][edited] SSH: Use default_domain_suffix for users' authorized keys

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/93
Author: jhrozek
 Title: #93: SSH: Use default_domain_suffix for users' authorized keys
Action: edited

 Changed field: body
Original value:
"""
In commit eeecc48 we disabled
default_domain_suffix for the SSH responder, but in a wrong way -- we
disabled the functionality completely, also for users, not only for
groups. This might have been correct at the time, since SSH keys in ID
overrides are a relatively new feature, but it's definitely not correct
in general.

Instead, this patch restores the use of default_domain_suffix, but only
for looking up public keys of users, not of groups.
"""

___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#93][edited] SSH: Use default_domain_suffix for users' authorized keys

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/93
Author: jhrozek
 Title: #93: SSH: Use default_domain_suffix for users' authorized keys
Action: edited

___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#93][opened] SSH: Use default_domain_suffix for users' authorized keys

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/93
Author: jhrozek
 Title: #93: SSH: Use default_domain_suffix for users' authorized keys
Action: opened

PR body:
"""
None
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/93/head:pr93
git checkout pr93
From 9806f0bda1fb96b860790ae96cdf707b7e612864 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek 
Date: Thu, 24 Nov 2016 18:07:56 +0100
Subject: [PATCH] SSH: Use default_domain_suffix for users' authorized keys

In commit eeecc48d22a28bb69da56f6ffd8824163fc9bf00 we disabled
default_domain_suffix for the SSH responder, but in a wrong way -- we
disabled the functionality completely, also for users, not only for
groups. This might have been correct at the time, since SSH keys in ID
overrides are a relatively new feature, but it's definitely not correct
in general.

Instead, this patch restores the use of default_domain_suffix, but only
for looking up public keys of users, not of groups.
---
 src/responder/ssh/sshsrv_cmd.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/responder/ssh/sshsrv_cmd.c b/src/responder/ssh/sshsrv_cmd.c
index ab721d6..2e64893 100644
--- a/src/responder/ssh/sshsrv_cmd.c
+++ b/src/responder/ssh/sshsrv_cmd.c
@@ -36,7 +36,8 @@
 #include "responder/ssh/sshsrv_private.h"
 
 static errno_t
-ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx);
+ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx,
+  char *default_domain);
 
 static errno_t
 ssh_user_pubkeys_search(struct ssh_cmd_ctx *cmd_ctx);
@@ -57,7 +58,7 @@ sss_ssh_cmd_get_user_pubkeys(struct cli_ctx *cctx)
 cmd_ctx->cctx = cctx;
 cmd_ctx->is_user = true;
 
-ret = ssh_cmd_parse_request(cmd_ctx);
+ret = ssh_cmd_parse_request(cmd_ctx, cctx->rctx->default_domain);
 if (ret != EOK) {
 goto done;
 }
@@ -107,7 +108,7 @@ sss_ssh_cmd_get_host_pubkeys(struct cli_ctx *cctx)
 cmd_ctx->cctx = cctx;
 cmd_ctx->is_user = false;
 
-ret = ssh_cmd_parse_request(cmd_ctx);
+ret = ssh_cmd_parse_request(cmd_ctx, NULL);
 if (ret != EOK) {
 goto done;
 }
@@ -681,7 +682,8 @@ ssh_host_pubkeys_update_known_hosts(struct ssh_cmd_ctx *cmd_ctx)
 }
 
 static errno_t
-ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx)
+ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx,
+  char *default_domain)
 {
 struct cli_protocol *pctx;
 struct ssh_ctx *ssh_ctx;
@@ -754,6 +756,8 @@ ssh_cmd_parse_request(struct ssh_cmd_ctx *cmd_ctx)
 return EINVAL;
 }
 c += domain_len;
+} else {
+domain = default_domain;
 }
 
 DEBUG(SSSDBG_TRACE_FUNC,
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#66][comment] Minor Dynamic DNS fixes

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/66
Title: #66: Minor Dynamic DNS fixes

lslebodn commented:
"""
I let fellow developers to review it.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/66#issuecomment-262816234
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#27][+Rejected] Minor code changes

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/27
Title: #27: Minor code changes

Label: +Rejected
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#27][comment] Minor code changes

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/27
Title: #27: Minor code changes

lslebodn commented:
"""
I finally tried the patch and here are logs before change
```
[sssd[be[LDAP]]] [sdap_get_generic_op_finished] (0x0400): Search result: 
Administrative limit exceeded(11), no errmsg set
[sssd[be[LDAP]]] [sdap_get_generic_op_finished] (0x0080): LDAP sizelimit was 
exceeded, returning incomplete data
```

and after change
```
[sssd[be[LDAP]]] [sdap_get_generic_op_finished] (0x0400): Search result: 
Administrative limit exceeded(11), no errmsg set
[sssd[be[LDAP]]] [sdap_get_generic_op_finished] (0x0080): LDAP server limit was 
exceeded, returning incomplete data: Administrative limit exceeded(11)
```

Personally, I do not see any benefit. I would prefer to reject the patch. I 
will wait few days before closing this PR.

"""

See the full comment at 
https://github.com/SSSD/sssd/pull/27#issuecomment-262816103
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#79][closed] BUILD: Drop libsss_config

2016-11-24 Thread lslebodn

   URL: https://github.com/SSSD/sssd/pull/79
Author: fidencio
 Title: #79: BUILD: Drop libsss_config
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/79/head:pr79
git checkout pr79
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#79][+Pushed] BUILD: Drop libsss_config

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/79
Title: #79: BUILD: Drop libsss_config

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#79][comment] BUILD: Drop libsss_config

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/79
Title: #79: BUILD: Drop libsss_config

lslebodn commented:
"""
`ChangeDebugLevelTemporarily` does not depend on auges so it can be removed 
later.
master:
* 99b2352f909c548811617389641a9ccc3e17bc53
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/79#issuecomment-262808633
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][comment] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

lslebodn commented:
"""
Updated version attached; waiting for result from CentOS CI.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/90#issuecomment-262783056
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][-Changes requested] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

Label: -Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#92][opened] UTIL: Fix compilation of sss_utf8 with libunistring

2016-11-24 Thread lslebodn

   URL: https://github.com/SSSD/sssd/pull/92
Author: lslebodn
 Title: #92: UTIL: Fix compilation of sss_utf8 with libunistring
Action: opened

PR body:
"""
The internal header file "util/util.h" was removed from sss_utf8.h
as part of commit de5fa34860886ad68fba5e739987e16c342e8f14.
It was neccessary to ensure libipa_hbac can be build with C90
compatible compiler.

This header file includes many system header file and after
this change caused missing declaration of the function free()

src/util/sss_utf8.c: In function ‘sss_utf8_free’:
src/util/sss_utf8.c:40:12: error: implicit declaration of function ‘free’
  [-Werror=implicit-function-declaration]
 return free(ptr);
^~~~
src/util/sss_utf8.c:40:12: warning: incompatible implicit declaration
of built-in function ‘free’
src/util/sss_utf8.c:40:12: note: include ‘’ or provide
 a declaration of ‘free’
cc1: some warnings being treated as errors
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/92/head:pr92
git checkout pr92
From 438ba2ede8378abe8eff125b53cd8315f54927e9 Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Fri, 18 Nov 2016 17:49:35 +0100
Subject: [PATCH] UTIL: Fix compilation of sss_utf8 with libunistring
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The internal header file "util/util.h" was removed from sss_utf8.h
as part of commit de5fa34860886ad68fba5e739987e16c342e8f14.
It was neccessary to ensure libipa_hbac can be build with C90
compatible compiler.

This header file includes many system header file and after
this change caused missing declaration of the function free()

src/util/sss_utf8.c: In function ‘sss_utf8_free’:
src/util/sss_utf8.c:40:12: error: implicit declaration of function ‘free’
  [-Werror=implicit-function-declaration]
 return free(ptr);
^~~~
src/util/sss_utf8.c:40:12: warning: incompatible implicit declaration
of built-in function ‘free’
src/util/sss_utf8.c:40:12: note: include ‘’ or provide
 a declaration of ‘free’
cc1: some warnings being treated as errors
---
 src/util/sss_utf8.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/sss_utf8.c b/src/util/sss_utf8.c
index 722f28d..e62e9c6 100644
--- a/src/util/sss_utf8.c
+++ b/src/util/sss_utf8.c
@@ -26,6 +26,7 @@
 #include 
 
 #ifdef HAVE_LIBUNISTRING
+#include 
 #include 
 #include 
 #elif defined(HAVE_GLIB2)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Design document - Socket-activatable responders

2016-11-24 Thread Fabiano Fidêncio

The design page is done [0] and it's based on this discussion [1] we
had on this very same mailing list. A pull-request with the
implementation is already opened [2].

[0]: https://fedorahosted.org/sssd/wiki/DesignDocs/SocketActivatableResponders
[1]: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org/message/H6JOF5SGGSIJUIWYNANDA73ODHWBS7J2/
[2]: https://github.com/SSSD/sssd/pull/84

The full text of c here:

= Socket Activatable Responders =

Related ticket(s):
 * https://fedorahosted.org/sssd/ticket/2243
 * https://fedorahosted.org/sssd/ticket/3129

=== Problem statement ===
SSSD has some responders which don't have to be running all the time,
but could be socket-activated instead in platforms where it's
supported. That's the case, for instance, for the IFP, ssh and sudo
responders.
Making these responders socket-activated would provide a better use
experience, as these services could be started on-demand when a client
needs them and exist after a period of inactivity. Currently the admin
has to explicitly list all the services that might potentially be
needed in the `services` section and the processes have to be running
all the time.

=== Use cases ===

 sssctl  
As more and more features that had been added depending on the IFP
responder, we should make sure that the responder is activated on
demand and the admins doesn't have to activate it manually.

 KCM 
The KCM responder is only seldom needed, when libkrb5 needs to access
the credentials store. At the same time, the KCM responder must be
running if the Kerberos credentials cache defaults to `KCM`.
Socket-activating the responder would solve both of these cases.

 autofs 
The autofs responder is typically only needed when a share is about to
be mounted.

=== Overview of the solution ===
The solution agreed on the mailing list is to add a new unit for each
one of the responders. Once a responder is started, it will
communicate to the monitor in order to let the monitor know that it's
up and the monitor will do the registration of the responder, which
basically consists in marking the service as started, increasing the
services' counter, getting the responder's configuratiom, adding the
responder to the service's list.
A configurable idle timeout will be implemented in each responder, as
part of this task, in order to exit the responder in case it's not
used for a few minutes.

=== Implementation details ===
In order to achieve our goal we will need a small modification in
responders' common code in order to make it ready for
socket-activation, add some systemd units for each of the responders
and finally small changes in the monitor code in order to manage the
new activated service.

The change in the responders' common code is quite trivial, just
chnage the sss_process_init code to call activate_unix_sockets()
istead of set_unix_socket(). Something like:
{{{
-ret = set_unix_socket(rctx, conn_setup);
+ret = activate_unix_sockets(rctx, conn_setup);
}}}

The units that have to be added for each responder must look like:

sssd-@respon...@.service.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder
Documentation=man:sssd.conf(5)
Requires=sssd.service
PartOf=sssd.service
After=sssd.service

[Install]
Also=sssd-@responder@.socket

[Service]
ExecStart=@libexecdir@/sssd/sssd_@responder@ --uid 0 --gid 0 --debug-to-files
}}}

sssd-@respon...@.socket.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder socket
Documentation=man:sssd.conf(5)

[Socket]
ListenStream=@pipepath@/@responder@

[Install]
WantedBy=sockets.target
}}}

Some responders may have more than one socket, which is the case of
PAM, so another unit will be needed.

sssd-@respon...@-priv.socket.in:
{{{
[Unit]
Description=SSSD @responder@ Service responder private socket
Documentation=man:sssd.conf(5)

[Socket]
ListenStream=@pipepath@/private/@responder@

[Install]
WantedBy=sockets.target
}}}

Last but not least, the IFP responder doesn't have a socket. It's
going to be D-Bus activated and some small changes will be required on
its D-Bus service unit.
{{{
-Exec=@libexecdir@/sssd/sss_signal
+Exec=@libexecdir@/sssd/sssd_@responder@
}}}

And, finally, the code in the monitor side will have to have some
adjustments in order to properly deal with an empty list of services
and, also, to register the service when it's started.

As just the responders' will be socket-activated for now, the service
type will have to exposed and passed through sbus when calling the
RegistrationService method and the monitor will have to properly do
the registration of the service when RegistrationService's callback is
triggered. As mentioned before, the "registration" that has to be done
from the monitor's side is:
 * Mark the service as started;
 * Increase the services' counter;
 * Get the responders' configuration;
 * Set the service's restart number;
 * Add the service to the services' list.

=== Configuration changes ===
After this design

[SSSD] [sssd PR#90][synchronized] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread lslebodn

   URL: https://github.com/SSSD/sssd/pull/90
Author: lslebodn
 Title: #90: UTIL: Fix implicit declaration of function 'htobe32'
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/90/head:pr90
git checkout pr90
From 73f23558a7a843b781d7a070b9ecef9dc61e6ce2 Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Fri, 18 Nov 2016 17:29:44 +0100
Subject: [PATCH] UTIL: Fix implicit declaration of function 'htobe32'

Include internal wrapper header file for endian related functions.
The "util/sss_endian.h" include available header file on different
platform or it provides compatible macros in the worst case.

Breakage noticed when building SSSD on FreeBSD

  CC   src/util/cert/nss/libsss_cert_la-cert.lo
src/util/cert/nss/cert.c: In function 'cert_to_ssh_key':
src/util/cert/nss/cert.c:358: error: implicit declaration of function 'htobe32'
gmake[2]: *** [Makefile:12421: src/util/cert/nss/libsss_cert_la-cert.lo] Error 1
gmake[2]: Leaving directory '/root/sssd_from_git'
gmake[1]: *** [Makefile:20050: all-recursive] Error 1
gmake[1]: Leaving directory '/root/sssd_from_git'
gmake: *** [Makefile:7116: all] Error 2
---
 src/util/cert/libcrypto/cert.c | 1 +
 src/util/cert/nss/cert.c   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/util/cert/libcrypto/cert.c b/src/util/cert/libcrypto/cert.c
index aba598d..c54db86 100644
--- a/src/util/cert/libcrypto/cert.c
+++ b/src/util/cert/libcrypto/cert.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "util/util.h"
+#include "util/sss_endian.h"
 
 errno_t sss_cert_der_to_pem(TALLOC_CTX *mem_ctx, const uint8_t *der_blob,
 size_t der_size, char **pem, size_t *pem_size)
diff --git a/src/util/cert/nss/cert.c b/src/util/cert/nss/cert.c
index b5e0ff9..9d31cfe 100644
--- a/src/util/cert/nss/cert.c
+++ b/src/util/cert/nss/cert.c
@@ -31,6 +31,7 @@
 #include "util/crypto/sss_crypto.h"
 #include "util/crypto/nss/nss_util.h"
 #include "util/cert.h"
+#include "util/sss_endian.h"
 
 #define NS_CERT_HEADER "-BEGIN CERTIFICATE-"
 #define NS_CERT_TRAILER "-END CERTIFICATE-"
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#91][opened] sssctl: Fix missing declaration

2016-11-24 Thread lslebodn

   URL: https://github.com/SSSD/sssd/pull/91
Author: lslebodn
 Title: #91: sssctl: Fix missing declaration
Action: opened

PR body:
"""
The WEXITSTATUS is defined in stdlib.h on linux.
There is a nice comment in stdlib.h:
  /* Define the macros  also would define this way.  */

It's better to not rely on this and use more platfom friendly
way with including "sys/wait.h".

I found this macro mentioned only in the manual page for wait(2)
and there is mentioned just the "sys/wait.h" and not "stdlib.h"

src/tools/sssctl/sssctl.c: In function 'sssctl_run_command':
src/tools/sssctl/sssctl.c:110: error: implicit declaration of function
'WEXITSTATUS'
gmake[2]: *** [Makefile:22383: src/tools/sssctl/sssctl-sssctl.o] Error 1
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/91/head:pr91
git checkout pr91
From 51135e79ca03723bde0393c6d81fa4d157b653cc Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Fri, 18 Nov 2016 17:58:28 +0100
Subject: [PATCH] sssctl: Fix missing declaration

The WEXITSTATUS is defined in stdlib.h on linux.
There is a nice comment in stdlib.h:
  /* Define the macros  also would define this way.  */

It's better to not rely on this and use more platfom friendly
way with including "sys/wait.h".

I found this macro mentioned only in the manual page for wait(2)
and there is mentioned just the "sys/wait.h" and not "stdlib.h"

src/tools/sssctl/sssctl.c: In function 'sssctl_run_command':
src/tools/sssctl/sssctl.c:110: error: implicit declaration of function
'WEXITSTATUS'
gmake[2]: *** [Makefile:22383: src/tools/sssctl/sssctl-sssctl.o] Error 1
---
 src/tools/sssctl/sssctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/tools/sssctl/sssctl.c b/src/tools/sssctl/sssctl.c
index ece1e6d..e1cf463 100644
--- a/src/tools/sssctl/sssctl.c
+++ b/src/tools/sssctl/sssctl.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 
 #include "util/util.h"
 #include "tools/sssctl/sssctl.h"
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] Re: [SSSD-users] Re: Re: Announcing SSSD 1.14.2

2016-11-24 Thread Joakim Tjernlund

On Mon, 2016-11-07 at 12:08 +0100, Lukas Slebodnik wrote:
> On (20/10/16 06:58), Joakim Tjernlund wrote:
> > 
> > On Wed, 2016-10-19 at 21:48 +0200, Jakub Hrozek wrote:
> > > 
> > >   === SSSD 1.14.2 ===
> > > 
> > > The SSSD team is proud to announce the release of version 1.14.2 of
> > > the System Security Services Daemon.
> > > 
> > > As always, the source is available from https://fedorahosted.org/sssd
> > > 
> > > RPM packages will be made available for Fedora shortly.
> > > 
> > > == Feedback ==
> > > Please provide comments, bugs and other feedback via the sssd-devel
> > > or sssd-users mailing lists:
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> > > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> > >  
> > 
> > hmm, I still get:
> > libtool: link: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC  
> > src/providers/krb5/.libs/libsss_krb5_la-
> > krb5_init.o   -Wl,-rpath 
> > -Wl,/var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-1.14.2-abi_x86_64.amd64/.libs
> >  
> > -Wl,-rpath -Wl,/usr/lib64/sssd 
> > -L/var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-1.14.2-
> > abi_x86_64.amd64/.libs -Wl,--as-needed -L/usr/lib64 ./.libs/libsss_util.so 
> > -lpopt -lldb -ldbus-1 -lpcre
> > /usr/lib64/libini_config.so /usr/lib64/libpath_utils.so 
> > /usr/lib64/libbasicobjects.so
> > /usr/lib64/libref_array.so /usr/lib64/libcollection.so 
> > /usr/lib64/libldap.so /usr/lib64/liblber.so
> > -lresolv -lsasl2 -lgnutls /usr/lib64/libgcrypt.so -lgpg-error -ltdb 
> > -lglib-2.0 /var/tmp/portage/sys-
> > auth/sssd-1.14.2/work/sssd-1.14.2-abi_x86_64.amd64/.libs/libsss_child.so 
> > /var/tmp/portage/sys-auth/sssd-
> > 1.14.2/work/sssd-1.14.2-abi_x86_64.amd64/.libs/libsss_cert.so 
> > /var/tmp/portage/sys-auth/sssd-
> > 1.14.2/work/sssd-1.14.2-abi_x86_64.amd64/.libs/libsss_crypt.so 
> > ./.libs/libsss_crypt.so -lcrypto
> > ./.libs/libsss_debug.so ./.libs/libsss_child.so -ltevent -ltalloc 
> > /var/tmp/portage/sys-auth/sssd-
> > 1.14.2/work/sssd-1.14.2-abi_x86_64.amd64/.libs/libsss_debug.so 
> > ./.libs/libsss_krb5_common.so -lkeyutils
> > /usr/lib64/libdhash.so -lkrb5 -lk5crypto -lcom_err  -O2 -Wl,-O1   
> > -Wl,-soname -Wl,libsss_krb5.so -o
> > .libs/libsss_krb5.so
> > ./.libs/libsss_util.so: undefined reference to `timer_settime'
> > ./.libs/libsss_util.so: undefined reference to `timer_delete'
> > ./.libs/libsss_util.so: undefined reference to `timer_create'
> > collect2: error: ld returned 1 exit status
> > libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wshadow -Wstrict-prototypes 
> > -Wpointer-arith -Wcast-qual
> > -Wcast-align -Wwrite-strings -Wundef -Werror-implicit-function-declaration 
> > -Winit-self -Wmissing-include-
> > dirs -fno-strict-aliasing -std=gnu99 -O2 -pipe -D_FILE_OFFSET_BITS=64 
> > -D_LARGEFILE_SOURCE
> > -D_LARGEFILE64_SOURCE -Wl,-O1 -o .libs/sss_ssh_knownhostsproxy 
> > src/sss_client/sss_ssh_knownhostsproxy-
> > common.o src/sss_client/ssh/sss_ssh_knownhostsproxy-sss_ssh_client.o
> > src/sss_client/ssh/sss_ssh_knownhostsproxy-sss_ssh_knownhostsproxy.o 
> > -Wl,-rpath -Wl,/usr/lib64  -Wl,--as-
> > needed ./.libs/libsss_util.so -L/usr/lib64 -lldb -ldbus-1 -lpcre 
> > /usr/lib64/libini_config.so
> > /usr/lib64/libpath_utils.so /usr/lib64/libbasicobjects.so 
> > /usr/lib64/libref_array.so
> > /usr/lib64/libcollection.so /usr/lib64/libldap.so /usr/lib64/liblber.so 
> > -lresolv -lsasl2 -lgnutls
> > /usr/lib64/libgcrypt.so -lgpg-error -ltdb -lglib-2.0 
> > /var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-
> > 1.14.2-abi_x86_64.amd64/.libs/libsss_child.so 
> > /var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-1.14.2-
> > abi_x86_64.amd64/.libs/libsss_cert.so 
> > /var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-1.14.2-
> > abi_x86_64.amd64/.libs/libsss_crypt.so ./.libs/libsss_crypt.so -lcrypto 
> > ./.libs/libsss_debug.so
> > ./.libs/libsss_child.so -ltevent /usr/lib64/libdhash.so 
> > /var/tmp/portage/sys-auth/sssd-1.14.2/work/sssd-
> > 1.14.2-abi_x86_64.amd64/.libs/libsss_debug.so -lpthread -ltalloc -lpopt 
> > -Wl,-rpath -Wl,/usr/lib64/sssd
> > Makefile:11323: recipe for target 'sss_ssh_authorizedkeys' failed
> > make[2]: *** [sss_ssh_authorizedkeys] Error 1
> > make[2]: *** Waiting for unfinished jobs
> > ./.libs/libsss_util.so: undefined reference to `timer_settime'
> > ./.libs/libsss_util.so: undefined reference to `timer_delete'
> > ./.libs/libsss_util.so: undefined reference to `timer_create'
> > collect2: error: ld returned 1 exit status
> > Makefile:11336: recipe for target 'sss_ssh_knownhostsproxy' failed
> > make[2]: *** [sss_ssh_knownhostsproxy] Error 1
> > 
> > I thought this was fixed(linking with librt that is)?
> > 
> Could you test attached patch?
Tested:
...
checking for library containing timer_create... -lrt

and it builds and starts too :)

 Jocke
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][comment] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

fidencio commented:
"""
So, discussing in person with Lukáš he told me the compilation error happened 
when building sssd for BSD.
Would you mind including a mention to that in the commit message? Something 
like "Breakage noticed when building SSSD on *BSD" (or anything towards this 
line ...)

Is this the only breakage we have there? I'll wait for the whole series :-)
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/90#issuecomment-262771305
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#90][+Changes requested] UTIL: Fix implicit declaration of function 'htobe32'

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/90
Title: #90: UTIL: Fix implicit declaration of function 'htobe32'

Label: +Changes requested
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][comment] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/87
Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

jhrozek commented:
"""
* sssd-1-13: 6ec33f5acfba6fa266c1dd7722c0c7bb88333f7f
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/87#issuecomment-262770205
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][-Accepted] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/87
Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

Label: -Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][+Pushed] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/87
Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][comment] sss_client: Defer thread cancellation until completion of nss/pam operations

2016-11-24 Thread lslebodn

  URL: https://github.com/SSSD/sssd/pull/46
Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations

lslebodn commented:
"""
master:
* d2f93542650c2f9613043acfa8e2f368972a70cd
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/46#issuecomment-262760584
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][closed] sss_client: Defer thread cancellation until completion of nss/pam operations

2016-11-24 Thread lslebodn

   URL: https://github.com/SSSD/sssd/pull/46
Author: HouzuoGuo
 Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/46/head:pr46
git checkout pr46
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][synchronized] sss_client: Defer thread cancellation until completion of nss/pam operations

2016-11-24 Thread HouzuoGuo

   URL: https://github.com/SSSD/sssd/pull/46
Author: HouzuoGuo
 Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/46/head:pr46
git checkout pr46
From 3eae3802347e244a032624733ae28b720feba1d5 Mon Sep 17 00:00:00 2001
From: Howard Guo 
Date: Tue, 11 Oct 2016 10:35:13 +0200
Subject: [PATCH] sss_client: Defer thread cancellation until completion of
 nss/pam operations

https://fedorahosted.org/sssd/ticket/3156

The client code is not cancellation-safe, an application which has cancelled an NSS operation
will experience subtle bugs, hence thread cancellation is deferred until completion of client
operations.
---
 Makefile.am |  4 ---
 src/sss_client/common.c | 80 +
 2 files changed, 7 insertions(+), 77 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1ea8f50..ca561de 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -771,10 +771,6 @@ endif
 
 CLIENT_LIBS = $(LTLIBINTL)
 
-if HAVE_PTHREAD
-CLIENT_LIBS += -lpthread
-endif
-
 if WITH_JOURNALD
 SYSLOG_LIBS = $(JOURNALD_LIBS)
 endif
diff --git a/src/sss_client/common.c b/src/sss_client/common.c
index 20106b1..b7a5ed7 100644
--- a/src/sss_client/common.c
+++ b/src/sss_client/common.c
@@ -1070,86 +1070,28 @@ typedef void (*sss_mutex_init)(void);
 struct sss_mutex {
 pthread_mutex_t mtx;
 
-pthread_once_t once;
-sss_mutex_init init;
+int old_cancel_state;
 };
 
-static void sss_nss_mt_init(void);
-static void sss_pam_mt_init(void);
-static void sss_nss_mc_mt_init(void);
+static struct sss_mutex sss_nss_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER };
 
-static struct sss_mutex sss_nss_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-.once = PTHREAD_ONCE_INIT,
-.init = sss_nss_mt_init };
+static struct sss_mutex sss_pam_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER };
 
-static struct sss_mutex sss_pam_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-.once = PTHREAD_ONCE_INIT,
-.init = sss_pam_mt_init };
-
-static struct sss_mutex sss_nss_mc_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-   .once = PTHREAD_ONCE_INIT,
-   .init = sss_nss_mc_mt_init };
-
-/* Wrappers for robust mutex support */
-static int sss_mutexattr_setrobust (pthread_mutexattr_t *attr)
-{
-#ifdef HAVE_PTHREAD_MUTEXATTR_SETROBUST
-return pthread_mutexattr_setrobust(attr, PTHREAD_MUTEX_ROBUST);
-#elif defined(HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP)
-return pthread_mutexattr_setrobust_np(attr, PTHREAD_MUTEX_ROBUST_NP);
-#else
-#warning Robust mutexes are not supported on this platform.
-return 0;
-#endif
-}
-
-static int sss_mutex_consistent(pthread_mutex_t *mtx)
-{
-#ifdef HAVE_PTHREAD_MUTEX_CONSISTENT
-return pthread_mutex_consistent(mtx);
-#elif defined(HAVE_PTHREAD_MUTEX_CONSISTENT_NP)
-return pthread_mutex_consistent_np(mtx);
-#else
-#warning Robust mutexes are not supported on this platform.
-return 0;
-#endif
-}
-
-/* Generic mutex init, lock, unlock functions */
-static void sss_mt_init(struct sss_mutex *m)
-{
-pthread_mutexattr_t attr;
-
-if (pthread_mutexattr_init() != 0) {
-return;
-}
-if (sss_mutexattr_setrobust() != 0) {
-return;
-}
-
-pthread_mutex_init(>mtx, );
-pthread_mutexattr_destroy();
-}
+static struct sss_mutex sss_nss_mc_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER };
 
 static void sss_mt_lock(struct sss_mutex *m)
 {
-pthread_once(>once, m->init);
-if (pthread_mutex_lock(>mtx) == EOWNERDEAD) {
-sss_cli_close_socket();
-sss_mutex_consistent(>mtx);
-}
+pthread_mutex_lock(>mtx);
+pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, >old_cancel_state);
 }
 
 static void sss_mt_unlock(struct sss_mutex *m)
 {
+pthread_setcancelstate(m->old_cancel_state, NULL);
 pthread_mutex_unlock(>mtx);
 }
 
 /* NSS mutex wrappers */
-static void sss_nss_mt_init(void)
-{
-sss_mt_init(_nss_mtx);
-}
 void sss_nss_lock(void)
 {
 sss_mt_lock(_nss_mtx);
@@ -1160,10 +1102,6 @@ void sss_nss_unlock(void)
 }
 
 /* NSS mutex wrappers */
-static void sss_pam_mt_init(void)
-{
-sss_mt_init(_pam_mtx);
-}
 void sss_pam_lock(void)
 {
 sss_mt_lock(_pam_mtx);
@@ -1174,10 +1112,6 @@ void sss_pam_unlock(void)
 }
 
 /* NSS mutex wrappers */
-static void sss_nss_mc_mt_init(void)
-{
-sss_mt_init(_nss_mc_mtx);
-}
 void sss_nss_mc_lock(void)
 {
 sss_mt_lock(_nss_mc_mtx);
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][comment] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/87
Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

fidencio commented:
"""
Simple fix.
Acked-by: Fabiano Fidêncio 
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/87#issuecomment-262737696
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][+Accepted] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread fidencio

  URL: https://github.com/SSSD/sssd/pull/87
Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

Label: +Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][opened] SYSDB: Only process aliases if they are non-NULL

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/87
Author: jhrozek
 Title: #87: SYSDB: Only process aliases if they are non-NULL
Action: opened

PR body:
"""
This bug was found by downstream coverity check.

The aliases array is created by sysdb_get_sudo_user_info() which returns a NULL 
array if there are no aliases. We need to avoid dereferencing the array in that 
case.
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/87/head:pr87
git checkout pr87
From 520bb404dee3e40088cd5bccf5c3bcc7e1c638f1 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek 
Date: Thu, 24 Nov 2016 10:57:44 +0100
Subject: [PATCH] SYSDB: Only process aliases if they are non-NULL

---
 src/db/sysdb_sudo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/db/sysdb_sudo.c b/src/db/sysdb_sudo.c
index de1e8da..420c9e6 100644
--- a/src/db/sysdb_sudo.c
+++ b/src/db/sysdb_sudo.c
@@ -259,7 +259,7 @@ sysdb_get_sudo_filter(TALLOC_CTX *mem_ctx, const char *username, char **aliases,
  sanitized);
 NULL_CHECK(specific_filter, ret, done);
 
-if (case_sensitive_domain == false) {
+if (case_sensitive_domain == false && aliases != NULL) {
 for (i = 0; aliases[i] != NULL; i++) {
 specific_filter = talloc_asprintf_append(specific_filter, "(%s=%s)",
  SYSDB_SUDO_CACHE_AT_USER,
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#87][edited] SYSDB: Only process aliases if they are non-NULL (sssd-1-13)

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/87
Author: jhrozek
 Title: #87: SYSDB: Only process aliases if they are non-NULL (sssd-1-13)
Action: edited

 Changed field: title
Original value:
"""
SYSDB: Only process aliases if they are non-NULL
"""

___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#86][closed] SYSDB: check aliases before using them (sssd-1-13 only)

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/86
Author: jhrozek
 Title: #86: SYSDB: check aliases before using them (sssd-1-13 only)
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/86/head:pr86
git checkout pr86
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#86][comment] SYSDB: check aliases before using them (sssd-1-13 only)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/86
Title: #86: SYSDB: check aliases before using them (sssd-1-13 only)

jhrozek commented:
"""
apparently I can't use the hub tool, sorry
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/86#issuecomment-262736028
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#46][synchronized] sss_client: Defer thread cancellation until completion of nss/pam operations

2016-11-24 Thread HouzuoGuo

   URL: https://github.com/SSSD/sssd/pull/46
Author: HouzuoGuo
 Title: #46: sss_client: Defer thread cancellation until completion of nss/pam 
operations
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/46/head:pr46
git checkout pr46
From 176a84c1add79398f342157a12945838bbb1ef0e Mon Sep 17 00:00:00 2001
From: Howard Guo 
Date: Tue, 11 Oct 2016 10:35:13 +0200
Subject: [PATCH 1/3] sss_client: Defer thread cancellation until completion of
 nss/pam operations

https://fedorahosted.org/sssd/ticket/3156

The client code is not cancellation-safe, an application which has cancelled an NSS operation
will experience subtle bugs, hence thread cancellation is deferred until completion of client
operations.
---
 Makefile.am |  4 ---
 src/sss_client/common.c | 74 +
 2 files changed, 7 insertions(+), 71 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 1ea8f50..ca561de 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -771,10 +771,6 @@ endif
 
 CLIENT_LIBS = $(LTLIBINTL)
 
-if HAVE_PTHREAD
-CLIENT_LIBS += -lpthread
-endif
-
 if WITH_JOURNALD
 SYSLOG_LIBS = $(JOURNALD_LIBS)
 endif
diff --git a/src/sss_client/common.c b/src/sss_client/common.c
index 20106b1..61ec55e 100644
--- a/src/sss_client/common.c
+++ b/src/sss_client/common.c
@@ -1071,85 +1071,33 @@ struct sss_mutex {
 pthread_mutex_t mtx;
 
 pthread_once_t once;
-sss_mutex_init init;
+int old_cancel_state;
 };
 
-static void sss_nss_mt_init(void);
-static void sss_pam_mt_init(void);
 static void sss_nss_mc_mt_init(void);
 
 static struct sss_mutex sss_nss_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-.once = PTHREAD_ONCE_INIT,
-.init = sss_nss_mt_init };
+.once = PTHREAD_ONCE_INIT };
 
 static struct sss_mutex sss_pam_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-.once = PTHREAD_ONCE_INIT,
-.init = sss_pam_mt_init };
+.once = PTHREAD_ONCE_INIT };
 
 static struct sss_mutex sss_nss_mc_mtx = { .mtx  = PTHREAD_MUTEX_INITIALIZER,
-   .once = PTHREAD_ONCE_INIT,
-   .init = sss_nss_mc_mt_init };
-
-/* Wrappers for robust mutex support */
-static int sss_mutexattr_setrobust (pthread_mutexattr_t *attr)
-{
-#ifdef HAVE_PTHREAD_MUTEXATTR_SETROBUST
-return pthread_mutexattr_setrobust(attr, PTHREAD_MUTEX_ROBUST);
-#elif defined(HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP)
-return pthread_mutexattr_setrobust_np(attr, PTHREAD_MUTEX_ROBUST_NP);
-#else
-#warning Robust mutexes are not supported on this platform.
-return 0;
-#endif
-}
-
-static int sss_mutex_consistent(pthread_mutex_t *mtx)
-{
-#ifdef HAVE_PTHREAD_MUTEX_CONSISTENT
-return pthread_mutex_consistent(mtx);
-#elif defined(HAVE_PTHREAD_MUTEX_CONSISTENT_NP)
-return pthread_mutex_consistent_np(mtx);
-#else
-#warning Robust mutexes are not supported on this platform.
-return 0;
-#endif
-}
-
-/* Generic mutex init, lock, unlock functions */
-static void sss_mt_init(struct sss_mutex *m)
-{
-pthread_mutexattr_t attr;
-
-if (pthread_mutexattr_init() != 0) {
-return;
-}
-if (sss_mutexattr_setrobust() != 0) {
-return;
-}
-
-pthread_mutex_init(>mtx, );
-pthread_mutexattr_destroy();
-}
+   .once = PTHREAD_ONCE_INIT };
 
 static void sss_mt_lock(struct sss_mutex *m)
 {
-pthread_once(>once, m->init);
-if (pthread_mutex_lock(>mtx) == EOWNERDEAD) {
-sss_cli_close_socket();
-sss_mutex_consistent(>mtx);
-}
+pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, >old_cancel_state);
+pthread_mutex_lock(>mtx);
 }
 
 static void sss_mt_unlock(struct sss_mutex *m)
 {
 pthread_mutex_unlock(>mtx);
+pthread_setcancelstate(m->old_cancel_state, NULL);
 }
 
 /* NSS mutex wrappers */
-static void sss_nss_mt_init(void)
-{
-sss_mt_init(_nss_mtx);
-}
 void sss_nss_lock(void)
 {
 sss_mt_lock(_nss_mtx);
@@ -1160,10 +1108,6 @@ void sss_nss_unlock(void)
 }
 
 /* NSS mutex wrappers */
-static void sss_pam_mt_init(void)
-{
-sss_mt_init(_pam_mtx);
-}
 void sss_pam_lock(void)
 {
 sss_mt_lock(_pam_mtx);
@@ -1174,10 +1118,6 @@ void sss_pam_unlock(void)
 }
 
 /* NSS mutex wrappers */
-static void sss_nss_mc_mt_init(void)
-{
-sss_mt_init(_nss_mc_mtx);
-}
 void sss_nss_mc_lock(void)
 {
 sss_mt_lock(_nss_mc_mtx);

From 22762ebecdead93764197b0fc245a1d6909b68d7 Mon Sep 17 00:00:00 2001
From: HouzuoGuo 
Date: Wed, 9 Nov 2016 12:10:25 +0100
Subject: [PATCH 2/3] Remove unused sss_mutex.once; correct the order of
 locking mutex and setting thread cancel state.

---
 src/sss_client/common.c | 14 +-
 1 file

[SSSD] [sssd PR#39][closed] RESPONDER: Enable sudoRule in case insen. domains (1.13)

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/39
Author: celestian
 Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/39/head:pr39
git checkout pr39
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#39][+Pushed] RESPONDER: Enable sudoRule in case insen. domains (1.13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/39
Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#39][-Accepted] RESPONDER: Enable sudoRule in case insen. domains (1.13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/39
Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)

Label: -Accepted
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#39][comment] RESPONDER: Enable sudoRule in case insen. domains (1.13)

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/39
Title: #39: RESPONDER: Enable sudoRule in case insen. domains (1.13)

jhrozek commented:
"""
CI: http://sssd-ci.duckdns.org/logs/job/57/35/summary.html
sssd-1-13: b6d0b0a14c7f09371cbb2afd0347f6a16fcfc8dd
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/39#issuecomment-262723829
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#75][closed] Add configuirable max payload size limit of a secret

2016-11-24 Thread jhrozek

   URL: https://github.com/SSSD/sssd/pull/75
Author: fidencio
 Title: #75: Add configuirable max payload size limit of a secret
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/75/head:pr75
git checkout pr75
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#75][comment] Add configuirable max payload size limit of a secret

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/75
Title: #75: Add configuirable max payload size limit of a secret

jhrozek commented:
"""
master:
9ba53ac52b12e2b9fdd3981d28ae56a8fece0131
7171a7584dda534dde5409f3e7f4657e845ece15 
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/75#issuecomment-262723330
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#75][+Pushed] Add configuirable max payload size limit of a secret

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/75
Title: #75: Add configuirable max payload size limit of a secret

Label: +Pushed
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#75][comment] Add configuirable max payload size limit of a secret

2016-11-24 Thread jhrozek

  URL: https://github.com/SSSD/sssd/pull/75
Title: #75: Add configuirable max payload size limit of a secret

jhrozek commented:
"""
CI: http://sssd-ci.duckdns.org/logs/job/57/36/summary.html

the failure on rawhide is unrelated.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/75#issuecomment-262722314
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

55 matches

Mail list logo