From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Description of problem: The DN of the authenticated user in access_log contain spaces which can cause troubles on parsing through analog and other programs. Version-Release number of selected component (if applicable): mod_authz_ldap-0.22-5 How reproducible: Always Steps to Reproduce: 1. Setup mod_authz_ldap authentication 2. Authenticate as user Actual Results: access_log: 1.2.3.4 - cn=user, dc=subkey1,dc=subkey2,dc=subkey3,dc=subkey4,dc=de [08/Mar/2005:08:30:15 +0100] "GET /something.html HTTP/1.0" 304 - "" "" 596 298 See space between cn=user, dc=subkey1 ^ Expected Results: Escaped spaces or at least no spaces Additional info: I've got response from the mod_authz_ldap developer and told me, that currently no escape mechanism at all exists in mod_authz_ldap. The module put the value given from LDAP directory without any modification to the log. Even more funny things can happen, e.g. also " is allowed and unfiltered.
It's not clear what's the best thing to do about this. Does analog parse the logs OK if you change the LogFormat to double-quote the %u? Even if it does, quoting it by default could certainly confuse other programs which expect that field unquoted. In the RHEL4 httpd, at least the double-quotes and backslash characters will be escaped in the logged username.
Given that: 1) any change to the logfile format will require modifying log analysis tools anyway 2) the log analysis tools could use the '[' of the date field to delimit the username field to avoid the problem in the first place 3) in RHEL4 escaping of quotes and backslashes in the username field is easily possible I don't think it's appropriate to change anything here in RHEL3. Thanks for the report.