DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22955>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22955
unix based lock creation routines have a possible race issue
Summary: unix based lock creation routines have a possible race
issue
Product: Apache httpd-2.0
Version: 2.0.47
Platform: Sun
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Platform
AssignedTo: bugs@httpd.apache.org
ReportedBy: arvind_gopalan@yahoo.com
CC: arvind_gopalan@yahoo.com
In the code below, theres a small race window between when we do a semget and
when we try and set the mutex value to 1. Its possible for a different process
to prematurely call and succeed in the _acquire() in this window..
static apr_status_t proc_mutex_sysv_create(apr_proc_mutex_t *new_mutex,
const char *fname)
{
union semun ick;
apr_status_t rv;
new_mutex->interproc = apr_palloc(new_mutex->pool, sizeof(*new_mutex-
>interproc));
new_mutex->interproc->filedes = semget(IPC_PRIVATE, 1, IPC_CREAT | 0600);
if (new_mutex->interproc->filedes < 0) {
rv = errno;
proc_mutex_sysv_cleanup(new_mutex);
return rv;
}
ick.val = 1;
if (semctl(new_mutex->interproc->filedes, 0, SETVAL, ick) < 0) {
rv = errno;
proc_mutex_sysv_cleanup(new_mutex);
return rv;
}
new_mutex->curr_locked = 0;
apr_pool_cleanup_register(new_mutex->pool,
(void *)new_mutex, apr_proc_mutex_cleanup,
apr_pool_cleanup_null);
return APR_SUCCESS;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
|