DO NOT REPLY [Bug 12987] New: - Existing semaphore (0) is modified

[bu...@apache.org]

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=12987>.
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=12987

Existing semaphore (0) is modified

           Summary: Existing semaphore (0) is modified
           Product: Apache httpd-1.3
           Version: 1.3.23
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: dave.kelly@samsungcontact.com


Description of problem:
When my Linux server boots up, my application (Samsung Contact) is started 
first. This creates 2 semaphores with id=0 and id=32769.

When Apache starts up, it changes the permissions on semaphore 0 from 
666 to 600 and ownership from openmail to apache. This causes errors to be 
generated within Samsung Contact because a daemon can no longer operate on the 
semaphore it created.

If Samsung Contact is stopped and restarted, it's semaphores are created with 
non-zero ids and subsequent restarts of Apache do not cause a problem.

A strace on /usr/sbin/httpd shows that there are 3 calls to semctl to change 
the ownership. However, within the strace, there are only ever 2 semgets. 
Somehow, the daemon is also calling semctl on semaphore 0.

Trying to track this down with the 1.3.23-14 source RPM, there is no code that 
matches the behaviour seen in the strace.

There are 2 calls to semctl for each semid: 1 to with IPC_STAT and 1 with 
IP_SET where the permissions and ownership are changed.

There are calls to semctl in http_main.c but they do not match up with the 
strace output.

Attempting to compile the source with debugging symbols turned on does not seem 
to reproduce the problem. (Help would be appreciated on enabling debugging 
successfully :-) )

Compiling the source from the SRPM, will reproduce the problem.

We are also seeing that after Apache has been shut down, the semaphores it 
created are being left.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1) Stop Apache or boot up without Apache running.
2) Create a semaphore using the attached C program. If this is run just after 
boot up, it should have id 0. If not, modify the program so that semid=0 when 
the call to semctl with IPC_SET is made.
3) Run ipcs -s to confirm the permissions and ownership.
4) Start up Apache.
5) Run ipcs -s to see that the permissions and ownership of semaphore 0 have 
changed.
	

Expected Results:  Apache should not be "stomping" over an existing semaphore.

Additional info:

#include <stdio.h>
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>

#if defined(__GNU_LIBRARY__) && !defined(_SEM_SEMUN_UNDEFINED)
	/* union semun is defined by including <sys/sem.h> */
#else
	/* according to X/OPEN we have to define it ourselves */
union semun {
	int val;                  /* value for SETVAL */
	struct semid_ds *buf;     /* buffer for IPC_STAT, IPC_SET */
	unsigned short *array;    /* array for GETALL, SETALL */
	/* Linux specific part: */
	struct seminfo *__buf;    /* buffer for IPC_INFO */
};
#endif

int main(int argc, char *argv[])
{
		int semid;
		char c;
		union semun arg;
		struct semid_ds buf;

		semid = semget(IPC_PRIVATE, 1, IPC_CREAT | 0666);

		buf.sem_perm.uid = 100;
		buf.sem_perm.gid = 11;
		arg.buf = &buf;
		semctl(semid, 1, IPC_SET, arg);

//		semctl(semid, 1, IPC_RMID);

		exit(0);

}

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org