Bug 74485 - Existing semaphore (0) is modified at Apache 1.3.23-14 startup
Summary: Existing semaphore (0) is modified at Apache 1.3.23-14 startup
Keywords:
Status: CLOSED DUPLICATE of bug 74496
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apache
Version: 7.3
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On: 74496
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-25 06:42 UTC by Dave Kelly
Modified: 2007-04-18 16:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-09-29 08:09:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Dave Kelly 2002-09-25 06:42:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

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);

}

Comment 1 Joe Orton 2002-12-03 09:51:15 UTC

*** This bug has been marked as a duplicate of 74496 ***


Note You need to log in before you can comment on or make changes to this bug.