Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

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 >

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

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

Re: [WIP] mod_authnz_ldap / mod_ldap support for APR v2 LDAP API

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

Re: [VOTE] Release httpd-2.4.59-rc1 as httpd-2.4.59

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

Re: mod_systemd: refactor to get rid of libsystemd dependency?

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 >

Re: mod_ssl: Add support for loading keys from OpenSSL 3.x providers via STORE

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

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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: > >

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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

Re: svn commit: r1913977 - /httpd/httpd/trunk/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

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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:

Re: svn commit: r1914067 - in /httpd/httpd/trunk: changes-entries/ldap-optimise.txt modules/aaa/mod_authnz_ldap.c

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

Re: svn commit: r1914067 - in /httpd/httpd/trunk: changes-entries/ldap-optimise.txt modules/aaa/mod_authnz_ldap.c

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;

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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,

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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:

Re: svn commit: r1913977 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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 —

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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

Re: svn commit: r1913962 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c

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

Re: svn commit: r1591012 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number modules/aaa/mod_authnz_ldap.c

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.

Re: svn commit: r1913936 - /httpd/httpd/branches/2.4.x/STATUS

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

Re: svn commit: r1909137 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_alias.c

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,

Re: [VOTE] Switch read/write repository from Subversion to Git

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 >

Re: ci vs PR approvals? (was: [apache/httpd] Fix a possible NULL pointer dereference in hook_uri2file (PR #355))

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

Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

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

Re: svn commit: r1909135 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h server/core.c

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 >

POC: updated ldapi:// support for mod_ldap

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 === ---

Re: svn commit: r1909137 - in /httpd/httpd/trunk: CHANGES modules/mappers/mod_alias.c

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

Re: mod_dav and PATH_INFO - MKCOL silently creates the parent directory

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

Re: mod_dav and PATH_INFO - MKCOL silently creates the parent directory

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

mod_dav and PATH_INFO - MKCOL silently creates the parent directory

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