directory secret2 works fine, secret1 gives following error in the log:
[Sun May 22 22:53:29 2005] [error] MySQL error You have an error in your SQL syntax. Check the manual t
hat corresponds to your MySQL server version for the right syntax to use near '... FROM ... WHERE ...='/C=.../L=.../...: /secret1
[Sun May 22 22:53:29 2005] [error] mysql user /C=.../L=.../O=.../CN=.../emailAddress=... failed authorization to access /secret1
Does anybody knows what I'm doing wrong and can help me? Thanks a lot.
--
dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure why secret1 would fail - your message seems to be relaed to parameters in the secret2 entry.
OTOH, your "require user" for secret2 is not valid. It can only be a list of user names which can access the resource. See the Apache documentation for more info on this statement.
I'm still not sure why you would get this problem, however. We don't use the contents from the require user statement in the mysql calls.
You aren't by any chance trying to use special characters (i.e. '=') in your user ids, are you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. The user name is just the Subject of the Client's X509 Certificate (can be determined by running OpenSSL's openssl x509 command: openssl x509 -noout -subject -in certificate.crt). Note that no password is obtained from the user. Every entry in the user file needs this password: ``xxj31ZMTZzkVA'', which is the DES-encrypted version of the word `password''. Those who live under MD5-based encryption (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5 hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's going to be difficult to determine the cause because we don't have the details - understandable because this is security related. But we'll do our best.
From the abbreviated messages, it looks like your problem may be the userid. You indicate it contains special chars - which ones? The apostrophe would be especially important, since it is a delimiter to MySQL. Backslashes may also cause problems; others might but without knowing exactly which ones are in the string, we can't say for sure.
As for the Apache comment - this is true for Apache authorization modules. We attempt to duplicate this behavior as much as possible, but we are limited by MySQL, also - a constraint Apache doesn't have.
BTW - If the user in your secret2 directory is actually as presented, then it would be a valid (although unusual) user ID. But it it's the same user as in secret1, I would expect to see the same error.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apache/2.0.54 (Trustix Secure Linux/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7c PHP/4.3.11 mysql/4.0.24
httpd.conf:
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +StdEnvVars +FakeBasicAuth
<Directory /.../.../secret1>
AuthName xxxx
AuthType Basic
AuthMySQLHost localhost
AuthMySQLUser xxx
AuthMySQLPassword xxx
AuthMySQLDB xxx
AuthMySQLUserTable xxx
AuthMySQLNameField xxx
AuthMySQLPasswordField xxx
AuthMySQLGroupField xxx
AuthMySQLPwEncryption crypt
Require group betatester
AllowOverride None
</Directory>
<Directory /.../.../secret2>
AuthName ...
AuthType Basic
AuthMySQLHost localhost
AuthMySQLUser ...
AuthMySQLPassword ...
AuthMySQLDB ...
AuthMySQLUserTable ...
AuthMySQLNameField ...
AuthMySQLPasswordField ...
AuthMySQLGroupTable ...
AuthMySQLGroupField ...
AuthMySQLPwEncryption crypt
require user '/C=.../L=.../O=.../OU=.../CN=.../emailAddress=...'
AllowOverride None
</Directory>
directory secret2 works fine, secret1 gives following error in the log:
[Sun May 22 22:53:29 2005] [error] MySQL error You have an error in your SQL syntax. Check the manual t
hat corresponds to your MySQL server version for the right syntax to use near '... FROM ... WHERE ...='/C=.../L=.../...: /secret1
[Sun May 22 22:53:29 2005] [error] mysql user /C=.../L=.../O=.../CN=.../emailAddress=... failed authorization to access /secret1
Does anybody knows what I'm doing wrong and can help me? Thanks a lot.
--
dirk
Dirk,
I'm not sure why secret1 would fail - your message seems to be relaed to parameters in the secret2 entry.
OTOH, your "require user" for secret2 is not valid. It can only be a list of user names which can access the resource. See the Apache documentation for more info on this statement.
I'm still not sure why you would get this problem, however. We don't use the contents from the require user statement in the mysql calls.
You aren't by any chance trying to use special characters (i.e. '=') in your user ids, are you?
I use a certificate based authorization for the entire site:
SSLVerifyClient require
to control access for the secret areas I use:
SSLOptions +FakeBasicAuth
The AuthMySQLNameField contains the DN of the certificate:
/C=.../L=.../O=.../OU=.../CN=.../emailAddress=...
(the password is always the encrypted version of 'password'.)
This works fine with the secret2 directory:
The browser sends the DN and password automatically to the server and everything works like expected.
The group based authorization for the secret1 dir fails.
Yes I use special characters for the username (see above).
--
dirk
This is from the Apache doc:
FakeBasicAuth
When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. The user name is just the Subject of the Client's X509 Certificate (can be determined by running OpenSSL's openssl x509 command: openssl x509 -noout -subject -in certificate.crt). Note that no password is obtained from the user. Every entry in the user file needs this password: ``xxj31ZMTZzkVA'', which is the DES-encrypted version of the word `password''. Those who live under MD5-based encryption (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5 hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.
Hello, Dirk,
It's going to be difficult to determine the cause because we don't have the details - understandable because this is security related. But we'll do our best.
From the abbreviated messages, it looks like your problem may be the userid. You indicate it contains special chars - which ones? The apostrophe would be especially important, since it is a delimiter to MySQL. Backslashes may also cause problems; others might but without knowing exactly which ones are in the string, we can't say for sure.
As for the Apache comment - this is true for Apache authorization modules. We attempt to duplicate this behavior as much as possible, but we are limited by MySQL, also - a constraint Apache doesn't have.
BTW - If the user in your secret2 directory is actually as presented, then it would be a valid (although unusual) user ID. But it it's the same user as in secret1, I would expect to see the same error.
Jerry
Hi Jerry,
I found the mistake!
I used this:
AuthMySQLGroupField group
But 'group' is a reserved field in mysql!!!
So I changed it to
AuthMySQLGroupField user_group
Everything works fine now.
Thank you very much for your time.
--
Dirk
Dirk,
Ok, that makes sense. GROUP is a reserved word in SQL.
You probably could have gotten around the probem by surrounding it with back-tics, i.e.
`group`
MySQL uses this to indicate it is a table or column name instead of a keyword.
Jerry