[SSSD] [PATCH] MAN: Clarify the ldap_access_filter option further

Jakub Hrozek jhrozek at redhat.com
Wed Feb 26 16:30:55 UTC 2014


On Wed, Feb 26, 2014 at 05:22:51PM +0100, Jakub Hrozek wrote:
> On Wed, Feb 26, 2014 at 11:14:33AM -0500, Stephen Gallagher wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 02/26/2014 10:08 AM, Jakub Hrozek wrote:
> > > On Mon, Feb 24, 2014 at 07:47:08PM +0100, Jakub Hrozek wrote:
> > >> The attached patch addresses: 
> > >> https://fedorahosted.org/sssd/ticket/2235
> > >> 
> > >> The memberof example was misleading and was making aministrators
> > >> think that the ldap_access_filter can resolve nested group
> > >> memberships.
> > >> 
> > >> The alternative I was considering was changing the example to use
> > >> a different attribute altogether, but I was struggling to come up
> > >> with an example that wouldn't be too artificial (like 
> > >> ldap_access_filter=/bin/bash).
> > > 
> > > Stephen's review seems to be stuck in mailman queue, so I'm sending
> > > a patch that contains his suggestion as a reply to myself.
> > > 
> > > The employeeType attribute Stephen suggested is a good choice, I
> > > think.
> > > 
> > 
> > If we're changing the cited example, I'm not sure we need to call out
> > the memberOf example anymore.
> 
> Hmm, initially I wanted to keep it in, because memberOf is what I see
> used mostly in the field but you're right that when I don't think about
> the context of the change and just read the man page text, it is
> confusing to start talking about memberOf.
> 
> Another iteration of the patch is attached.

Yet another version that retains a part of the paragraph (.."applied on
the LDAP entry only..") and changes description of the example.
-------------- next part --------------
>From e164ed61b32907e06795103d899bc52188450ff8 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek <jhrozek at redhat.com>
Date: Tue, 25 Feb 2014 17:09:00 +0100
Subject: [PATCH] MAN: Clarify that changing ID mapping options might require
 purging the cache

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

Currently SSSD chokes when IDs of users change, we don't support ID
changes yet. Because some users were confused about the failures, this
patch adds additional clarification.
---
 src/man/include/ldap_id_mapping.xml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/src/man/include/ldap_id_mapping.xml b/src/man/include/ldap_id_mapping.xml
index 9dda399243bfd1725509c239d3358f2ef7501014..a10dcd52a1687c4d97211ebdabc77095bbfccf5a 100644
--- a/src/man/include/ldap_id_mapping.xml
+++ b/src/man/include/ldap_id_mapping.xml
@@ -12,6 +12,17 @@
         need to use manually-assigned values, ALL values must be
         manually-assigned.
     </para>
+    <para>
+        Please note that changing the ID mapping related configuration
+        options will cause user and group IDs to change. At the moment,
+        SSSD does not support changing IDs, so the SSSD database must be
+        removed. Because cached passwords are also stored in the database,
+        removing the database should only be performed while the SSSD
+        is online, otherwise users might get locked out. Moreover, the
+        change of IDs might neccessitate to adjust other system properties
+        such as file and directory ownership, so it's advisable to plan
+        ahead and test the ID mapping configuration thoroughly.
+    </para>
 
     <refsect2 id='idmap_algorithm'>
         <title>Mapping Algorithm</title>
-- 
1.8.5.3



More information about the sssd-devel mailing list