On 19 Apr 2024, at 09:01, Ruediger Pluem wrote:
> First of all I haven't gone through the patch. Hence I may be off below.
>
> I think the core issue with the LDAP API we have in APR-UTIL 1.x today and
> that let to the
> removal discussions on APR side in 2010
>
On 19 Apr 2024, at 09:07, Ruediger Pluem wrote:
> Would it be possible to provide this patch as a PR against trunk on Github? I
> think that would ease reviewing it.
> I am quite aware that this moves some gory detail discussion of that patch
> away from the dev list here and over
> to the PR
On 18 Apr 2024, at 14:21, Joe Orton wrote:
> This design decision seems surprising to me, what does this add? Adding
> another abstraction layer to allow runtime selection of the LDAP library
> seems like a step backwards (a lot of complexity with no benefit).
> Unlike with e.g. a database
On 03 Apr 2024, at 13:26, Eric Covener wrote:
> [ ] +1: It's not just good, it's good enough!
+1 on RHEL9.
Regards,
Graham
--
On 02 Apr 2024, at 11:25, Rainer Jung wrote:
> in the light of the recent xz attack I was wondering, whether we should also
> reduce our library dependencies by no longer using sd_notify() in mod_systemd
> (thus loading libsystemd and all of its dependencies), but instead taking the
>
On 27 Nov 2023, at 15:02, Ingo Franzki wrote:
> The mod_ssl module has support for loading keys and certificates from OpenSSL
> engines via PKCS#11 URIs at SSLCertificateFile and SSLCertificateKeyFile,
> e.g. using the PKCS#11 engine part of libp11
> (https://github.com/OpenSC/libp11).
>
>
On 24 Nov 2023, at 19:26, Ruediger Pluem wrote:
>> We do - and we also need to apr_pstrdup() the dn to be consistent with the
>> rest.
>
> Why? dn is already apr_pstrdup from r->pool:
>
>
On 24 Nov 2023, at 14:25, Ruediger Pluem wrote:
>> +req->dn = dn;
>
> Don't we need to save the vals as well?
We do - and we also need to apr_pstrdup() the dn to be consistent with the rest.
Index: modules/aaa/mod_authnz_ldap.c
On 24 Nov 2023, at 10:03, Yann Ylavic wrote:
> +1 this is pretty much what Rüdiger proposed earlier and it aligns
> with the proposed 2.4.x backport so I understand better :)
Rüdiger’s patch had conflicts in the time he posted it and now, I reapplied his
changes in the above patch and
On 20 Nov 2023, at 15:10, Ruediger Pluem wrote:
> Revisiting this again. I guess the below patch should fix it.
> I assume that only the checking on req != NULL is relevant.
> r->user and req->dn do not matter. But we should set req->dn to dn
> if util_ldap_cache_getuserdn found one.
>
> BTW:
On 23 Nov 2023, at 13:28, Yann Ylavic wrote:
>> Unfortunately the message is correct and we do just that via
>> get_dn_for_nonldap_authn (line 1451). The DN you mention we look for
>> later in line 1480 via util_ldap_cache_getuserdn.
>
> My guess was that if r->user is set we always want to
On 23 Nov 2023, at 11:25, Ruediger Pluem wrote:
>> -if (req->dn == NULL || !*req->dn) {
>> -ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02636)
>> - "auth_ldap authorize: require ldap-filter: user's DN "
>> - "has not been defined;
On 20 Nov 2023, at 15:32, Yann Ylavic wrote:
> OK, I drop a new v3 here just in case and let those who know how LDAP
> authn/authz work take whatever :)
> This is just to show that there is some room for
> factorization/disambiguation in this code..
>
>
> Regards;
> Yann.
>
Just tested this,
On 20 Nov 2023, at 15:10, Ruediger Pluem wrote:
> Revisiting this again. I guess the below patch should fix it.
> I assume that only the checking on req != NULL is relevant.
> r->user and req->dn do not matter. But we should set req->dn to dn
> if util_ldap_cache_getuserdn found one.
>
> BTW:
On 20 Nov 2023, at 12:26, Ruediger Pluem wrote:
> Or we need to ensure that authn_ldap_build_filter is NULL safe and returns in
> a sensible way if user == NULL.
This is the option we need I think - it’s possible that ldapsearch could be
used without a user.
Regards,
Graham
—
On 20 Nov 2023, at 12:10, Yann Ylavic wrote:
>> Fine, but if r->user is NULL here we'll segfault (NULL dereference) in
>> "if (!*r->user)" here.
>
> Probably an unfortunate copy/paste in trunk only (not in your backport
> patch3), fixed in r1913977.
Thanks for this - it’s been making my head
On 20 Nov 2023, at 09:32, Ruediger Pluem wrote:
>> -if (sec->host) {
>> +if (!sec->host) {
>> +ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, APLOGNO(01738)
>
> This log message had the number 02636 before.
I’ve fixed these.
They don’t appear to affect the ldapsearch backport
On 20 Nov 2023, at 10:44, Yann Ylavic wrote:
>> URL: http://svn.apache.org/viewvc?rev=1913962=rev
>> Log:
>> Apply earlier fix to the ldapsearch case:
>>
>> Arrange for backend LDAP connections to be returned
>> to the pool by a fixup hook rather than staying locked
>> until the end of (a
On 18 Nov 2023, at 17:14, Yann Ylavic wrote:
> Oh it seems that the callers want the "filtbuf" to be \0 terminated
> (even in case of error), so this v2 probably..
Looking at this now.
Seems to be some differences between trunk and v2.4, seeing how they can be
aligned to make this easier.
On 18 Nov 2023, at 14:43, Yann Ylavic wrote:
> Do we need an MMN bump for some ap_proxy_ functions added to
> proxy_util.h (non public header), though AP_PROXY_DECLARE()d because
> they need to be accessible from several proxy modules SSOs?
I double checked, thought proxy_util.h was public when
On 17 Apr 2023, at 12:07, Yann Ylavic wrote:
>> The question is if we find an approach to
>> make it backportable e.g. by adding some kind of 2.4.x only configuration
>> switch to get the behavior of r1909137.
>
> Maybe "AliasPerDirRelative on" (default: "off", context: "server
> config,
On 04 May 2023, at 09:34, Ruediger Pluem wrote:
> This is a formal vote on whether we should move our read/write repository
> from Subversion to Git.
> This means that our latest read/write repository will be no longer available
> via svn.apache.org. It
> will be available via Git at
>
On 25 Apr 2023, at 07:45, Ruediger Pluem wrote:
> 2. Switching from Subversion to Git is mostly an emotional problem for me. We
> have some closer ties to Subversion by some
> overlaps in the community and via mod_dav_svn we kind of partially eat our
> very own dogfood here by using
On 19 Mar 2020, at 12:26, Graham Leggett wrote:On 19 Mar 2020, at 02:40, Eric Covener wrote:Neat, have you thought about mod_auth_form in relation to this?Something on my wishlist has been to not put the password in thesession / not continue to call the original auth
On 19 Apr 2023, at 19:08, Yann Ylavic wrote:
> Currently all the tests (framework) are broken due to cmd->regex not
> being properly stacked/scoped.
> If cmd->regex is to be used to store the enclosing section's regex, it
> should be saved and restored by *all* the the sections (much like
>
Hi all,
This is a patch for httpd that adds support for ldapi:// URLs to mod_ldap and
friends.
It depends on a patch for apr-util posted to the dev@apr list.
Regards,
Graham
—
Index: include/util_ldap.h
===
---
On 14 Apr 2023, at 17:18, Ruediger Pluem wrote:
> Would that break configs like
>
>
>
> Alias /filesystemprefix/%{HTTP:X-example-header}
>
>
>
> where the expression evaluation determines the complete filesystem path
> without adding the remainder of the URL?
It would, which alas might
On 13 Apr 2023, at 16:27, Graham Leggett wrote:
> Changing the config to this makes it work:
>
> Alias /storage /var/www/dav/storage
>
> It looks like the detail that’s missing that we don’t identify the rest of
> the URL after the alias and pass it on by calling alias_matches() to identify
On 13 Apr 2023, at 14:55, Graham Leggett via dev wrote:
> Config looks like this:
>
>
>Alias /var/www/dav/storage
>Dav on
>AcceptPathInfo On
>
Changing the config to this makes it work:
Alias /storage /var/www/dav/storage
It looks like the detail that’s
Hi all,
I am having super fun time trying to turn on mod_dav on an httpd v2.4.53-11.el9
(as shipped by RHEL9).
The request “MKCOL /storage/foo” returns a 201, but doesn't actually do
anything. The “foo” directory is silently not created.
Stepping through the code, the code that creates the
30 matches
Mail list logo