sssd.git/src/config, branch certificate_mapping

RESPONDER: Shutdown {dbus,socket}-activated responders in case they're idle

2017-01-23T17:46:37+00:00

This commit introduces a new option for the responders called
responder_idle_timeout, which specifies the number of seconds that the
responder process can be up without being used. The default value is
300 seconds (5 minutes) and can be configured per responder, being 60
seconds the minimum acceptable value.

Is important to note that setting "responder_idle_timeout = 0" disables
the responder timeout, which makes sense for the responders that always
will be running.

The shutdown timeout is activated per responder in case the responder
has been {dbus,socket}-activated. In case of any commnunication with the
responder the timeout is reset thereby ensuring we won't shutdown a
responder that is not idle.

Setting the responder's last request time is done slightly differently
for socket-activated and dbus-activated responders. In both cases it's
updated in any internal communication in sbus_message_handler(), but
for the socket-activated responders it's also updated when the
responder's socket is used.

Currently it works properly with all responders but the secrets one,
which has a different logic and must be treated separately in case some
change is required there.

Is worth to mention that this commit does not affect the responders
explicitly configured in the "services" line of sssd.conf.

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

Signed-off-by: Fabiano Fidêncio 
Reviewed-by: Pavel Březina 
Reviewed-by: Jakub Hrozek 
Reviewed-by: Lukáš Slebodník

SECRETS: Add configurable payload size limit of a secret

2016-11-24T08:55:45+00:00

Resolves:
https://fedorahosted.org/sssd/ticket/3169

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Jakub Hrozek 
Reviewed-by: Lukáš Slebodník

SECRETS: Add allowed_sec_users_options

2016-11-10T21:20:24+00:00

There are options (the proxying related ones) that only apply to the
secrets' subsections. In order to make config API able to catch those,
let's create a new section called allowed_sec_users_options) and move
there these proxying options.

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Jakub Hrozek

SECRETS: Fix secrets rule in the allowed sections

2016-11-10T21:20:16+00:00

We have been matching an invalid subsection of the secrets' section,
like:
[secrets/users/]

Let's ensure that we only match the following cases:
[secrets]
[secrets/users/[0-9]+]

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Lukáš Slebodník

PAM: add pam_response_filter option

2016-11-02T10:30:20+00:00

Currently the main use-case for this new option is to not set the
KRB5CCNAME environment varible for services like 'sudo-i'.

Resolves https://fedorahosted.org/sssd/ticket/2296

Reviewed-by: Jakub Hrozek

SECRETS: Add a configurable limit of secrets that can be stored

2016-10-05T09:57:20+00:00

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

Reviewed-by: Jakub Hrozek

SECRETS: Add a configurable depth limit for nested containers

2016-10-03T13:32:33+00:00

Resolves:
https://fedorahosted.org/sssd/ticket/3168

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Jakub Hrozek

CONFIG: Add secrets provider options

2016-10-03T13:32:23+00:00

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

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Jakub Hrozek

CONFIG: List allowed secrets responder options

2016-10-03T13:32:19+00:00

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

Reviewed-by: Fabiano Fidêncio

CONFIG: Add secrets responder to the allowed sections

2016-10-03T13:32:14+00:00

The regular expression used is quite specific for the two cases we
support:
- [secrets]
- [secrets/users/$uid]

It could be done a bit more generic, but the way it's right now it can
easily catch errors like: [secrets/usrs/$uid] or [secrets/].

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

Signed-off-by: Fabiano Fidêncio 

Reviewed-by: Jakub Hrozek