[SSSD] [sssd PR#102][opened] Sssctl no case sensitive searches

[mzidek-rh]

   URL: https://github.com/SSSD/sssd/pull/102
Author: mzidek-rh
 Title: #102: Sssctl no case sensitive searches
Action: opened

PR body:
"""
Trying to get rid of branches with smaller patches. Here is one of them.
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/102/head:pr102
git checkout pr102
From 20596900fca35c3039a22679f8eb4c7d1ba2be2e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20=C5=BDidek?= 
Date: Thu, 1 Dec 2016 15:56:39 +0100
Subject: [PATCH 1/3] common: Fix domain case sensitivity init

Fix initialization of domain case sensitivity.

Resolves:
https://fedorahosted.org/sssd/ticket/3235
---
 src/confdb/confdb.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/confdb/confdb.c b/src/confdb/confdb.c
index f0e3942..cfe765c 100644
--- a/src/confdb/confdb.c
+++ b/src/confdb/confdb.c
@@ -1292,7 +1292,7 @@ static int confdb_get_domain_internal(struct confdb_ctx *cdb,
 }
 
 tmp = ldb_msg_find_attr_as_string(res->msgs[0],
-  CONFDB_DOMAIN_CASE_SENSITIVE, "true");
+  CONFDB_DOMAIN_CASE_SENSITIVE, NULL);
 if (tmp != NULL) {
 if (strcasecmp(tmp, "true") == 0) {
 domain->case_sensitive = true;
@@ -1310,9 +1310,15 @@ static int confdb_get_domain_internal(struct confdb_ctx *cdb,
 }
 } else {
 /* default */
-domain->case_sensitive = true;
-domain->case_preserve = true;
+if (strcasecmp(domain->provider, "ad") == 0) {
+domain->case_sensitive = false;
+domain->case_sensitive = false;
+} else {
+domain->case_sensitive = true;
+domain->case_preserve = true;
+}
 }
+
 if (domain->case_sensitive == false &&
 strcasecmp(domain->provider, "local") == 0) {
 DEBUG(SSSDBG_FATAL_FAILURE,

From 89d31727c8292aefb333e11899635dbeaa223993 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20=C5=BDidek?= 
Date: Thu, 1 Dec 2016 14:51:37 +0100
Subject: [PATCH 2/3] sssctl: Users and groups search by alias

Also search by alias when using sssctl user/group-show command.

Resolves:
https://fedorahosted.org/sssd/ticket/3235
---
 src/tools/sssctl/sssctl_cache.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/tools/sssctl/sssctl_cache.c b/src/tools/sssctl/sssctl_cache.c
index b1a7cc9..93601b9 100644
--- a/src/tools/sssctl/sssctl_cache.c
+++ b/src/tools/sssctl/sssctl_cache.c
@@ -295,10 +295,12 @@ static const char *sssctl_create_filter(TALLOC_CTX *mem_ctx,
 const char *filter;
 char *filter_value;
 bool qualify_attr = false;
+bool use_alias = false;
 
 if (strcmp(attr_name, SYSDB_NAME) == 0) {
 if (obj_type == CACHED_USER || obj_type == CACHED_GROUP) {
 qualify_attr = true;
+use_alias = true;
 }
 }
 
@@ -327,8 +329,15 @@ static const char *sssctl_create_filter(TALLOC_CTX *mem_ctx,
 return NULL;
 }
 
-filter = talloc_asprintf(mem_ctx, "(&(objectClass=%s)(%s=%s))",
- class, attr_name, filter_value);
+if (use_alias) {
+ filter = talloc_asprintf(mem_ctx, "(&(objectClass=%s)(|(%s=%s)(%s=%s)))",
+  class, attr_name, filter_value,
+  SYSDB_NAME_ALIAS, filter_value);
+} else {
+filter = talloc_asprintf(mem_ctx, "(&(objectClass=%s)(%s=%s))",
+ class, attr_name, filter_value);
+}
+
 talloc_free(filter_value);
 
 return filter;

From 04e8d5a5d2d85734cb3edd7b8097a7dc2c08f3d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michal=20=C5=BDidek?= 
Date: Thu, 1 Dec 2016 15:22:42 +0100
Subject: [PATCH 3/3] sssctl: Case insensitive filters

Lowercase the filter in case insensitive domains.

Resolves:
https://fedorahosted.org/sssd/ticket/3235
---
 src/tools/sssctl/sssctl_cache.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/tools/sssctl/sssctl_cache.c b/src/tools/sssctl/sssctl_cache.c
index 93601b9..a8d703d 100644
--- a/src/tools/sssctl/sssctl_cache.c
+++ b/src/tools/sssctl/sssctl_cache.c
@@ -329,6 +329,14 @@ static const char *sssctl_create_filter(TALLOC_CTX *mem_ctx,
 return NULL;
 }
 
+if (dom->case_sensitive == false) {
+char *filter_value_old;
+
+filter_value_old = filter_value;
+filter_value = sss_tc_utf8_str_tolower(mem_ctx, filter_value_old);
+talloc_free(filter_value_old);
+}
+
 if (use_alias) {
  filter = talloc_asprintf(mem_ctx, "(&(objectClass=%s)(|(%s=%s)(%s=%s)))",
   class, attr_name, filter_value,
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#102][comment] Sssctl no case sensitive searches

[mzidek-rh]

  URL: https://github.com/SSSD/sssd/pull/102
Title: #102: Sssctl no case sensitive searches

mzidek-rh commented:
"""
I need to write an intg test. So the review can wait.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/102#issuecomment-264207778
___
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

[Jakub Hrozek]

On Thu, Dec 01, 2016 at 03:59:37PM +0100, Fabiano Fidêncio wrote:
> On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce  wrote:
> > On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote:
> >> On 12/01/2016 02:56 PM, Simo Sorce wrote:
> >> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote:
> >> >> On 11/24/2016 02: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
> >> >>
> >> >> I think we should also provide 'disabled_services' option, to give
> >> >> admins a way to explicitly disable some responders if the don't want to
> >> >> used them.
> >> >
> >> > How would this work ?
> >>
> >> If responder is listed in disabled_services, it won't be allowed to
> >> start via socket activation. If disabling the socket as Fabiano
> >> mentioned in the other mail is enough, I'm fine with it, plese test.
> >
> > I am not sure this is a good behavior as clients will see a connection
> > being accept and then dropped, and may misbehave or report strange
> > errors.
> 
> So, thinking a little bit about it Pavel's idea is not bad.
> If you have a list of "not allowed"/"disabled" services we can, at
> least, report the proper error when enabling the service.

I don't know, to me it seems like if we are about to rely on systemd to
start the services we should just use the systemd facilities to manage
them. I'm not fond of the idea of yet another knob, or maybe I don't see
the benefit over disabling the socket.
___
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

[Fabiano Fidêncio]

On Thu, Dec 1, 2016 at 3:46 PM, Simo Sorce  wrote:
> On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote:
>> On 12/01/2016 02:56 PM, Simo Sorce wrote:
>> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote:
>> >> On 11/24/2016 02: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
>> >>
>> >> I think we should also provide 'disabled_services' option, to give
>> >> admins a way to explicitly disable some responders if the don't want to
>> >> used them.
>> >
>> > How would this work ?
>>
>> If responder is listed in disabled_services, it won't be allowed to
>> start via socket activation. If disabling the socket as Fabiano
>> mentioned in the other mail is enough, I'm fine with it, plese test.
>
> I am not sure this is a good behavior as clients will see a connection
> being accept and then dropped, and may misbehave or report strange
> errors.

So, thinking a little bit about it Pavel's idea is not bad.
If you have a list of "not allowed"/"disabled" services we can, at
least, report the proper error when enabling the service.

Does this sound reasonable to you?

>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
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

[Simo Sorce]

On Thu, 2016-12-01 at 15:22 +0100, Pavel Březina wrote:
> On 12/01/2016 02:56 PM, Simo Sorce wrote:
> > On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote:
> >> On 11/24/2016 02: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
> >>
> >> I think we should also provide 'disabled_services' option, to give
> >> admins a way to explicitly disable some responders if the don't want to
> >> used them.
> >
> > How would this work ?
> 
> If responder is listed in disabled_services, it won't be allowed to 
> start via socket activation. If disabling the socket as Fabiano 
> mentioned in the other mail is enough, I'm fine with it, plese test.

I am not sure this is a good behavior as clients will see a connection
being accept and then dropped, and may misbehave or report strange
errors.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
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

[Simo Sorce]

On Thu, 2016-12-01 at 15:19 +0100, Fabiano Fidêncio wrote:
> On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina  wrote:
> > On 11/24/2016 02: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]: htatps://github.com/SSSD/sssd/pull/84
> >
> >
> > I think we should also provide 'disabled_services' option, to give admins a
> > way to explicitly disable some responders if the don't want to used them.
> 
> I have to double check a few things here but, AFAIU, just having the
> socket disabled (systemctl disable sssd-@responder@.socket) should be
> enough.

