The scenario is: 1) sudo starts and sets up a signal handler for SIGCHLD 2) pam modules gets loaded 3) Go gets initialized and sets the SA_ONSTACK flag specifically by calling rt_sigaction with a pointer to the existing signal handler in *sa_handler * field*.* 4) Sudo initialized a new signal handler for SIGCHLD 5) After the command is run and SIGCHLD signal is received by a Go created thread instead of the parent sudo thread then it goes to the signal handler created in step 1.
I believe this is the current set of events happening. I can share a strace dump if it would help. On Monday, August 14, 2023 at 12:17:34 PM UTC-7 Ian Lance Taylor wrote: > On Mon, Aug 14, 2023 at 12:02 PM Chandrasekhar R <crama...@gmail.com> > wrote: > > > > My understanding currently is sudo sets up a signal handler in pre_exec > and another signal handler later on which is tied into its main event loop. > > Go gets initialized when the pre_exec signal handler is used and it adds > rt_sigaction(SIGCHLD..) with the SA_ONSTACK flag as mentioned here. > > Then after the sudo command (echo) gets executed, the SIGCHLD is > received by one of the go threads which then runs the pre_exec signal > handler which is the old and nonexistent signal handler. > > > > My approach is to block the Go threads from receiving the SIGCHLD signal > and thus not let the signal to be handled by the old signal handler. > > I don't quite understand the scenario you are describing. What > matters is the signal handler. When Go adds the SA_ONSTACK flag, it > doesn't change the signal handler. Which thread a signal is delivered > to does not affect which signal handler gets run. > > Ian > > > > On Friday, August 11, 2023 at 10:05:48 PM UTC-7 Ian Lance Taylor wrote: > >> > >> On Fri, Aug 11, 2023 at 11:51 AM Chandrasekhar R <crama...@gmail.com> > wrote: > >> > > >> > I am planning on using a pam module written in Go (specifically > https://github.com/uber/pam-ussh) . When I run a script which calls sudo > continuously with an echo command, I am noticing zombie/defunct processes > starting to pop up. > >> > > >> > On doing strace, I noticed that the SIGCHLD gets delivered to one of > the threads created when Go gets initialized (i.e. the shared object gets > loaded). > >> > > >> > I tried to add one level of indirection by having a separate C code > which creates a new thread, sets the signal mask to block SIGCHLD and then > use dlopen to open the shared object created using cgo. I am still facing > the same issue, is there any pointer on how to fix this issue? I think this > would be a wide issue across all PAM modules written using cgo. > >> > >> As far as I know the specific thread that receives a SIGCHLD signal is > >> fairly random. What matters is not the thread that receives the > >> signal, but the signal handler that is installed. Signal handlers are > >> process-wide. What signal handler is running when you get a SIGCHLD? > >> What signal handler do you expect to run? > >> > >> Ian > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7b395394-da12-4b19-9e07-5c8f7e91dcabn%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/216fb89f-ba9c-41e6-ba90-485b9174a0a5n%40googlegroups.com.
