[Mono-dev] [PATCH] mono-service bugs - please review

[Avery Pennarun]

Jörg Rosenkranz wrote:
> Avery wrote:
> > - mono-service can overwrite its lockfile if the lockfile isn't
> >   lockf'ed.  This seems to be what was originally intended, but didn't
> >   quite get implemented correctly.
>
> Did you have a look at bug #77340
> (https://bugzilla.novell.com/show_bug.cgi?id=MONO77340)? For me it
> looks like you are reopening this security hole with your patch.

Oh dear. Well, my patch definitely brings back that one.  I think the
right fix is to open the existing file, lockf, unlink, and then create
a new one O_CREAT|O_EXCL|O_NOFOLLOW.  In the event that a new file is
created in between unlink and create, just give up.  If it works,
close the original file and throw it away.  Keep the new file's handle
open to preserve the lockf until the program dies.  (Same as current
behaviour.)

Of course no sensible person should leave their lock files in /tmp in
production, but that's a separate question.  I can see why it's the
default.  Another reasonable default would be $PWD.

Then Jonathan Pryor wrote:
> The UnixSignal patch was committed to head earlier this week, and I just
> migrated mono-service to use UnixSignal and UnixSignal.WaitAny() instead
> of Stdlib.signal().  Consequently the polling code has been removed with
> extreme prejudice, and we now have wonderful select(2)-based sleeping
> care of UnixSignal.WaitAny().
>
> This change also adds support for SIGINT, treating it identically with
> SIGTERM.

Excellent, problem solved.  And mono services will now start and stop
much faster than Microsoft ones with their arbitrary delays :)

So I need to submit a new lockfile patch.  Any comments on the
UserInteractive stuff?  That's actually the part I'm most suspicious
that I did wrong.

Thanks,

Avery