I guess I misunderstood what ou mean by "provide 'disabled_services'
option", I though you wanted to add that option to sssd.conf

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
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

[Pavel Březina]

On 12/01/2016 02:56 PM, Simo Sorce wrote:

On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote:

On 11/24/2016 02: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


I think we should also provide 'disabled_services' option, to give
admins a way to explicitly disable some responders if the don't want to
used them.


How would this work ?


If responder is listed in disabled_services, it won't be allowed to 
start via socket activation. If disabling the socket as Fabiano 
mentioned in the other mail is enough, I'm fine with it, plese test.

___
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

[Fabiano Fidêncio]

On Thu, Dec 1, 2016 at 2:44 PM, Pavel Březina  wrote:
> On 11/24/2016 02: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]: htatps://github.com/SSSD/sssd/pull/84
>
>
> I think we should also provide 'disabled_services' option, to give admins a
> way to explicitly disable some responders if the don't want to used them.

I have to double check a few things here but, AFAIU, just having the
socket disabled (systemctl disable sssd-@responder@.socket) should be
enough.


>
> ___
> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
___
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

[Simo Sorce]

On Thu, 2016-12-01 at 14:44 +0100, Pavel Březina wrote:
> On 11/24/2016 02: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
> 
> I think we should also provide 'disabled_services' option, to give 
> admins a way to explicitly disable some responders if the don't want to 
> used them.

