[CVS] pidfile support
Rob Siemborski
rjs3 at andrew.cmu.edu
Mon Dec 16 11:22:36 EST 2002
On Sun, 15 Dec 2002, Henrique de Moraes Holschuh wrote:
> 1. There is no support for updating the pidfile. Thus, the lock is acquired
> only after forking, which means we lost the controlling terminal by the time
> we can complain about not being able to acquire a lock, and that we have
> already tried to go daemon and thus whatever is trying to start master is
> NOT told that we failed.
I don't think you can fix this in a perfect way, giving unix locking
semantics (well, atleast fcntl).
This is using the code from the original patch:
http://bugzilla.andrew.cmu.edu/attachment.cgi?id=93&action=view
[A] lock and write pidfile
[A] fork and create [B] (which doesn't hold a lock on the file)
[B] attempt to reacquire lock on pidfile, FAIL since A doesn't have it
[A] exit(success)
[B] exit(failure)
The parent to A thinks we successfully finished, when in reality we've
stepped on our own feet.
I've experementally verified that this is actually a problem in theory
(if not in practice).
I don't think the BSD flock() semantics even help us here (hold lock
across fork() but any close() will get rid of the lock), since then we
have:
[A] lock and write the pidfile
[A] fork and create [B] (which shares the lock with [A])
[A] exit(success), which closes the file descriptor and releases the lock
[C] start a master process, lock and write the pidfile
[B] attempt to reacquire lock, and fail because [C] has the lock
(I'll note that I haven't experementally verified this sequence)
Now we've exited in failure, and not reported so to our parent.
But, I think this might be less of an issue than the first, since master
still starts successfully in the end (though, perhaps with a different
config file?)
I'm willing to listen to suggestions.
> 2. Close on exec is not being set on the pidfile. Right now, this is not
> a bug. However, should we forget a close(pidfile) anywhere, it could
> somehow be the part of a bigger security hole...
This is doable I suppose.
-Rob
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
More information about the Info-cyrus
mailing list