Re: [SSSD] SSSD Crypto Support
Hi, Am Mittwoch 14 März 2012, 08:59:33 schrieb Stephen Gallagher: SSSD is designed to have support for multiple cryptography libraries. Originally we build in support for both Mozilla NSS and libcrypto. However, over the last several releases, libcrypto support has fallen by the wayside and there is now a notable feature disparity between versions of SSSD built against Mozilla NSS and versions built against libcrypto. The basic functionality still works (we have support for caching credentials using a SHA512 algorithm provided by either library), but some of the more advanced features do not. For example: 1. Support for obfuscated passwords in the sssd.conf requires Mozilla NSS(*) 2. Support for centrally-managed SSH public keys requires a BASE64 encode/decode routine and in 1.8.2 wil add a SHA1 hash routine. There is no equivalent available in libcrypto at this time. Going forward, the core upstream for SSSD (all of whom run on Fedora and RHEL systems which have been consolidated on Mozilla NSS for some time) is planning to formally drop support for libcrypto. However, we're certainly willing to continue supporting it if someone else is willing to own the maintenance on it. Thus, I am CCing the maintainers of SSSD in non-Fedora/RHEL distributions that I know of. If anyone here is relying on libcrypto support and is willing to take over its maintenance, please speak up. As much as I like to have libcrypto support staying in sssd, I currently don't have any time left to work on this. So unless somebody else steps up I guess I'll just have to live with that decision. (*) I consider this a misfeature imposed upon us by incompetent auditors, but it's still a checkbox on someone's list. :) Agreed. regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Request password control unconditionally during bind
Hi, On Montag 01 August 2011 18:19:50 Stephen Gallagher wrote: On Mon, 2011-08-01 at 10:49 -0400, Stephen Gallagher wrote: On Mon, 2011-08-01 at 15:49 +0200, Jakub Hrozek wrote: https://fedorahosted.org/sssd/ticket/940 Ack Pushed to master and sssd-1-5. BTW, this also fixes https://fedorahosted.org/sssd/ticket/899 I guess. Having options to enable/disable certain controls might still be valueable though. regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] supportedControl and OpenLDAP
Hi, On Dienstag 12 Juli 2011 20:24:21 Stephen Gallagher wrote: On Tue, 2011-07-12 at 17:24 +0200, Ralf Haferkamp wrote: reason not to use it. (e.g. I don't see a good reason for using paged results with OpenLDAP by default). Ralf, could you elaborate on this specifically? I can't really come up with a situation where it's harmful to use paged results if they're available. It's not harmful (other than that it might need a few more resource on the server side). But it doesn't gain you anything when using OpenLDAP on the server side. If the results don't exceed the page size (1000 records by default), then the operation is basically identical to an unpaged search. And if it DOES exceed the page size, not having paging support would end up with incomplete (and therefore untrusted) results. OpenLDAP doesn't apply any different limits for searches using paged results. So if the server is configured to only return 1000 result for a normal search you will also only get 1000 entries at max for a paged search (i.e. with a pagesize of 1000 you will only get one page and then a SIZE_LIMIT_EXCEEDED error). Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] supportedControl and OpenLDAP
Hi, On Donnerstag 16 Juni 2011 14:09:43 Simo Sorce wrote: On Thu, 2011-06-16 at 11:32 +0200, Sumit Bose wrote: Hi, by chance I realized that an OpenLDAP server does not list all controls it can handle in the rootDSE attribute supportedControl. Especially LDAP_CONTROL_PASSWORDPOLICY is not listed. According to the OpenLDAP developers this is because the related spec (http://tools.ietf.org/html/draft-behera-ldap-password-policy-10) is still a draft and not finalized (http://www.openldap.org/lists/openldap-software/200606/msg00220.htm l). Since sssd only uses controls which are in the supportedControl list we will not be able to give the user expiration warnings or information about grace logins for OpenLDAP servers with the password policy overlay enabled. I'm not sure if we need to do anything about it but at least I think it is good to be aware of. Maybe we can have an override option where we list the OIDs we know are supported even though they are not listed in rootDSE. IT may be useful for testing and other purposes too. Even though a list of OIDs might work, I find it somewhat inconvient to use. I'd prefer a separate config keyword for every control one wants to enable/disable. If I grep'ed the sources correctly sssd currently supports three different LDAP controls (deref, paged results and password policy) so adding config keywords for each those does seem to be too much of a problem. BTW, there is another problem with using the information from the rootDSE. If the server (like OpenLDAP and AFAIK 389DS as well) supports multiple backend databases, the supported controls might differ between the configured database. The rootDSE does not give any information about which database support which controls (and extensions). Additionally, even if a specific control is returned in the rootDSE there might be good reason not to use it. (e.g. I don't see a good reason for using paged results with OpenLDAP by default). regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [RFC][PATCH] Add new getgrgid2(), getgrnam2() interfaces to glibc
Am Dienstag 19 Oktober 2010, 14:04:06 schrieb Stephen Gallagher: On 10/18/2010 07:42 PM, Petr Baudis wrote: This RFC patch adds support for new interfaces: getgrgid2(), getgrnam2() and their *_r() variants. These interfaces allow the user to specify whether the group.gr_mem field shall be filled in. The issue we are trying to solve is that needlessly high load is generated in large deployments with NIS/LDAP user groups with possibly thousands of members. Even when nscd is used, the information is requested and transferred frequently even when there never arises any real use for the huge lists of members at the node at all. We have looked at some commonly used applications and e.g. for a normal desktop, if some basic utilities and file managers would be trivially modified to use the new interface, the full lists of users in a group would never have to be downloaded. Right now, even ls will trigger getting full lists of users in all groups it encounters. Moreover, e.g. the sssd guys are reportedly trying to solve this problem by evil hacks like randomly not filling or only partially filling the gr_mem field. Actually, your information is a little bit incorrect. We recently discovered that we had a few bugs in SSSD that were causing us to only present a subset of the gr_mem field. This was entirely incorrect, and as of SSSD 1.2.4 and 1.4.0 we have rectified this problem. From the recent discussion on sssd-devel it seemed to have been done as an optimization initially. But in the end that doesn't really matter. The way we do things in SSSD is, however, designed to significantly reduce the load on LDAP servers. When we perform a group lookup with getgrnam() or getgrgid(), we request ONLY this group from the LDAP server. What we then do on our client-side is to create in our cache mechanism a series of fake users in our data store. These users will be reported back to getgrnam(), but they are not separately looked up and populated with their complete user information unless they are directly requested by a getpwnam() or getpwid() request. This is not correct. See below. The net result is that we will report all of the users that belong in a group, but we will not make additional requests to populate those users unless they are directly requested. Yes, for groups that have many thousands of users, we may make a single request that transfers a couple hundred kilobytes, but we do not make subsequent requests for each of those users in turn. RFC2307bis servers require slightly more processing, as we need to make multiple requests to LDAP if there are nested groups in play. But we never make more requests than the configured nesting limit. I think your are mixing things up a bit. For RFC2307bis, even if nested groups are not used (IIRC nested groups were never really part of RFC2307bis), sssd still needs to make an LDAP lookup for every single member to correctly populate the gr_mem attribute of the struct group, you can't create any fake entries in the sssd cache for that (the fake user approach only works with plain old RFC2307 groups). Any comments on the API are welcome, including thoughts on how to make it more elegant. Originally, I wanted to implement it as gid_t getgidbyname(const char *name) etc., but I would have to redo some parts of the NSS infrastructure to easily allow returning gid_t instead of a struct. If there is a consensus that this is a good idea and Ulrich gives his blessing, I will of course extend the patch to be compatible with older NSS modules and add NIS support and nscd support. I'm really not sure what the value of this approach is. Realistically, you're talking about creating an interface whose sole purpose is to map GID-groupname and nothing else? Yes. I'm not sure there's sufficient value in this approach, given that it's possible as described above to limit the network requests. I think it makes much more sense to guide the respective name-service providers along the path of handling these requests more efficiently. That's the problem, for e.g. RFC2307bis this can't be done more efficiently in a reliable manner (see the recent discussion around getgrgid/getgrnam() on the sssd-devel list). So as most callers of getgrnam/getgrgid don't use the member information anyways I think such gid-groupname mapping function could be quite useful. I'm expanding this mailing to include the sssd-devel list for broader discussion. -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Friday 01 October 2010 15:22:09 Ralf Haferkamp wrote: Hi, find yet another release of the patches attached. It adresses the remaining issues we discussed in IRC: - included the Simo's style fixes and rearrangements to better match the overall sssd code style - Errors detected in sdap_process_group_members() are not considered fatal (apart from ENOMEM conditions, where it doesn't seem to make a lot of sense to continue). We just log an error message an skip to the next member. This could be improved a bit by stopping to send new LDAP request when sdap_get_generic_recv() error code e.g. indicates that the LDAP connection is permanently broken. What error code would that be, EIO? But this should probably better addressed together with #633. Any news on this? Is the patch now acceptable? regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Monday 11 October 2010 10:30:01 Jakub Hrozek wrote:
[..]
Hi Ralf,
I'm sorry for the delay but we have been swamped releasing the 1.2.4
version. We will get back to fixing the issues in the master branch
this week.
As per your patches, I based quite some of my 1.2 patch and all of my
RFC2307 work in master on them, so I know they work fine.
They were two additional minor comments during the review of the 1.2
patch -
https://fedorahosted.org/pipermail/sssd-devel/2010-October/004773.html
The first (changing the bool parameter) one was later withdrawn as it
is quite invasive change esp. for the 1.2 branch, but the latter
(memory contexts) might be something we should fix in master, too.
Ok. The attached patches have the memctx issues addressed (similar to
what you did in the 1.2 branch).
regards,
Ralf
From ed1add9caab21680bc035758437a5db595af1f93 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 11 Oct 2010 17:13:58 +0200
Subject: [PATCH 1/2] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter populate_members for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 95f3b0d..b71e6d5 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool populate_members,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (populate_members) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el);
if (ret != EOK) {
@@ -808,6 +821,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
struct sdap_options *opts,
struct sysdb_attrs **groups,
int num_groups,
+bool populate_members,
char **_timestamp)
{
TALLOC_CTX *tmpctx;
@@ -848,7 +862,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
/* if 2 pass savemembers = false */
ret = sdap_save_group(tmpctx, sysdb,
opts, dom, groups[i],
- (!twopass), timestamp);
+ (!twopass), populate_members, timestamp);
/* Do not fail completely on errors.
* Just report the failure to save and go on */
@@ -872,7 +886,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
}
}
-if (twopass) {
+if (twopass !populate_members) {
for (i = 0; i num_groups; i++) {
@@ -988,6 +1002,7 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
ret = sdap_save_groups(state, state-sysdb,
state-dom, state-opts,
state-groups, state-count,
+ false,
state-higher_timestamp);
if (ret) {
DEBUG(2, (Failed to store groups.\n));
@@ -1355,7 +1370,7 @@ static void sdap_initgr_nested_store(struct tevent_req *req)
state = tevent_req_data(req, struct sdap_initgr_nested_state);
ret = sdap_save_groups(state, state-sysdb, state-dom, state-opts,
- state-groups, state-groups_cur, NULL);
+ state-groups, state-groups_cur, false, NULL);
if (ret) {
tevent_req_error(req, ret);
return;
--
1.7.1
From 46323c327b9a462980eb9dacdf3b06c716eb87ea Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 11 Oct 2010 17:13:58 +0200
Subject: [PATCH 2/2] Return all group members from getgr(nam|gid)
getgrnam()/getgrgid() should return all group members instead of only those
which have already been cached (in sysdb). To achieve this every member
that is currently not in the cache is looked up via LDAP and saved to the
cache.
---
src/providers/ldap
Re: [SSSD] Behaviour of getgrnam/getgrgid
Hi,
find yet another release of the patches attached. It adresses the
remaining issues we discussed in IRC:
- included the Simo's style fixes and rearrangements to better match the
overall sssd code style
- Errors detected in sdap_process_group_members() are not considered
fatal (apart from ENOMEM conditions, where it doesn't seem to make a
lot of sense to continue).
We just log an error message an skip to the next member. This could be
improved a bit by stopping to send new LDAP request when
sdap_get_generic_recv() error code e.g. indicates that the LDAP
connection is permanently broken. What error code would that be, EIO?
But this should probably better addressed together with #633.
--
regards,
Ralf
From 2494425b1faf7b83266b844e5c82c696256c33de Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 1 Oct 2010 14:48:16 +0200
Subject: [PATCH 1/2] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter populate_members for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 95f3b0d..b71e6d5 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool populate_members,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (populate_members) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el);
if (ret != EOK) {
@@ -808,6 +821,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
struct sdap_options *opts,
struct sysdb_attrs **groups,
int num_groups,
+bool populate_members,
char **_timestamp)
{
TALLOC_CTX *tmpctx;
@@ -848,7 +862,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
/* if 2 pass savemembers = false */
ret = sdap_save_group(tmpctx, sysdb,
opts, dom, groups[i],
- (!twopass), timestamp);
+ (!twopass), populate_members, timestamp);
/* Do not fail completely on errors.
* Just report the failure to save and go on */
@@ -872,7 +886,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
}
}
-if (twopass) {
+if (twopass !populate_members) {
for (i = 0; i num_groups; i++) {
@@ -988,6 +1002,7 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
ret = sdap_save_groups(state, state-sysdb,
state-dom, state-opts,
state-groups, state-count,
+ false,
state-higher_timestamp);
if (ret) {
DEBUG(2, (Failed to store groups.\n));
@@ -1355,7 +1370,7 @@ static void sdap_initgr_nested_store(struct tevent_req *req)
state = tevent_req_data(req, struct sdap_initgr_nested_state);
ret = sdap_save_groups(state, state-sysdb, state-dom, state-opts,
- state-groups, state-groups_cur, NULL);
+ state-groups, state-groups_cur, false, NULL);
if (ret) {
tevent_req_error(req, ret);
return;
--
1.7.1
From 7e66e857f35783a8ff57954a076dd64d70a3bf55 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 1 Oct 2010 14:48:16 +0200
Subject: [PATCH 2/2] Return all group members from getgr(nam|gid)
getgrnam()/getgrgid() should return all group members instead of only those
which have already been cached (in sysdb). To achieve this every member
that is currently not in the cache is looked up via LDAP and saved to the
cache.
---
src/providers/ldap/sdap_async_accounts.c | 386 +-
1 files changed, 374 insertions(+), 12
Re: [SSSD] Behaviour of getgrnam/getgrgid
Am Montag 27 September 2010, 16:37:14 schrieb Simo Sorce:
On Fri, 24 Sep 2010 16:31:24 +0200
Ralf Haferkamp rha...@suse.de wrote:
Hi,
find updated patches attached. (Rebased against current master)
Am Donnerstag 23 September 2010, 20:02:20 schrieb Stephen Gallagher:
On 09/20/2010 11:13 AM, Ralf Haferkamp wrote:
[..]
Patch 0001: Ack. This looks fine to me.
Uhmm I think I see an issue in patch 1.
It looks to me that we fail the operation if we have no members in a
group as when calling sysdb_attrs_get_el() sdap_save_group() now
treats ENOENT just like a fatal error.
Hm, I am not sure what call to sysdb_attrs_get_el() you are referring
to, but if I understand the sysdb_attrs_get_el() code correctly it will
never return ENOENT.
It just calls sysdb_attrs_get_el_int with alloc=true in that case the
only error that can return is ENOMEN. Did I overlook something?
IIRC I explicitly tested the code with empty groups.
Although uncommon I think we should handle empty groups.
Of course.
Also I have a cosmetic request. It took sometimes to me to understand
what the name sysdb_member_dns meant. Would it be possible to rename
it to something like populate_members/resolve/members/fetch_members
or something similar ? It would make it easier to understand it is an
option that does something like store_members, just different.
Ok. Find updated patch attached.
--
Ralf
From bdd2b5877a0eeb0dbe0578390e4cd819776bbf2e Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 27 Sep 2010 21:33:41 +0200
Subject: [PATCH 1/2] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter populate_members for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 95f3b0d..b71e6d5 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool populate_members,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (populate_members) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el);
if (ret != EOK) {
@@ -808,6 +821,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
struct sdap_options *opts,
struct sysdb_attrs **groups,
int num_groups,
+bool populate_members,
char **_timestamp)
{
TALLOC_CTX *tmpctx;
@@ -848,7 +862,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
/* if 2 pass savemembers = false */
ret = sdap_save_group(tmpctx, sysdb,
opts, dom, groups[i],
- (!twopass), timestamp);
+ (!twopass), populate_members, timestamp);
/* Do not fail completely on errors.
* Just report the failure to save and go on */
@@ -872,7 +886,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
}
}
-if (twopass) {
+if (twopass !populate_members) {
for (i = 0; i num_groups; i++) {
@@ -988,6 +1002,7 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
ret = sdap_save_groups(state, state-sysdb,
state-dom, state-opts,
state-groups, state-count,
+ false,
state-higher_timestamp);
if (ret) {
DEBUG(2, (Failed to store groups.\n));
@@ -1355,7 +1370,7 @@ static void sdap_initgr_nested_store(struct tevent_req *req)
state = tevent_req_data(req, struct sdap_initgr_nested_state);
ret = sdap_save_groups(state, state-sysdb, state-dom, state-opts,
- state-groups, state-groups_cur, NULL);
+ state-groups
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thursday 23 September 2010 20:02:20 Stephen Gallagher wrote: On 09/20/2010 11:13 AM, Ralf Haferkamp wrote: [..] Nice, that makes the code a little cleaner, thanks. New patches attached. Patch 0001: Ack. This looks fine to me. Patch 0002: Nack. There are still a few style issues. Please move the struct sdap_process_group_state definition to right before the sdap_get_groups_process() implementation. will do I'm not a huge fan of firing off all of the sdap_process_group_state() calls in a loop for (effectively) simultaneous operation. I'd prefer if you implemented this with our _step() approach (where you handle each one serially until they're all finished). It's quite a bit easier to follow in a debugger. This will also eliminate the need for GROUPMEMBER_REQ_PARALLEL. Believe it or not, it won't be any slower because the LDAP id op operations will serialize the requests anyway so we don't open large numbers of separate connections to the LDAP server. I agree that the parallel approach is a bit more complex. But it was significantly faster in the tests I did compared to serially processing the group members. Otherwise I wouldn't have done that implementation. BTW, you can see the difference by setting GROUPMEMBER_REQ_PARALLEL to 0. The goal wasn't to have multiple LDAP connections opened (that would be insane). But sending multiple request at once to the LDAP server (through a single connection) and then starting processing the results of the requests is of course faster than sending sending a single request then processing the result of that request and then sending the next request. Simply because the LDAP server can a) process multiple requests at once and b) has a some request queued to process while the client is busy with retrieving and processing the results. The only drawback I see here is that the LDAP Server might limit the number of LDAP request it queues on a single connection therefor it would probably be good to replace GROUPMEMBER_REQ_PARALLEL with a value configurable via sssd.conf. There's a memory hierarchy bug in sdap_process_group_send(). You allocate sysdb_dn on memctx, but it really should be a child of grp_state-sysdb_dns-values[grp_state-sysdb_dns-num_values]. Ok, I'll check that. I think there's a lot of potential here. We just need to work on cleaning things up a little bit further. Patch 0003: Nack. I agree with Simo that it would make more sense to use a nesting level rather than a boolean for this task. Yeah, I fine with taking Simo's approach here. Also, any changes to the LDAP options need to be added to src/config/etc/sssd.api.d/sssd-ldap.conf and have a translatable string added to src/config/SSSDConfig.py and also have the same option mirrored in the IPA backend. This latter you will be alerted to if you attempt to run 'make check'. -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
Am Freitag 24 September 2010, 16:29:33 schrieb Jakub Hrozek: On 09/24/2010 11:27 AM, Ralf Haferkamp wrote: I agree that the parallel approach is a bit more complex. But it was significantly faster in the tests I did compared to serially processing the group members. Otherwise I wouldn't have done that implementation. BTW, you can see the difference by setting GROUPMEMBER_REQ_PARALLEL to 0. The goal wasn't to have multiple LDAP connections opened (that would be insane). But sending multiple request at once to the LDAP server (through a single connection) and then starting processing the results of the requests is of course faster than sending sending a single request then processing the result of that request and then sending the next request. Simply because the LDAP server can a) process multiple requests at once and b) has a some request queued to process while the client is busy with retrieving and processing the results. The only drawback I see here is that the LDAP Server might limit the number of LDAP request it queues on a single connection therefor it would probably be good to replace GROUPMEMBER_REQ_PARALLEL with a value configurable via sssd.conf. Hi Ralf, I think this part of your work overlaps with what I've been doing in order to fix #621 and #625. My approach was a little bit different and I'm wondering whether we could merge our patches. I've been implementing Simo's proposal so that for every user that is not cached in sysdb we add a kind of fake skeleton user - just a DN, name and marked as expired - so that getgrnam is able to return the list of users but when additional details about the user are requested via getpwnam/getpwuid, the entry is requested. Yeah, we discussed that already on the list here at the beginning of this thread, but the fake user approach will only work reliably for RFC2307 setups, where the user names of the group members are stored in the memberUid Attribute. My patch currently only addresses the RFC2307bis approach, and there you need to read the actualy LDAP objects in order to find out the username (ok there are corner cases where you can derive the user names from the DN but I think we agreed during the discussion not to do such hacks). And it then it is better to actually request the complete users objects and populate the cache with those instead of fake entries. For more details, please see Simo's breakdown here: https://fedorahosted.org/sssd/ticket/625 My proposal is to modify your patch #2 to not lookup the users in LDAP, but rather save these fake expired entries. For rfc2307bis those lookups are needed unfortunately. But for rfc2307 setups that's of course the right way to go. I have implemeted this for initgroups (adding fake group entries) and started on getgrname (or rather sdap_save_group). I have pushed patches into my fedorapeople git repository (master branch), if you'd like to take a look. Yes, I will. -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Friday 17 September 2010 19:56:15 Stephen Gallagher wrote:
On 09/17/2010 12:16 PM, Ralf Haferkamp wrote:
Find a new version attached. Does that look better? If that is not
what you were referring to lets discuss it in IRC on monday.
Note, I needed to implement sdap_process_group_send() slightly
differnent than the other _send functions in sdap_async_accounts().
Instead of returning as tevent_req* it does return a error code.
The tevent_req* is returned via the argument list. I did this
because there are cases where sdap_process_group_send() does not
need to create a new tevent_req*, e.g. when the groups doesn't have
any members or when all groupmembers are already cached.
In situations like this, the correct behavior is still to return the
request, but inside the _send() function call:
tevent_req_done(req);
tevent_req_post(req, ev);
return req;
This way it will just call the finish handler immediately after the
parent function returns. Then you don't need to have separate
codepaths for functions that do or do not have to make subrequests.
Nice, that makes the code a little cleaner, thanks. New patches attached.
--
Ralf
From 8557d18865674ee5e95f36bde97e28f617458530 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 20 Sep 2010 16:57:38 +0200
Subject: [PATCH 1/3] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter sysdb_member_dns for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 8999ba0..d1c6378 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool sysdb_member_dns,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (sysdb_member_dns) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el);
if (ret != EOK) {
@@ -808,6 +821,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
struct sdap_options *opts,
struct sysdb_attrs **groups,
int num_groups,
+bool sysdb_member_dns,
char **_timestamp)
{
TALLOC_CTX *tmpctx;
@@ -848,7 +862,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
/* if 2 pass savemembers = false */
ret = sdap_save_group(tmpctx, sysdb,
opts, dom, groups[i],
- (!twopass), timestamp);
+ (!twopass), sysdb_member_dns, timestamp);
/* Do not fail completely on errors.
* Just report the failure to save and go on */
@@ -872,7 +886,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
}
}
-if (twopass) {
+if (twopass !sysdb_member_dns) {
for (i = 0; i num_groups; i++) {
@@ -988,6 +1002,7 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
ret = sdap_save_groups(state, state-sysdb,
state-dom, state-opts,
state-groups, state-count,
+ false,
state-higher_timestamp);
if (ret) {
DEBUG(2, (Failed to store groups.\n));
@@ -1354,7 +1369,7 @@ static void sdap_initgr_nested_store(struct tevent_req *req)
state = tevent_req_data(req, struct sdap_initgr_nested_state);
ret = sdap_save_groups(state, state-sysdb, state-dom, state-opts,
- state-groups, state-groups_cur, NULL);
+ state-groups, state-groups_cur, false, NULL);
if (ret) {
tevent_req_error(req, ret);
return;
--
1.7.1
From 1ee8533ca66e9e4e39e8f53ba4cd94b7be8a2b8b Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 20 Sep
Re: [SSSD] Behaviour of getgrnam/getgrgid
Hi,
On Thursday 16 September 2010 20:16:56 Simo Sorce wrote:
On Thu, 16 Sep 2010 17:50:28 +0200
Ralf Haferkamp rha...@suse.de wrote:
Hi,
On Thursday 09 September 2010 15:14:10 Ralf Haferkamp wrote:
[..]
Find a newer version of my patch attached. Actually it's 3 patches
now. Please review.
Patch1: This just adds a new flag to save_groups() to indicate that
the group's member attribute is already populated with the members'
sysdb DN (instead on LDAP DNs). As I need to lookup the group
members in sysdb anyway, when processing the group, this saves some
redundant
sysdb lookups when storing the group.
This looks like a good idea.
Patch2: This is a somewhat improved version of my last patch.
- better error handling
- limit the number of LDAP requests that are issued before
[..]
This patch makes the main function very complex, I suggest that you at
least create separate functions for each new tevent request you want
to create, that is sort of a rule for sssd. (And it makes code
digestible more often than not).
Find a new version attached. Does that look better? If that is not what
you were referring to lets discuss it in IRC on monday.
Note, I needed to implement sdap_process_group_send() slightly differnent
than the other _send functions in sdap_async_accounts(). Instead of
returning as tevent_req* it does return a error code. The tevent_req* is
returned via the argument list. I did this because there are cases where
sdap_process_group_send() does not need to create a new tevent_req*, e.g.
when the groups doesn't have any members or when all groupmembers are
already cached.
As for group unrolling I have also started working on it (ticket
#625), although I am doing that in the 1.2.x branch as we need the
functionality there too. I will try to post a patch soon so that we
can compare relative approaches and merge the effort, ok ?
Fine. Feel free to take what you need from my patch.
Patch3: This adds a new config option to ldap_unroll_group_members
to enable/disable group unrolling
Can we use the followin patch instead ?
http://fedorapeople.org/gitweb?p=simo/public_git/sssd.git;a=commitdiff
;h=fedf324be284de71e5dbf22f0135e9f681a15bde
This patch assumes the code will consider a nesting level of 0 as no
nesting. therefore it will embed in a single option both a way to
enable disable unrolling and a limit on the level of nesting we will
allow on the client (to avoid loops or very long delay on pathological
cases).
Hm, just to make sure I understand your approach:
ldap_group_nesting_level = 0 would be equal to
ldap_unroll_group_members = false - resulting in the current getgrnam
behavior of only returning cached members.
ldap_group_nesting_level = 1 would mean ldap_unroll_group_members =
true - return only direct members of the group and ignore mested
groups.
while ldap_group_nesting_level 1 allow nesting up to a certain depth.
If that is correct what does ldap_group_nesting_level = 0 mean for the
initgroups() call? Return only groups that are already cached? I wonder
if that would be a good idea.
--
Ralf
From 651a5c060c78aff8f7e5d3423d80a5471561c8ed Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Thu, 16 Sep 2010 17:24:17 +0200
Subject: [PATCH 1/3] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter sysdb_member_dns for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 8999ba0..d1c6378 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool sysdb_member_dns,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (sysdb_member_dns) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el
Re: [SSSD] Behaviour of getgrnam/getgrgid
Hi,
On Thursday 09 September 2010 15:14:10 Ralf Haferkamp wrote:
[..]
I have started working on a patch to let sssd look up the non-cached
users via LDAP (and save them into the cache). Find it attached. Note:
That patch is not really complete (e.g. it doesn't handle rfc2307
groups correctly). But before putting more effort into this I like to
make sure that I am not trying to fix a feature here.
Find a newer version of my patch attached. Actually it's 3 patches now.
Please review.
Patch1: This just adds a new flag to save_groups() to indicate that the
group's member attribute is already populated with the members' sysdb
DN (instead on LDAP DNs). As I need to lookup the group members in
sysdb anyway, when processing the group, this saves some redundant
sysdb lookups when storing the group.
Patch2: This is a somewhat improved version of my last patch.
- better error handling
- limit the number of LDAP requests that are issued before
starting to process the results. This is especially needed when
dealing with large groups, otherwise the server might choke on us
(e.g. OpenLDAP has a (configurable) limit of 100 pending operations
per anonymous connection and 1000 per authenticated connection).
OTOH sending multiple LDAP request at once will speed up things a
bit compared to just sending the next request after processing the
result of the previous.
- populate the member attribute with the correct sysdb DNs to
utilize Patch1.
- limit the group unrolling to rfc2307bis for now. rfc2307 and IPA
need to be treated differently as discussed previously in this
thread.
Patch3: This adds a new config option to ldap_unroll_group_members to
enable/disable group unrolling
regards,
Ralf
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
From 910f5c16ba1dda5f29a43af134683108d3d10ae3 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Thu, 16 Sep 2010 17:24:17 +0200
Subject: [PATCH 1/3] Shortcut for save_group() to accept sysdb DNs as member attributes
Addtional parameter sysdb_member_dns for save_group() and save_groups()
to indicate that the member attribute of the groups is populated with
sysdb DNs of the members (instead of LDAP DNs).
---
src/providers/ldap/sdap_async_accounts.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 8999ba0..d1c6378 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -609,6 +609,7 @@ static int sdap_save_group(TALLOC_CTX *memctx,
struct sss_domain_info *dom,
struct sysdb_attrs *attrs,
bool store_members,
+ bool sysdb_member_dns,
char **_timestamp)
{
struct ldb_message_element *el;
@@ -697,7 +698,19 @@ static int sdap_save_group(TALLOC_CTX *memctx,
}
}
-if (store_members) {
+if (sysdb_member_dns) {
+struct ldb_message_element *el1;
+ret = sysdb_attrs_get_el(attrs, opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el1);
+if (ret != EOK) {
+goto fail;
+}
+ret = sysdb_attrs_get_el(group_attrs, SYSDB_MEMBER, el);
+if (ret != EOK) {
+goto fail;
+}
+el-values = el1-values;
+el-num_values = el1-num_values;
+} else if (store_members) {
ret = sysdb_attrs_get_el(attrs,
opts-group_map[SDAP_AT_GROUP_MEMBER].sys_name, el);
if (ret != EOK) {
@@ -808,6 +821,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
struct sdap_options *opts,
struct sysdb_attrs **groups,
int num_groups,
+bool sysdb_member_dns,
char **_timestamp)
{
TALLOC_CTX *tmpctx;
@@ -848,7 +862,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
/* if 2 pass savemembers = false */
ret = sdap_save_group(tmpctx, sysdb,
opts, dom, groups[i],
- (!twopass), timestamp);
+ (!twopass), sysdb_member_dns, timestamp);
/* Do not fail completely on errors.
* Just report the failure to save and go on */
@@ -872,7 +886,7 @@ static int sdap_save_groups(TALLOC_CTX *memctx,
}
}
-if (twopass) {
+if (twopass !sysdb_member_dns) {
for (i = 0; i num_groups; i++) {
@@ -988,6 +1002,7 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
ret = sdap_save_groups(state, state-sysdb,
state-dom, state-opts,
state-groups, state-count
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Friday 10 September 2010 13:48:31 Simo Sorce wrote: On Fri, 10 Sep 2010 12:06:25 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 18:33:26 Simo Sorce wrote: So we have the following scenarios: 1) If we use rfc2307 classic with memberUid attributes, we can just create the fake/expired users and be done with it. Agreed. 2) If we use rfc2307bis w/o nested groups we can count the number of members on the group entry and switch to a full user enumeration if the number of members is greater than a defined (potentially user defined) threshold. Assuming a threshold value of 100, if we have 10 members we just do 10 lookups, while, if we have 100 member we do a full enumeration (it's a single ldap search, and if modifyTimestamp is used also highly optimized after the first search) so we are sure all users are there with the right name. I think that's an optimization that could be worth exploring later. In a first iteration I'd just go for implementing the complete group lookup by looking up every single user regardless of how large the group is. (plus the possiblity to completely disable member unrolling through the configuration) Ok, although performances will suck so much I bet we will have to implement the optimization pretty soon. After doing some test here, I really wonder if the LDAP lookups are going to be the bottleneck. I just tested a slightly improved version of my previous patch with a group with 500 members (not really big, I know). Doing getent group on that group takes about 2sec on my testsystem, which is really slow (nss_ldap needs 0.5sec). But looking closer at that, the LDAP searches and the processing of the search results accounts only for about 160ms of that two seconds. Much more time (more than 1sec) is then spent in saving the user objects and the group in sysdb. Probably it would be worth looking for optimizations in that area first. Other calls (initgroups?) could benefit from that as well. Note, I already save all users in one transaction instead of starting a new transaction for every user. Also note that, opening the sysdb with LDB_FLG_NOSYNC brings down the time to about 1.3sec. [..] regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Friday 10 September 2010 15:34:22 Simo Sorce wrote: On Fri, 10 Sep 2010 09:06:29 -0400 Dmitri Pal d...@redhat.com wrote: Is this the right summary: 1a) Initgroups do not fetch groups from LDAP - bug I am not sure this is correct. It normally works (we have tests) but it may not work properly in some conditions. Does you testcases probably call getpwnam() before calling initgroups/getgrouplist()? Ralf can you open a bug with logs and all ? This is now #620. 1b) When the user is already cached and rfc2307bis+memberof is used on the Serverside, nothing is returned upon the first initgroups call (bug above), but the cache is correctly populated with the groups, a second initgroups call then returns the correct results (task to test related to the bug above). I never seen this myself, but I haven't tested the code lately either, I'll let Ralf comment as he is the one seeing it. I created #621 for this. 2) When using rfc2307 or rfc2307bis (without memberof Attributes) initgroups() seems completely broken. (this is probably related to ticket 595) Yeah maybe just add note to 595 if necessary. The rfc2307bis issue is #595, yes. sssd just assumes that memberof is in place when rfc2307bis is configured. It seems that the rfc2307 problem is something different though. I created #622 for that. 3) Have a config option to enable/disable nested groups rolling with default enabled. We should document the scenarios when it makes sense to enable or disable it. We actually proposed 2 different options in the mail thread. Option 1. Fetch/Do not fetch, all group members (default disabled) Option 2. Resolve Nested Groups, here I think the default should depend on what the server offers. If it is IPA with its memberof we can always properly resolve nested groups with almost no effort, so we should have nested groups enable by default as we encourage using them in the server. For other servers I am not sure what is the best default. In general having it on by default is not a bad idea, unless the server has been managed so badly that nesting causes issues. The main reason for turning it off by default for rfc2307bis is IMO that it causes lots of unneeded LDAP lookups even when no nested groups are used. In initgroups() you'll have to read every groupmember to check if it probably is another group. Another way would be to make this a property of the schema you choose, and differentiate between rfc2307bis and rfc2307bis+nested groups by having a different name. 4) Add marking to the objects. Complete mark is put on the user object when all groups he is a member of are fetched. The groups that were fetched and were not in the cache are marked as incomplete. This is only on initgroups calls, and I think the first part (properly marking the user) is already implemented, we only need to mark the groups differently. When the group members are enumerated for a group all users for a group should be fetched and group should be marked as complete, users fetched by this lookup that were not in the cache are marked as incomplete. Why? Or do you mean incomplete wrt to the initgroups() call for that user. I think we could manage by simply marking users as expired, although this may cause issues if we go offline, as we do not have uid/gid and other fields ... probably we can simply leave those fields off, and this will automatically make them incomplete. We would have to make sure the rest of the code can cope (and filter out) these users when we are offline. Are you talking about the rfc2307 case, were dummy user object could be created? In the other cases (IPA, rfc2307bis) the complete user objects (including gid, uid,...) should be read from LDAP IMO. Reading only a subset there has no real advantage IMO. In the implementation there is probably no difference between the case when entry does not exist or or has incomplete status. Indeed, incomplete entries need to be revalidated (if online) or just filtered (when offline). In both cases same action needs to be taken. In both cases we need to fetch an entry. So I guess we really need just the complete mark. The difference is between the online and the offline case, but in the end yes, the complete mark is what will validate the entry for use. Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] Behaviour of getgrnam/getgrgid
Hi,
Is it really the intended behaviour of the sssd LDAP backend (I am
running the current code from the master branch) to only return the group
members that are already cached in sysdb and to silently ignore
everything else? E.g. when I start sssd with empty caches and do a
getent group random-ldap-group I will only get back the group without
any members. Somehow I think this can't be intended :)
I have started working on a patch to let sssd look up the non-cached
users via LDAP (and save them into the cache). Find it attached. Note:
That patch is not really complete (e.g. it doesn't handle rfc2307 groups
correctly). But before putting more effort into this I like to make sure
that I am not trying to fix a feature here.
--
regards,
Ralf
From 063dab6715f97aeeb6c29f5c3210f609cfea0f81 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Wed, 8 Sep 2010 10:30:03 +0200
Subject: [PATCH] Return all group members from getgr(nam|gid)
getgrnam()/getgrgid() should return all group members instead of only those
which have already been cached (in sysdb). To achieve this every member
that is currently not in the cache is looked up via LDAP and saved to the
cache.
---
src/providers/ldap/sdap_async_accounts.c | 177 --
1 files changed, 169 insertions(+), 8 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 8999ba0..795c7ca 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -4,6 +4,7 @@
Async LDAP Helper routines
Copyright (C) Simo Sorce sso...@redhat.com - 2009
+Copyright (C) 2010, Ralf Haferkamp rha...@suse.de, Novell Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -917,6 +918,20 @@ struct sdap_get_groups_state {
char *higher_timestamp;
struct sysdb_attrs **groups;
size_t count;
+size_t check_count;
+};
+
+struct sdap_process_group_state {
+struct tevent_context *ev;
+struct sdap_options *opts;
+struct sdap_handle *sh;
+struct sss_domain_info *dom;
+struct sysdb_ctx *sysdb;
+
+struct sysdb_attrs *group;
+struct sysdb_attrs **new_members;
+size_t count;
+size_t check_count;
};
static void sdap_get_groups_process(struct tevent_req *subreq);
@@ -962,13 +977,22 @@ struct tevent_req *sdap_get_groups_send(TALLOC_CTX *memctx,
return req;
}
+static void sdap_groupmember_process(struct tevent_req *subreq);
+static void sdap_group_process(struct tevent_req *subreq);
+
static void sdap_get_groups_process(struct tevent_req *subreq)
{
struct tevent_req *req = tevent_req_callback_data(subreq,
struct tevent_req);
struct sdap_get_groups_state *state = tevent_req_data(req,
struct sdap_get_groups_state);
-int ret;
+struct tevent_req *process_member_req;
+struct tevent_req *process_grp_req;
+struct ldb_message_element *el;
+struct sdap_process_group_state *grp_state;
+const char **attrs;
+char *filter;
+int ret,i,k;
ret = sdap_get_generic_recv(subreq, state,
state-count, state-groups);
@@ -985,19 +1009,156 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
return;
}
-ret = sdap_save_groups(state, state-sysdb,
- state-dom, state-opts,
- state-groups, state-count,
- state-higher_timestamp);
+state-check_count = state-count;
+
+ret = build_attrs_from_map(state, state-opts-user_map, SDAP_OPTS_USER,
+ attrs);
+filter = talloc_asprintf(state, (objectclass=%s),
+ state-opts-user_map[SDAP_OC_USER].name);
+
+for (i=0; i state-count; i++) {
+ret = sysdb_attrs_get_el(state-groups[i],
+state-opts-group_map[SDAP_AT_GROUP_NAME].sys_name, el);
+if (ret || el-num_values == 0) {
+tevent_req_error(req, ENOENT);
+return;
+}
+
+DEBUG(2, (Processing Group %s\n, (const char*)el-values[0].data));
+process_grp_req = tevent_req_create(state, grp_state,
+struct sdap_process_group_state);
+if (!process_grp_req) {
+tevent_req_error(req, ENOMEM);
+return;
+}
+
+grp_state-ev = state-ev;
+grp_state-opts = state-opts;
+grp_state-dom = state-dom;
+grp_state-sh = state-sh;
+grp_state-sysdb = state-sysdb;
+grp_state-group = state-groups[i];
+grp_state-check_count = 0;
+grp_state-new_members = NULL;
+tevent_req_set_callback(process_grp_req, sdap_group_process, req);
+
+ret = sysdb_attrs_get_el
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thursday 09 September 2010 15:59:46 Simo Sorce wrote: On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Then it should probably be possible to disable that feature separately from enumeration. While, turning enumerations off by default makes sense to me, I think returning incomplete results when resolving groups by default goes a bit too far. BTW, I just found out that the behaviour of getgrouplist()/initgroups() is similar currently. It will only return the groups that are already present in the cache. That means in many cases it will return nothing. (Or just the gid you supplied via the group argument). Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. Why is that? Users should of course be saved in the sysdb after being read from LDAP. If you read another group which has that user as a member the result is taken from the cache of course. (That's what my patch tries to do at least, though I admit there is still room for optimization) And if you have a *lot* of users this would defeat the point of disabling enumerations, making performances actually worse. So please do not change this without proper discussion. regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Two enhancements for PAM client
Am Donnerstag 22 April 2010 17:03:23 schrieb Sumit Bose: On Thu, Apr 22, 2010 at 04:37:36PM +0200, Ralf Haferkamp wrote: Am Donnerstag 22 April 2010 12:08:46 schrieb Sumit Bose: Hi, the two patches attached should fix #446 and #417 respectively. For #417 a different solution, where the message is generated by SSSD and send to the client, would be possilbe. But I decided against it, because with the attached patch it is possilbe to support localized messages. Pardon my ignorance, but why can messages generated by the daemon not be localized? Am I overlooking something? The messages generated by the daemon can be localized, but I meant the localization with respect to the settings of the client. The client is this case is the PAM module. Which is running as root usually (as is sssd). For best localization you'd need to run in the locale of the authenticating user. So there is no advantage in generating the strings on the client side (at least for the PAM module). It makes some things even harder as the messeage are obviously very depened on the backend that is used. I agree that for other clients (!=PAM) the localization could be easier handled on the client side. We had a longer discussion about how to handle localization and came to the agreement that this should be done on the client side, because the client knows best about this locale settings and the use of gettext() is straight forward. In this special case it would be possible to let the client send it's locale to the SSSD and let the SSSD open the file and send back the content. But this would mean that we have to send more data through the pipe. -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Two enhancements for PAM client
Am Donnerstag 22 April 2010 12:08:46 schrieb Sumit Bose: Hi, the two patches attached should fix #446 and #417 respectively. For #417 a different solution, where the message is generated by SSSD and send to the client, would be possilbe. But I decided against it, because with the attached patch it is possilbe to support localized messages. Pardon my ignorance, but why can messages generated by the daemon not be localized? Am I overlooking something? -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Improvements for LDAP Password Policy support
Am Donnerstag 18 März 2010 15:25:49 schrieb Dmitri Pal:
Ralf Haferkamp wrote:
Am Donnerstag 18 März 2010 12:42:23 schrieb Simo Sorce:
On Wed, 17 Mar 2010 15:33:38 +0100
Ralf Haferkamp rha...@suse.de wrote:
Hi,
here's another set of enhancements to the LDAP Password Policy
support in the PAM module and the LDAP backend. The PAM module now
issues warning when either the grace counter or the expire counter
of the LDAP Ppolicy Control in 0.
Addtionally I changed the detection for Ppolicy support of the
LDAP Server a bit. If the Server returned the Ppolicy Control in
the Bind Response ppolicy support is assumed.
I left the original check for pwdAttribute intact, though I
think it doesn't make a lot of sense. The pwdAttribute LDAP
Attribute is usually not part of the user's entry, it's part of
the Entry that contains the Policy. Addtionally it might be
protected by ACLs and not be returned for anonymous (without
losing any functionality).
Ralf,
patch looks mostly good, but there are some heavy coding style
violations.
if ( condition ){ is not good, it should be: is (condition) {
same for some functions foo( ccc ); is not good, use foo(ccc);
Ie, no space in parenthesis, a space only after keywords, and
always before the opening {
Don't use ++x, but x++ if possible.
Also there is at least one place where the return of talloc is not
checked.
Finally please try to keep the 80 columns limit where possible.
Updated patch attached. I think I fixed the coding style issues.
Additionally I just noticed that my orginal patch broke password
resets via LDAP password policies. This should be fixed now as
well.
regards,
Ralf
+data = talloc_size(pd, 2* sizeof(uint32_t));
+if (*data == NULL) {
+DEBUG(1, (talloc_size failed.\n));
+return ENOMEM;
+}
The returned value check does not look right.
I do not know if there are other places with similar logic.
There weren't (The one above was embarrasing enough. I must have
overlooked the compiler warning :| ). Updated patch attached.
My eye just caught it when I was scrolling through the patch...
Ralf
From 1bcc807693212861807849b582bae3bb75e889ca Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 12 Mar 2010 10:54:40 +0100
Subject: [PATCH] Improvements for LDAP Password Policy support
Display warnings about remaining grace logins and password
expiration to the user, when LDAP Password Policies are used.
Improved detection if LDAP Password policies are supported by
LDAP Server.
---
src/providers/ldap/ldap_auth.c | 52 +-
src/providers/ldap/sdap.h |5 ++
src/providers/ldap/sdap_async.h|6 ++-
src/providers/ldap/sdap_async_connection.c | 53 +++
src/sss_client/pam_sss.c | 82
src/sss_client/sss_cli.h | 23 ++---
6 files changed, 201 insertions(+), 20 deletions(-)
diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c
index 5228703..8c77e3a 100644
--- a/src/providers/ldap/ldap_auth.c
+++ b/src/providers/ldap/ldap_auth.c
@@ -7,6 +7,7 @@
Sumit Bose sb...@redhat.com
Copyright (C) 2008 Red Hat
+Copyright (C) 2010, rha...@suse.de, Novell Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -135,6 +136,39 @@ static errno_t check_pwexpire_shadow(struct spwd *spwd, time_t now,
return EOK;
}
+static errno_t check_pwexpire_ldap(struct pam_data *pd,
+ struct sdap_ppolicy_data *ppolicy,
+ enum sdap_result *result)
+{
+if (ppolicy-grace 0 || ppolicy-expire 0) {
+uint32_t *data;
+uint32_t *ptr;
+
+data = talloc_size(pd, 2* sizeof(uint32_t));
+if (data == NULL) {
+DEBUG(1, (talloc_size failed.\n));
+return ENOMEM;
+}
+
+ptr = data;
+if (ppolicy-grace 0) {
+*ptr = SSS_PAM_USER_INFO_GRACE_LOGIN;
+ptr++;
+*ptr = ppolicy-grace;
+} else if (ppolicy-expire 0) {
+*ptr = SSS_PAM_USER_INFO_EXPIRE_WARN;
+ptr++;
+*ptr = ppolicy-expire;
+}
+
+pam_add_response(pd, SSS_PAM_USER_INFO, 2* sizeof(uint32_t),
+ (uint8_t*)data);
+}
+
+*result = SDAP_AUTH_SUCCESS;
+return EOK;
+}
+
static errno_t string_to_shadowpw_days(const char *s, long *d)
{
long l;
@@ -569,8 +603,15 @@ static void auth_bind_user_done(struct tevent_req *subreq)
struct auth_state *state = tevent_req_data(req,
struct auth_state);
int ret;
-
-ret = sdap_auth_recv(subreq, state-result
[SSSD] [Patch] Fix for SUSE init script
Hi, attached a small fix for the SUSE init script to use logfiles for debug logging. -- Ralf From 7a33b5915571e1c38fec3f5e69b1d1711148db1b Mon Sep 17 00:00:00 2001 From: Ralf Haferkamp rha...@suse.de Date: Mon, 8 Mar 2010 14:42:06 +0100 Subject: [PATCH] use logfiles for debug messages --- src/sysv/SUSE/sssd |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/sysv/SUSE/sssd b/src/sysv/SUSE/sssd index 34fd837..2f98c21 100644 --- a/src/sysv/SUSE/sssd +++ b/src/sysv/SUSE/sssd @@ -29,7 +29,7 @@ PID_FILE=/var/run/sssd.pid case $1 in start) echo -n Starting $prog -/sbin/startproc $SSSD -D 2/dev/null +/sbin/startproc $SSSD -f -D 2/dev/null rc_status -v ;; -- 1.6.4.2 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] Improvements for LDAP Password Policy support
Hi,
here's another set of enhancements to the LDAP Password Policy support in
the PAM module and the LDAP backend. The PAM module now issues warning
when either the grace counter or the expire counter of the LDAP Ppolicy
Control in 0.
Addtionally I changed the detection for Ppolicy support of the LDAP
Server a bit. If the Server returned the Ppolicy Control in the Bind
Response ppolicy support is assumed.
I left the original check for pwdAttribute intact, though I think it
doesn't make a lot of sense. The pwdAttribute LDAP Attribute is usually
not part of the user's entry, it's part of the Entry that contains the
Policy. Addtionally it might be protected by ACLs and not be returned for
anonymous (without losing any functionality).
--
Ralf
From 0b06bdc110a489802e359ceea3b890cf84524491 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 12 Mar 2010 10:54:40 +0100
Subject: [PATCH] Improvements for LDAP Password Policy support
Display warnings about remaining grace logins and password
expiration to the user, when LDAP Password Policies are used.
Improved detection if LDAP Password policies are supported by
LDAP Server.
---
src/providers/ldap/ldap_auth.c | 44 +++-
src/providers/ldap/sdap.h |5 ++
src/providers/ldap/sdap_async.h|6 ++-
src/providers/ldap/sdap_async_connection.c | 43
src/sss_client/pam_sss.c | 79
src/sss_client/sss_cli.h | 23 ++---
6 files changed, 180 insertions(+), 20 deletions(-)
diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c
index 5228703..aec31dd 100644
--- a/src/providers/ldap/ldap_auth.c
+++ b/src/providers/ldap/ldap_auth.c
@@ -7,6 +7,7 @@
Sumit Bose sb...@redhat.com
Copyright (C) 2008 Red Hat
+Copyright (C) 2010, rha...@suse.de, Novell Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -135,6 +136,31 @@ static errno_t check_pwexpire_shadow(struct spwd *spwd, time_t now,
return EOK;
}
+static errno_t check_pwexpire_ldap(struct pam_data *pd,
+ struct sdap_ppolicy_data *ppolicy,
+ enum sdap_result *result)
+{
+if ( ppolicy-grace 0 || ppolicy-expire 0 ){
+uint32_t *data = talloc_size(pd, 2* sizeof(uint32_t));
+uint32_t *ptr = data;
+if ( ppolicy-grace 0 ){
+*ptr = SSS_PAM_USER_INFO_GRACE_LOGIN;
+++ptr;
+*ptr = ppolicy-grace;
+} else if ( ppolicy-expire 0 ) {
+*ptr = SSS_PAM_USER_INFO_EXPIRE_WARN;
+++ptr;
+*ptr = ppolicy-expire;
+}
+
+pam_add_response( pd, SSS_PAM_USER_INFO, 2*sizeof(uint32_t),
+ (uint8_t*)data );
+}
+
+*result = SDAP_AUTH_SUCCESS;
+return EOK;
+}
+
static errno_t string_to_shadowpw_days(const char *s, long *d)
{
long l;
@@ -569,8 +595,15 @@ static void auth_bind_user_done(struct tevent_req *subreq)
struct auth_state *state = tevent_req_data(req,
struct auth_state);
int ret;
-
-ret = sdap_auth_recv(subreq, state-result);
+struct sdap_ppolicy_data *ppolicy;
+
+ret = sdap_auth_recv(subreq, state, state-result, ppolicy);
+if ( ppolicy ){
+DEBUG(9,(Found ppolicy data,
+ assuming LDAP password policies are active.\n));
+state-pw_expire_type = PWEXPIRE_LDAP_PASSWORD_POLICY;
+state-pw_expire_data = ppolicy;
+}
talloc_zfree(subreq);
if (ret) {
tevent_req_error(req, ret);
@@ -960,6 +993,13 @@ static void sdap_pam_auth_done(struct tevent_req *req)
}
break;
case PWEXPIRE_LDAP_PASSWORD_POLICY:
+ret = check_pwexpire_ldap(state-pd, pw_expire_data, result);
+if (ret != EOK) {
+DEBUG(1, (check_pwexpire_ldap failed.\n));
+state-pd-pam_status = PAM_SYSTEM_ERR;
+goto done;
+}
+break;
case PWEXPIRE_NONE:
break;
default:
diff --git a/src/providers/ldap/sdap.h b/src/providers/ldap/sdap.h
index 007185f..f0e345e 100644
--- a/src/providers/ldap/sdap.h
+++ b/src/providers/ldap/sdap.h
@@ -85,6 +85,11 @@ struct sdap_service {
char *uri;
};
+struct sdap_ppolicy_data {
+int grace;
+int expire;
+};
+
#define SYSDB_SHADOWPW_LASTCHANGE shadowLastChange
#define SYSDB_SHADOWPW_MIN shadowMin
#define SYSDB_SHADOWPW_MAX shadowMax
diff --git a/src/providers/ldap/sdap_async.h b/src/providers/ldap/sdap_async.h
index 3c52d23..888df6b 100644
--- a/src/providers/ldap/sdap_async.h
+++ b/src/providers/ldap/sdap_async.h
@@ -76,7 +76,11 @@ struct tevent_req
[SSSD] [PATCH] Various fixes/improvment to ldap ppolicy handling
Hi,
here are some more patches regarding the handling of the LDAP ppolicy
control.
Patch1: An error code of LDAP_INVALID_CREDENTIALS + a ppolicy control
with the error PP_passwordExpired indicates an expire password
as well.
Patch2: When doing LDAP authentiation for PAM_PRELIM_CHECK, treat
SDAP_AUTH_PW_EXPIRED as a successful authentication to be able to
continue the the password change
Patch3: Display a messages to the user when a password change is going to
be initiated because of an expired password.
feedback is of course welcome,
Ralf
From c4978d1f40c3cbaa6f24c0fa1d9f3b8b4c00e616 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 12 Mar 2010 15:06:44 +0100
Subject: [PATCH 1/3] Fixed check for expired passwords
When the user's password is expired it might also be indicated by
the bind operation returning INVALID_CREDENTIALS with the ppolicy
control's errorcode set to PP_passwordExpired.
---
src/providers/ldap/sdap_async_connection.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c
index 18e47d3..fe8a501 100644
--- a/src/providers/ldap/sdap_async_connection.c
+++ b/src/providers/ldap/sdap_async_connection.c
@@ -421,8 +421,10 @@ static void simple_bind_done(struct sdap_op *op,
error [%s].\n, pp_expire, pp_grace,
ldap_passwordpolicy_err2txt(pp_error)));
-if (state-result == LDAP_SUCCESS
-(pp_error == PP_changeAfterReset || pp_grace 0)) {
+if ((state-result == LDAP_SUCCESS
+(pp_error == PP_changeAfterReset || pp_grace 0)) ||
+(state-result == LDAP_INVALID_CREDENTIALS
+pp_error == PP_passwordExpired ) ) {
DEBUG(4, (User must set a new password.\n));
state-result = LDAP_X_SSSD_PASSWORD_EXPIRED;
}
--
1.6.4.2
From ef8f49bf3ac93402856f37fcbb5828b6e03563ca Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 12 Mar 2010 14:42:09 +0100
Subject: [PATCH 2/3] Fixed authentication check for CHAUTHTOK_PRELIM
When changing passwords, treat SDAP_AUTH_PW_EXPIRED as a successful
authentication in SSS_PAM_CHAUTHTOK_PRELIM.
---
src/providers/ldap/ldap_auth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/providers/ldap/ldap_auth.c b/src/providers/ldap/ldap_auth.c
index ba1136b..5228703 100644
--- a/src/providers/ldap/ldap_auth.c
+++ b/src/providers/ldap/ldap_auth.c
@@ -721,7 +721,7 @@ static void sdap_auth4chpass_done(struct tevent_req *req)
goto done;
}
-if (result == SDAP_AUTH_SUCCESS
+if ( (result == SDAP_AUTH_SUCCESS || result == SDAP_AUTH_PW_EXPIRED )
state-pd-cmd == SSS_PAM_CHAUTHTOK_PRELIM) {
DEBUG(9, (Initial authentication for change password operation
successful.\n));
--
1.6.4.2
From d8ca40aab756197c0806b1790387e83761e04321 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Fri, 12 Mar 2010 15:13:59 +0100
Subject: [PATCH 3/3] Warn user about an expired password
---
src/sss_client/pam_sss.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/sss_client/pam_sss.c b/src/sss_client/pam_sss.c
index ff3a7f9..2ba6f15 100644
--- a/src/sss_client/pam_sss.c
+++ b/src/sss_client/pam_sss.c
@@ -1122,7 +1122,12 @@ static int pam_sss(enum sss_cli_command task, pam_handle_t *pamh,
if (ret == PAM_SUCCESS task == SSS_PAM_ACCT_MGMT
pam_get_data(pamh, PWEXP_FLAG, (const void **) exp_data) ==
PAM_SUCCESS) {
-return PAM_NEW_AUTHTOK_REQD;
+ret = do_pam_conversation(pamh, PAM_TEXT_INFO,
+_(Password expired. Change your password now.), NULL, NULL);
+if (ret != PAM_SUCCESS) {
+D((do_pam_conversation failed.));
+}
+return PAM_NEW_AUTHTOK_REQD;
}
overwrite_and_free_authtoks(pi);
--
1.6.4.2
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] PATCH] Password changes and getuid() == 0 checks
Am Freitag 12 März 2010 16:41:47 schrieb Dmitri Pal: [..] Regardless of the outcome it would be nice to have a ticket open about the issue. Ok, this is now Ticket#417. -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] PATCH] Password changes and getuid() == 0 checks
Am Freitag 12 März 2010 17:58:48 schrieb Sumit Bose: On Fri, Mar 12, 2010 at 04:37:26PM +0100, Ralf Haferkamp wrote: Hi, I did some testing of pam_sss and the LDAP backend's password policy features and ran into some issue. One of the being the getuid() == 0 checks in pam_sss when checking whether the user needs to be prompted for the old password before changing the password. I guess the idention of those checks is that root should be able to change a users password without being prompted for the old password. There are however some issues with that: - Most PAM clients run with a real uid of root(0), so that check will not work correctly in many cases. A notable exception being the passwd command. But with password policies in place password changes can be triggered from almost every PAM client. - When using the LDAP backend even root would need to somehow authenticate against the LDAP Server to be able to change a users password. I'm not sure if we want to support the password resets by root at all with the LDAP backend. Typically there are a couple of different ways for an authorized user to change the password of a different user in an LDAP server. The same holds for a Kerberos server. Do you have use cases which can illustrate why it would make sense to support it in sssd? Because it just worked in the past :). (Which is of course not entirely true when pam_ldap was used. It has some issues in that area as well). IMO it would be enough to display a proper error message when root tries to change the password of an LDAP user. (But AFAICS this would require some bigger changes. The LDAP backend does currently have no information who is trying to change which password, if I didn't overlook something) But at least we should send a message to the user that the password reset is not possible and maybe a configurable hint how to do it like pam_password_prohibit_message. bye, Sumit [..] -- Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] SUSE specific init script
Hi,
based on the init script in server/sysv/ I created one for SUSE based
distributions. Sumit suggested to use server/sysv/sssd.SUSE for that. Find
a patch attached.
In future it would be nice to have make install automatically pick the
correct file. Any ideas how that could be implemented?
--
regards,
Ralf
From ea4a9c83c11bead6f0ab1099aed6a8bc952fd544 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Mon, 12 Oct 2009 15:15:36 +0200
Subject: [PATCH] SUSE specific init script
---
server/sysv/sssd.SUSE | 78 +
1 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 server/sysv/sssd.SUSE
diff --git a/server/sysv/sssd.SUSE b/server/sysv/sssd.SUSE
new file mode 100644
index 000..e070928
--- /dev/null
+++ b/server/sysv/sssd.SUSE
@@ -0,0 +1,78 @@
+#!/bin/sh
+### BEGIN INIT INFO
+# Provides: sssd
+# Required-Start: $remote_fs $time
+# Should-Start: $syslog
+# Should-Stop: $syslog
+# Required-Stop: $remote_fs
+# Default-Start: 3 5
+# Default-Stop: 0 1 2 4 6
+# Short-Description: System Security Services Daemon
+# Description: Provides a set of daemons to manage access to remote directories
+# and authentication mechanisms. It provides an NSS and PAM
+# interface toward the system and a pluggable backend system to
+# connect to multiple different account sources. It is also the
+# basis to provide client auditing and policy services for projects
+# like FreeIPA.
+### END INIT INFO
+
+RETVAL=0
+prog=sssd
+
+# Source function library.
+. /etc/rc.status
+rc_reset
+
+SSSD=/usr/sbin/sssd
+PID_FILE=/var/run/sssd.pid
+
+case $1 in
+start)
+echo -n Starting $prog
+/sbin/startproc $SSSD -D 2/dev/null
+rc_status -v
+;;
+
+stop)
+echo -n Shutting down $prog
+/sbin/killproc -p $PID_FILE $SSSD -TERM
+rc_status -v
+;;
+
+restart)
+$0 stop
+$0 start
+rc_status
+;;
+
+reload)
+echo -n Reload service $prog
+killproc $SSSD -HUP
+rc_status -v
+;;
+
+force-reload)
+$0 reload
+;;
+
+status)
+echo -n Checking for service $prog
+/sbin/checkproc $SSSD
+rc_status -v
+;;
+
+condrestart|try-restart)
+$0 status
+if test $? = 0; then
+$0 restart
+else
+rc_reset# Not running is not a failure.
+fi
+rc_status
+;;
+*)
+echo Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}
+exit 1
+esac
+rc_exit
+
--
1.6.4.2
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] LDAP provider needs to link against krb libraries
Hi, since the LDAP provider does calls into the krb5 libs it should also be linked against them :). Attached patch should fix that. -- regards, Ralf From 6169242cc432b48d86eaae03fbee52af69527860 Mon Sep 17 00:00:00 2001 From: Ralf Haferkamp rha...@suse.de Date: Mon, 12 Oct 2009 11:50:30 +0200 Subject: [PATCH] LDAP provider needs to link against krb libraries --- server/Makefile.am |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/server/Makefile.am b/server/Makefile.am index a65c9fa..6c08274 100644 --- a/server/Makefile.am +++ b/server/Makefile.am @@ -424,9 +424,11 @@ libsss_ldap_la_SOURCES = \ providers/ldap/sdap.c libsss_ldap_la_CFLAGS = \ $(AM_CFLAGS) \ -$(LDAP_CFLAGS) +$(LDAP_CFLAGS) \ +$(KRB5_CFLAGS) libsss_ldap_la_LIBADD = \ -$(OPENLDAP_LIBS) +$(OPENLDAP_LIBS) \ +$(KRB5_LIBS) libsss_ldap_la_LDFLAGS = \ -version-info 1:0:0 \ -module -- 1.6.4.2 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
