This is the mail archive of the
mailing list for the Cygwin project.
Re: signal semaphores inheritance
On Wed, Feb 21, 2001 at 02:40:30PM +0300, Egor Duda wrote:
>Wednesday, 21 February, 2001 Corinna Vinschen email@example.com wrote:
>>> >> if ntsec is on and cygwin app a.exe (with pid x) starts non-cygwin
>>> >> app b.exe, b.exe inherits cygwin1S3.sigcatch.x semaphore. if a.exe
>>> >> dies and b.exe continue execution, and if new cygwin app c.exe
>>> >> got pid x it, fails to create sigcatch semaphore. looks like typo in
>>> >> getsem() to me. is this patch ok?
>>> CV> Did you check it with apps chenging the user context? AFAIR I had
>>> CV> a reason using an inheritable SD...
>>> hmm. i haven't noticed any differences. i may have missed something,
>>> though. but, if this handle is supposed to be inheritable, shouldn't
>>> it be DuplicateHandle()'d in child process? I've grepped through
>>> sources and haven't find any DuplicateHandle() used on semaphores. so
>>> even if this handle is made inheritable, i don't see the place
>>> where child is using it.
>CV> Please don't misunderstand me. I'm asking that question because I'm
>CV> really unsure why this is an inheritable SD and I only remember (in
>CV> the deepest corner of my brain) that there might have been _some_ issue
>CV> to do it that way but my alzheimer disease is getting worse...
>CV> If you have tested the patch with using telnet or ssh to actually
>CV> change the user context and an `id' results in the correct identity
>CV> and the permissions seem to be ok then I have no problem with your patch.
>i've tested it in several simple scenarios, and it seems to work.
>user context is changed, id shows correct info, and i can send SIGINT
>to process run under sshd via pressing Ctrl-C.
Knowing how signals work, I can't imagine a scenario where inheriting the
semaphore would be useful. I think that Egor's patch is correct.