How would this work ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
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

[Pavel Březina]

On 11/24/2016 02: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


I think we should also provide 'disabled_services' option, to give 
admins a way to explicitly disable some responders if the don't want to 
used them.

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

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

[pbrezina]

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

pbrezina commented:
"""
Squashing is fine, of course. BTW I'm not quite sure if this version contains 
the uid/gid changes as I see it as parameters in all systemd unit files.

In my opinion, even private communication between responders and data providers 
should prolong the timeout. The communication is triggered by the client 
anyway. The basic idea is that when a client contacts responder, the responder 
contacts data provider and awaits reply. It may take a long time for the dp 
reply to come, but we are still not idle, we await a reply. It probably won't 
make much difference since we send reply to client as fast as we can when we 
get reply from dp so the timestamps will be similar, but we don't have to 
special case IFP anymore and I like that :-) What do other @SSSD/developers 
think?

The only incoming signal SSSD can handle right now is NameOwnerChange and this 
should not take part in the decision whether SSSD is idle or not. All signals 
are handled inside `sbus_signal_handler` and should not make it into message 
handler, if the do I'd consider it a bug. 
"""

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

[SSSD] [sssd PR#101][closed] SIFP: Fix warning format-security

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/101
Author: lslebodn
 Title: #101: SIFP: Fix warning format-security
Action: closed

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

[SSSD] [sssd PR#101][+Pushed] SIFP: Fix warning format-security

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/101
Title: #101: SIFP: Fix warning format-security

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#101][comment] SIFP: Fix warning format-security

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/101
Title: #101: SIFP: Fix warning format-security

lslebodn commented:
"""
On (01/12/16 04:25), Pavel Březina wrote:
>Obvious ack.
>
master:
* 8618716d6ed4eadca2743eb2dfbbb8d11c4fb22f

LS

"""

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

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

[fidencio]

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

fidencio commented:
"""
On Thu, Dec 1, 2016 at 1:03 PM, Pavel Březina 
wrote:

> Hi,
>
> if (ret != EOK) {
> #ifdef HAVE_SYSTEMD
> if (ret != ENOENT)
> #endif
> {
> DEBUG(SSSDBG_FATAL_FAILURE, "No services configured!\n");
> return EINVAL;
> }
> }
>
> can you separate above to:
>
> #ifdef HAVE_SYSTEMDif (ret != EOK && ret != ENOENT) {
> DEBUG(SSSDBG_FATAL_FAILURE, "No services configured!\n");
> return EINVAL;
> }
> #else
> ...
> #endif
>
>
Okay,


> We should also amend services option man page to describe what happens if
> a service is not listed there, that they are automatically activated when
> needed
>

Okay.


> .
>
> Now I have few more comments to the timeouts.
>
>1. I believe you can remove "RESPONDER: Shutdown
>{dbus,socket}-activated responders in case they're idle" in favor of
>"Change the timeout logic".
>
>
The "Change timeout logic" commit is a leftover that must have been
squashed to "RESPONDER: Shutdown {dbus,socket}-activated responders in case
they're idle". Sorry for messing it up.

Squashing it there is okay for you?


>
>1. Please use the same logic in sbus code. I think you just want to
>pass a pointer to last_request_time into sbus (to remove the need for
>function pointers) and let the sbus code update it when appropriate even
>for our private communication (in other responders). Because if a
>communication is happening between responder and provider, the responder is
>still not idle (it may be awaiting reply from data provider so it can be
>send to the client).
>
>
Okay, I can pass just the pointer to the last_request_time var into sbus.
Please, here I need a bit more pointers in order to be sure I understand
your suggestion.

Please, correct me if I'm wrong, it's updating the last_request_time even
for our private communication, no?
Are you talking specifically about IFP provider or the others? Because the
others have their last_request_time() updated everytime something goes
through their sockets and, as far as I understand, it should be enough,
right? If not, why not?



>
>1. Resetting the timeout when sbus signal is received is not enough.
>You want to reset it everytime any communication on the bus is happening. I
>actually think that signals are the only communication that we can skip for
>two reasons (One - we don't use any signals except NameOwnerChanged, Second
>- those are asynchronous events that do not require any reply). I think you
>want to reset the time in sbus_message_handler when you got a valid
>handler (interface and method combination. The you don't need the iface
>validator.
>
>
Hmmm. I see your point and it makes sense. But I have one question ... We
do receive signals from org.freedesktop.sssd.infopipe.* and they should be
treated, right? So we can't ignore it completely.

In case those signals end up in sbus_message_handler() as well, then I
agree with you. Is that the case?


>
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> , or mute
> the thread
> 
> .
>

Thanks a lot for the review, Pavel.

"""

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

[SSSD] [sssd PR#101][comment] SIFP: Fix warning format-security

[pbrezina]

  URL: https://github.com/SSSD/sssd/pull/101
Title: #101: SIFP: Fix warning format-security

pbrezina commented:
"""
Obvious ack.
"""

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

[SSSD] [sssd PR#101][opened] SIFP: Fix warning format-security

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/101
Author: lslebodn
 Title: #101: SIFP: Fix warning format-security
Action: opened

PR body:
"""
dbus-1.11.8 added attributes for format string check to
few functions in public header files. And therefore there is a warning.

src/lib/sifp/sss_sifp_utils.c: In function ‘sss_sifp_set_io_error’:
src/lib/sifp/sss_sifp_utils.c:44:5: error: format not a string literal
and no format arguments [-Werror=format-security]
 dbus_set_error(ctx->io_error, error->name, error->message);
  ^~
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/101/head:pr101
git checkout pr101
From 038011b9121fff5ce0801e7ab3b49791079b91ac Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik 
Date: Thu, 1 Dec 2016 13:13:21 +0100
Subject: [PATCH] SIFP: Fix warning format-security
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

dbus-1.11.8 added attributes for format string check to
few functions in public header files. And therefore there is a warning.

src/lib/sifp/sss_sifp_utils.c: In function ‘sss_sifp_set_io_error’:
src/lib/sifp/sss_sifp_utils.c:44:5: error: format not a string literal
and no format arguments [-Werror=format-security]
 dbus_set_error(ctx->io_error, error->name, error->message);
  ^~
---
 src/lib/sifp/sss_sifp_utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/lib/sifp/sss_sifp_utils.c b/src/lib/sifp/sss_sifp_utils.c
index ccd0518..dcac71f 100644
--- a/src/lib/sifp/sss_sifp_utils.c
+++ b/src/lib/sifp/sss_sifp_utils.c
@@ -41,7 +41,7 @@ void sss_sifp_set_io_error(sss_sifp_ctx *ctx, DBusError *error)
 {
 dbus_error_free(ctx->io_error);
 dbus_error_init(ctx->io_error);
-dbus_set_error(ctx->io_error, error->name, error->message);
+dbus_set_error(ctx->io_error, error->name, "%s", error->message);
 }
 
 char * sss_sifp_strdup(sss_sifp_ctx *ctx, const char *str)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#100][comment] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds

[centos-ci]

  URL: https://github.com/SSSD/sssd/pull/100
Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval 
< 60 seconds

centos-ci commented:
"""
Can one of the admins verify this patch?
"""

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

[SSSD] [sssd PR#100][opened] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds

[amitkumar50]

   URL: https://github.com/SSSD/sssd/pull/100
Author: amitkumar50
 Title: #100: Updation of sssd-ad man page for case when 
dyndns_refresh_interval < 60 seconds
Action: opened

PR body:
"""
https://fedorahosted.org/sssd/ticket/2201
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/100/head:pr100
git checkout pr100
From 8bb51a3394fe0a5df3d2c26974c851b165d2e148 Mon Sep 17 00:00:00 2001
From: root 
Date: Thu, 1 Dec 2016 07:10:47 -0500
Subject: [PATCH] Updation of sssd-ad man page for case when
 dyndns_refresh_interval < 60 seconds

---
 src/man/sssd-ad.5.xml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/man/sssd-ad.5.xml b/src/man/sssd-ad.5.xml
index 8be1e78..1be6fa2 100644
--- a/src/man/sssd-ad.5.xml
+++ b/src/man/sssd-ad.5.xml
@@ -903,7 +903,8 @@ ad_gpo_map_deny = +my_pam_service
 addition to the automatic update performed when the back end
 goes online.
 This option is optional and applicable only when dyndns_update
-is true.
+is true.Note if dyndns_refresh_interval specified as less than
+60 seconds, actual refresh interval will be 60 seconds regardless.
 
 
 Default: 86400 (24 hours)
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#100][comment] Updation of sssd-ad man page for case when dyndns_refresh_interval < 60 seconds

[centos-ci]

  URL: https://github.com/SSSD/sssd/pull/100
Title: #100: Updation of sssd-ad man page for case when dyndns_refresh_interval 
< 60 seconds

centos-ci commented:
"""
Can one of the admins verify this patch?
"""

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