Bug 183925 - nsAdminAccessAddresses not working
nsAdminAccessAddresses not working
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Admin (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
:
Depends On:
Blocks: 152373 fds103trackingbug 240316
  Show dependency treegraph
 
Reported: 2006-03-03 14:54 EST by Rich Megginson
Modified: 2015-12-07 11:44 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:44:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Rich Megginson 2006-03-03 14:54:41 EST
The match success checking has been reversed.  If the pattern matches the client
IP address, the request is rejected.  If the pattern does not match, the request
is accepted.
Comment 1 Rich Megginson 2006-03-03 15:02:58 EST
One liner:

006-02-23 16:40:14.000000000 -0700
--- mod_admserv.c	2006-03-03 13:07:18.000000000 -0700
***************
*** 1913,1919 ****
      if (accessAddresses && *accessAddresses) {
          int matchflags = APR_FNM_PERIOD;
          apr_status_t rc = admserv_match_list(apr_pstrdup(r->pool,
accessAddresses), clientIP, matchflags);
!         if (rc == APR_SUCCESS) {
          } else {
              return DECLINED;
          }
--- 1913,1919 ----
      if (accessAddresses && *accessAddresses) {
          int matchflags = APR_FNM_PERIOD;
          apr_status_t rc = admserv_match_list(apr_pstrdup(r->pool,
accessAddresses), clientIP, matchflags);
!         if (rc != APR_SUCCESS) {
          } else {
              return DECLINED;
          }
Comment 2 Rich Megginson 2006-03-03 15:12:16 EST
Reviewed by: one line commit rule
Files: mod_admserv.c
Branch: HEAD
Fix Description: The comparison was reversed so that if the match is successful
the access is allowed.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none

Checking in mod_admserv.c;
/cvs/dirsec/mod_admserv/mod_admserv.c,v  <--  mod_admserv.c
new revision: 1.22; previous revision: 1.21
done
Comment 3 Thomas Vander Stichele 2006-11-26 05:29:13 EST
any reason not to just change this to:
if (rc == APR_SUCCESS) {
              return DECLINED;
          }

and make it easier to read in the process ?
Comment 4 Rich Megginson 2006-11-27 11:48:33 EST
For some reason, there are several places in the code where this style is used,
and we decided to just keep the same style for the sake of consistency.

This code is very old, written several years ago for the original Netscape
Enterprise Server based Admin Server and ported last year to an Apache module. 
We'd like to just get rid of it altogether and replace it with a proper java or
python web app, that's why we haven't been spending a lot of time maintaining
this code.
Comment 6 Albert Strasheim 2012-04-05 14:19:33 EDT
Is this still broken in 389-ds-1.2.2? Still having the issues described here:

http://www.redhat.com/archives/fedora-directory-users/2006-March/msg00071.html

with hosts that don't have reverse DNS. Tried the solution from 2006, but still no dice loading server info or logs via the web interface.
Comment 7 Rich Megginson 2012-04-05 14:24:32 EDT
(In reply to comment #6)
> Is this still broken in 389-ds-1.2.2? Still having the issues described here:
> 
> http://www.redhat.com/archives/fedora-directory-users/2006-March/msg00071.html
> 
> with hosts that don't have reverse DNS. Tried the solution from 2006, but still
> no dice loading server info or logs via the web interface.

What version of 389-admin are you using?  What is your platform?

Look for HostnameLookups in your /etc/dirsrv/admin-serv/console.conf
Comment 8 Albert Strasheim 2012-04-06 00:06:49 EDT
It seems it's a hostname issue.

If I access the server as http://primaryhostname:9830, it works.

If I access it using another hostname, the web interface returns errors as described below.

Thanks.

Long bunch of extra stuff I wrote before figuring out the above:

I am running 389-ds-base-1.2.10.4-2.fc16.x86_64 with 389-admin-1.1.23-1.fc16.x86_64 on Fedora 16 x86_64.

HostnameLookups is off in /etc/dirsrv/admin-serv/console.conf

I can admin the server using 389-console running on the same machine as the server using http://127.0.0.1:9830 and the http://serverip:9830 as the Admin URL.

However, if I access the web interface using a browser at http://secondaryhostname:9830/admin-serv/tasks/configuration/HTMLAdmin?op=index and click any  link (Replication Status, Server Info, etc.) I get an Apache error page:

Authorization Required

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

[notice] [client 1.2.3.4] admserv_host_ip_check: ap_get_remote_host could not resolve 1.2.3.4
[warn] [client 1.2.3.4] admserv_host_ip_check: failed to get host by ip addr [1.2.3.4] - check your host and DNS configuration

I did the

replace: nsAdminAccessAddresses
nsAdminAccessAddresses: *
replace: nsAdminAccessHosts
nsAdminAccessHosts: *

as per http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt

I also set

configuration.nsadminaccesshosts: *
configuration.nsadminaccessaddresses: *

in /etc/dirsrv/admin-serv/local.conf.

Note You need to log in before you can comment on or make changes to this bug.