On Mon, Jan 25, 1999, Jake Buchholz wrote:
> When ssl_scache.{pag,dir} get initially created, they're owned to root,
> instead of the eventual UID that apache's running as... Which means, I
> get a lot of engine messages about the fact that it can't open the DBM
> file for writing, and renders the cache pretty much useless... If I
> chown it to the right UID, all is well.
Hmmm.. which version of mod_ssl is it?
Actually in ssl_engine_scache.c at line 227 you can find this piece of code I
wrote to overcome the child-process problem:
| #ifndef WIN32
| /*
| * we have to make sure the Apache child processes
| * have access to the DBM file...
| */
| if (geteuid() == 0 /* is superuser */) {
| chown(mc->szSessionCacheDataFile,
| ap_user_id, -1 /* no gid change */);
| chown(ap_pstrcat(p, mc->szSessionCacheDataFile,
| SSL_DBM_FILE_SUFFIX_DIR, NULL),
| ap_user_id, -1 /* no gid change */);
| chown(ap_pstrcat(p, mc->szSessionCacheDataFile,
| SSL_DBM_FILE_SUFFIX_PAG, NULL),
| ap_user_id, -1 /* no gid change */);
| }
| #endif
Seems like either the SSL_DBM_FILE_SUFFIX_{DIR,PAG} macros are incorrectly
determined on your platform, or the ap_user_id contains "root" (check your
User/Group directives) or geteuid() doesn't return 0 for your situation. Can
you find out more?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
