[SSSD] [sssd PR#81][comment] Please see the commit message, the fix is hopefully simple

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

jhrozek commented:
"""
Thanks for the review, I pushed a new version. I did test the patch (otherwise 
the conditional build of the files provider where I added AM_CONDITIONAL didn't 
work) but I have no idea how it could work :)

Anyway, let's see if this version is OK..
"""

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

[SSSD] [sssd PR#81][-Changes requested] Please see the commit message, the fix is hopefully simple

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

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#80][comment] SYSDB: Fixing of sudorule without a sudoUser

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/80
Title: #80: SYSDB: Fixing of sudorule without a sudoUser

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

the rawhide failure is not related, it's a know bug in the latest python-urllib 
release.
"""

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

[SSSD] [sssd PR#81][comment] Please see the commit message, the fix is hopefully simple

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

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

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

[SSSD] [sssd PR#82][+Accepted] KRB5: Remove spurious warning in logs

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/82
Title: #82: KRB5: Remove spurious warning in logs

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#81][synchronized] Please see the commit message, the fix is hopefully simple

[jhrozek]

   URL: https://github.com/SSSD/sssd/pull/81
Author: jhrozek
 Title: #81: Please see the commit message, the fix is hopefully simple
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/81/head:pr81
git checkout pr81
From 5fb6104297aa2d2ced51e377bff52136eea13e2a Mon Sep 17 00:00:00 2001
From: Jakub Hrozek 
Date: Fri, 18 Nov 2016 12:19:02 +0100
Subject: [PATCH] BUILD: Fix a typo in inotify.m4

This typo prevented HAVE_INOTIFY from ever being set and as an effect,
prevented /etc/resolv.conf inotify detection from working
---
 src/external/inotify.m4 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/external/inotify.m4 b/src/external/inotify.m4
index 9572f6d..25259a8 100644
--- a/src/external/inotify.m4
+++ b/src/external/inotify.m4
@@ -6,8 +6,8 @@ AC_DEFUN([AM_CHECK_INOTIFY],
 AC_MSG_CHECKING([whether sys/inotify.h actually works])
 AC_LINK_IFELSE(
 [AC_LANG_SOURCE([
-#ifdef HAVE_SYS_INOTITY_H
-#include ,
+#ifdef HAVE_SYS_INOTIFY_H
+#include 
 #endif
 int main () {
 return (-1 == inotify_init());
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#81][+Accepted] Please see the commit message, the fix is hopefully simple

[fidencio]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

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#80][+Accepted] SYSDB: Fixing of sudorule without a sudoUser

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/80
Title: #80: SYSDB: Fixing of sudorule without a sudoUser

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#80][comment] SYSDB: Fixing of sudorule without a sudoUser

[jhrozek]

  URL: https://github.com/SSSD/sssd/pull/80
Title: #80: SYSDB: Fixing of sudorule without a sudoUser

jhrozek commented:
"""
ACK, the rule without a sudoUser attribute is properly skipped and the other 
rules are normally stored.
"""

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

[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)

[jhrozek]

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

jhrozek commented:
"""
ACK, this version works for me. I will run also downstream tests to be sure, 
but my manual testing passed.
"""

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

[SSSD] [sssd PR#82][+Pushed] KRB5: Remove spurious warning in logs

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/82
Title: #82: KRB5: Remove spurious warning in logs

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#82][closed] KRB5: Remove spurious warning in logs

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/82
Author: lslebodn
 Title: #82: KRB5: Remove spurious warning in logs
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/82/head:pr82
git checkout pr82
___
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 - SSSD KCM server

[Jakub Hrozek]

On Tue, Nov 22, 2016 at 09:23:22AM -0500, Stephen Gallagher wrote:
> Some thoughts inline:
> 
> On 11/22/2016 02:51 AM, Jakub Hrozek wrote:
> 
> ...
> 
> > === Implementation details ===
> > A new SSSD responder will be added. Since accessing the Kerberos credentials
> > is quite an infrequent operation, the responder will be socket-activated.
> > 
> > This responder would implement the same subset of the KCM protocol the MIT
> > client libraries implement. Contrary to Heimdal's KCM server that just
> > stores the credential caches in memory, the SSSD KCM server would store
> > the ccaches in the secrets database through the sssd-secret's responder
> > [https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-secrets.5.html 
> > public REST API].
> > 
> > For user credentials the KCM Server would use a secrets responder URI
> > like `/kcm/users/1234/X` where 1234 is the user ID and X is the residual.
> > The client then gets assigned a KRB5CCNAME of KCM:1234:X. Internally in the
> > secrets responder we will store the credential caches under a new base DN
> > `cn=kcm`.
> > 
> > The secret responder's quota on secrets must be made modular to allow
> > different number of secrets per base DN (so, different number of secrets
> > and credentials pretty much). What to do in case the quota is reached is
> > debatable - we should probably first remove service (non-TGT) tickets first
> > for valid TGTs and if that's not possible, just fail. A failure in this
> > case would be no different than a failure if a disk is full when trying
> > to store a FILE-based ccache.
> > 
> > The KCM responder would renew the user credentials by starting a tevent
> > timer which would then contact the SSSD Data Provider for the given UID
> > and principal, asking for the credentials to be renewed. Another tevent
> > timer would reap and remove a ccache that reaches its lifetime.
> > 
> 
> 
> OK, so the service is only semi-socket-activated? If we're keeping tevent 
> timers
> around for renewals and reaping, the service won't be exiting unless all 
> tickets
> have expired and been reaped.
> 
> Would it be possible to look into setting non-persistent systemd timer units
> instead that would "wake up" the sssd_kcm service at appropriate times to do
> renewal and expiration?
> 
> systemd provides the CreateTransientUnit() method on its public API that we
> could use for this purpose. If we did it this way, then the service would only
> need to be activated whenever a ticket was actually being retrieved from the
> collection.

All good points, I 'just' need to look into these systemd timers.

> 
> 
> > In the future, SSSD-specific operations such as writing out a FILE-based
> > ccache might be added. The SSSD D-Bus interface would also be extended to
> > publish information about credentials activity (such as - a ticket being
> > acquired, a ticket was renewed etc)
> 
> 
> This should be a high priority, since it will benefit tools such as GNOME 
> Online
> Accounts greatly (right now, they have to poll the kernel keyring and are not
> happy about it; with FILE and DIR caches, they at least could get 
> notifications
> via inotify)

OK, noted.

> 
> 
> > 
> > === Configuration changes ===
> > No KCM-specific configuration options will be added. The SSSD KCM responder
> > would use the same common options like other SSSD services such as idle
> > timeout.
> > 
> > We can add a configurable KCM socket location later, if needed, but for
> > the start it's fine to default to `/var/run/.heim_org.h5l.kcm-socket`
> > mostly because that's what MIT defaults to as well.
> > 
> > '''Q''': Should we add an option to explicitly enable ccache renewals and
> > default to no renewals? I don't think this would any any security though,
> > the attacker can just run 'kinit -R' on behalf of the user anyway.
> > 
> 
> If the user asked for a renewable ticket in the first place (and the server
> permitted it), then I don't see any reason not to just go ahead and renew it 
> by
> default.
> 
> 
> > === How To Test ===
> > In order for the admin to start using the KCM service, the sssd-kcm
> > responder's systemd service must be enabled. Then, libkrb5 must also be
> > configured to use KCM as its default ccache type in `/etc/krb5.conf`
> > {{{
> > [libdefaults]
> > default_ccache_name = KCM
> > }}}
> > 
> > After that, all common operations like kinit, kdestroy or login through
> > pam_sss should just work and store their credentials in the KCM server.
> > 
> > The KCM server must implement access control correctly, so even
> > trying to access other user's KCM credentials by setting KRB5CCNAME to
> > `KCM:1234:RESIDUAL` would not work (except for root).
> > 
> > Restarting the KCM server or rebooting the machine must persist the tickets.
> > 
> > As far as automatic unit and integration testing is required, we need to 
> > make
> > sure that MIT's testsuite passes with Kerberos ccache defaulting to KCM
> > and SSSD KCM deamon running. In the SSSD 

[SSSD] Re: Design document - SSSD KCM server

[Simo Sorce]

On Tue, 2016-11-22 at 09:23 -0500, Stephen Gallagher wrote:
> Some thoughts inline:
> 
> On 11/22/2016 02:51 AM, Jakub Hrozek wrote:
> 
> ...
> 
> > === Implementation details ===
> > A new SSSD responder will be added. Since accessing the Kerberos credentials
> > is quite an infrequent operation, the responder will be socket-activated.
> > 
> > This responder would implement the same subset of the KCM protocol the MIT
> > client libraries implement. Contrary to Heimdal's KCM server that just
> > stores the credential caches in memory, the SSSD KCM server would store
> > the ccaches in the secrets database through the sssd-secret's responder
> > [https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-secrets.5.html 
> > public REST API].
> > 
> > For user credentials the KCM Server would use a secrets responder URI
> > like `/kcm/users/1234/X` where 1234 is the user ID and X is the residual.
> > The client then gets assigned a KRB5CCNAME of KCM:1234:X. Internally in the
> > secrets responder we will store the credential caches under a new base DN
> > `cn=kcm`.
> > 
> > The secret responder's quota on secrets must be made modular to allow
> > different number of secrets per base DN (so, different number of secrets
> > and credentials pretty much). What to do in case the quota is reached is
> > debatable - we should probably first remove service (non-TGT) tickets first
> > for valid TGTs and if that's not possible, just fail. A failure in this
> > case would be no different than a failure if a disk is full when trying
> > to store a FILE-based ccache.
> > 
> > The KCM responder would renew the user credentials by starting a tevent
> > timer which would then contact the SSSD Data Provider for the given UID
> > and principal, asking for the credentials to be renewed. Another tevent
> > timer would reap and remove a ccache that reaches its lifetime.
> > 
> 
> 
> OK, so the service is only semi-socket-activated? If we're keeping tevent 
> timers
> around for renewals and reaping, the service won't be exiting unless all 
> tickets
> have expired and been reaped.
> 
> Would it be possible to look into setting non-persistent systemd timer units
> instead that would "wake up" the sssd_kcm service at appropriate times to do
> renewal and expiration?
> 
> systemd provides the CreateTransientUnit() method on its public API that we
> could use for this purpose. If we did it this way, then the service would only
> need to be activated whenever a ticket was actually being retrieved from the
> collection.

I am trying to think if this would gain us anything.
What would you use as a reasonable timeout to decide to exit ?
There are other events we may want to detect in future. for example we
may want to decide to destroy all of a user ccaches if all his sessions
go away, this requires active probing though, but I guess it could also
be a timer or maybe systemd has a way to notify and start a process when
this happens too ?

> > In the future, SSSD-specific operations such as writing out a FILE-based
> > ccache might be added. The SSSD D-Bus interface would also be extended to
> > publish information about credentials activity (such as - a ticket being
> > acquired, a ticket was renewed etc)
> 
> 
> This should be a high priority, since it will benefit tools such as GNOME 
> Online
> Accounts greatly (right now, they have to poll the kernel keyring and are not
> happy about it; with FILE and DIR caches, they at least could get 
> notifications
> via inotify)

That's the main target, but they will still need to keep the old code
for now, until we make sssd-kcm mandatory for gnome sessions.

> > 
> > === Configuration changes ===
> > No KCM-specific configuration options will be added. The SSSD KCM responder
> > would use the same common options like other SSSD services such as idle
> > timeout.
> > 
> > We can add a configurable KCM socket location later, if needed, but for
> > the start it's fine to default to `/var/run/.heim_org.h5l.kcm-socket`
> > mostly because that's what MIT defaults to as well.
> > 
> > '''Q''': Should we add an option to explicitly enable ccache renewals and
> > default to no renewals? I don't think this would any any security though,
> > the attacker can just run 'kinit -R' on behalf of the user anyway.
> > 
> 
> If the user asked for a renewable ticket in the first place (and the server
> permitted it), then I don't see any reason not to just go ahead and renew it 
> by
> default.

You might be surprised at what regulations may require in this area, but
I tend to agree that it is ok as a default.

> > === How To Test ===
> > In order for the admin to start using the KCM service, the sssd-kcm
> > responder's systemd service must be enabled. Then, libkrb5 must also be
> > configured to use KCM as its default ccache type in `/etc/krb5.conf`
> > {{{
> > [libdefaults]
> > default_ccache_name = KCM
> > }}}
> > 
> > After that, all common operations like kinit, kdestroy or login through
> > pam_sss 

[SSSD] [sssd PR#81][closed] Please see the commit message, the fix is hopefully simple

[lslebodn]

   URL: https://github.com/SSSD/sssd/pull/81
Author: jhrozek
 Title: #81: Please see the commit message, the fix is hopefully simple
Action: closed

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

[SSSD] [sssd PR#81][+Pushed] Please see the commit message, the fix is hopefully simple

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

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#82][comment] KRB5: Remove spurious warning in logs

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/82
Title: #82: KRB5: Remove spurious warning in logs

lslebodn commented:
"""
* a7f085d6a04d4ecf9ebc29b57c868ad41b744dff
"""

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

[Stephen Gallagher]

On 11/22/2016 09:38 AM, Simo Sorce wrote:
> On Tue, 2016-11-22 at 09:23 -0500, Stephen Gallagher wrote:

>> OK, so the service is only semi-socket-activated? If we're keeping tevent 
>> timers
>> around for renewals and reaping, the service won't be exiting unless all 
>> tickets
>> have expired and been reaped.
>>
>> Would it be possible to look into setting non-persistent systemd timer units
>> instead that would "wake up" the sssd_kcm service at appropriate times to do
>> renewal and expiration?
>>
>> systemd provides the CreateTransientUnit() method on its public API that we
>> could use for this purpose. If we did it this way, then the service would 
>> only
>> need to be activated whenever a ticket was actually being retrieved from the
>> collection.
> 
> I am trying to think if this would gain us anything.
> What would you use as a reasonable timeout to decide to exit ?
> There are other events we may want to detect in future. for example we
> may want to decide to destroy all of a user ccaches if all his sessions
> go away, this requires active probing though, but I guess it could also
> be a timer or maybe systemd has a way to notify and start a process when
> this happens too ?
> 

Well, as far as a timeout to exit, I'd probably go with a minute or two (since
you may have a short flurry of activity, such as when a user first connects to a
VPN).

As far as notification of a user signing in or out, we *could* attach a helper
unit to the systemd user session default.target (and have an ExecStop command
for handling when it gets shut down too).

>> How do containers access the KCM? Would they have to run their own copy 
>> internal
>> to the container? Would we bind-mount the /var/run/.heim_org.h5l.kcm-socket 
>> and
>> then work some namespacing magic in the host?
> 
> Deployment specific, I can see either way as an option depending on what
> you are doing.
> 

OK, but the document doesn't describe how that might be done. We should identify
the set of supported approaches up-front and include them in the design.


>> You call out in the introduction that this will help address container
>> use-cases, but then don't describe that implementation. This seems like an
>> important piece of the puzzle that should be added to the page (or made more
>> clear, since if it's in there, I can't spot it).
> 
> What would you want to call out exactly ?
> 

Describe a couple use-cases and the expected user experience for setting them up
and using them. If we bind-mount the host's KCM into the container, would the
user namespacing be handled "magically" by the kernel or do we need to keep
track of which cgroup our client is and sort it into its own section of the
database? (Just for example).




signature.asc
Description: OpenPGP digital signature
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org

[SSSD] [sssd PR#81][comment] Please see the commit message, the fix is hopefully simple

[lslebodn]

  URL: https://github.com/SSSD/sssd/pull/81
Title: #81: Please see the commit message, the fix is hopefully simple

lslebodn commented:
"""
master:
* 2927dc45b9bc810f4f55bce165bb96405129e693

sssd-1-14:
* 495289cfa922b00278aa91d433489403e792304e

sssd-1-13:
* 331a7c3d60a4dadd43565f339095daef5de5e7bf

"""

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