Re: [go-nuts] cgo pam module signal handling

[Ian Lance Taylor]

On Mon, Aug 14, 2023 at 4:52 PM Chandrasekhar R  wrote:
>
> 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.

Thanks for the outline.  That series of events doesn't make sense to
me.  Signal handlers are process-wide.  When in step 4 sudo sets a
signal handler for SIGCHLD, that is the signal handler for all threads
in the process.  When in step 5 a SIGCHLD signal is received, it will
go to the signal handler installed in step 4, not the signal handler
installed in step 1.

Yes, an strace dump would help clarify this.  Thanks.

Ian


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

-- 
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/CAOyqgcXc77NmzV8q623MR-1nCm1_5UaO-7tOS5BDM9_%2BX381Qw%40mail.gmail.com.

Re: [go-nuts] cgo pam module signal handling

[Chandrasekhar R]

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.

Re: [go-nuts] cgo pam module signal handling

[Ian Lance Taylor]

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+unsubscr...@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/CAOyqgcWhtpjyXALJoMFVjVWkfA4kntsxjKbK-LJxoSzJ9z%2BLAw%40mail.gmail.com.

Re: [go-nuts] cgo pam module signal handling

[Chandrasekhar R]

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.

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+unsubscr...@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.

Re: [go-nuts] cgo pam module signal handling

[Ian Lance Taylor]

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVEwqeoRZ9LLvErxC0rkFcRa9UUYbHSFawDoc%3DuhmTsRA%40mail.gmail.com.

[go-nuts] cgo pam module signal handling

[Chandrasekhar R]

Hey community,

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.

-- 
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/564ad353-885e-4662-8ac6-f15d41771a64n%40googlegroups.com.