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
> 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
> 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.
