[SOLVED] Is there any way to stop a user from invoking his own signal

[kingsmasher1]

Hi All,

My requirement is: I have a signal handler in my tool, which is registered and used between some particular interval (i am using timer).

Now this signal handler should NOT allow any other handler to be registered or invoked after this handler is once registered. (But this restriction is only for a short duration, means after that duration the user is free to invoke his own handler)Is there any way to accomplish this?

enter code here  struct itimerspec its; 
sigset_t mask;  
struct sigaction sa;  
printf("Establishing handler for signal %d\n", SIG);  
sa.sa_flags = SA_SIGINFO;  

sa.sa_sigaction = handler; // This handler should override all handlers  and prevent a user from invoking his own handler.

sigaction(SIG, &sa, NULL);  
sev.sigev_notify = SIGEV_SIGNAL;  sev.sigev_signo = SIGUSR1;

[Rubberman]

You mask out other signals on entry to your code, and unmask them afterward. Even if they are registered (you can't stop that), they will not be invoked until after you restore the mask. However, they are only masked while inside your own signal handler. You cannot do anything about signal registration, unless you were to re-implement the signal registration code itself.

[kingsmasher1]

You mask out other signals on entry to your code, and unmask them afterward. Even if they are registered (you can't stop that), they will not be invoked until after you restore the mask. However, they are only masked while inside your own signal handler. You cannot do anything about signal registration, unless you were to re-implement the signal registration code itself.

Thanks for the reply Rubberman.
My timer invokes SIGUSR1, for which i have a handler, inside that handler there is also a "flag", which is set once the timer expires (in other words the SIGUSR1) generated by timer expiration is received.

So my problem is, if the test program (which is linked to my tool), tries to register a new handler for the same signal, that used by my timer (SIGUSR1 in this case), then my original handler is never reached on timer expiration.

The same can happen indeed for any signal which my POSIX timer may use.
This is my problem. No way to resolve this?

[Rubberman]

As long as the other code is linked with your tool code, then there is no way to avoid this, AFAIK. Documentation should be made that tells the user developer that the SIGUSR1 signal is reserved for the tool's purposes, and use of it will result in "undesirable behavior"...

As someone, somewhere once said, there is no cure for sheer stupidity, but you can at least make sure that it isn't yours...

[kingsmasher1]

As long as the other code is linked with your tool code, then there is no way to avoid this, AFAIK. Documentation should be made that tells the user developer that the SIGUSR1 signal is reserved for the tool's purposes, and use of it will result in "undesirable behavior"...

As someone, somewhere once said, there is no cure for sheer stupidity, but you can at least make sure that it isn't yours...

@Rubberman: I thought i would get this idea from you

Infact, it can be done, here it is how:
This can be achieved, and in fact i have done that by writing a sigaction wrapper around the actual one, and using the dlsym and RTLD_NEXT technique.

Here is the code snippet of my wrapper

#define LT_SIGACTION (*lt_sigaction)
// The handle obtained from dlsym will be stored in lt_sigaction.

int sigaction(int sig, const struct sigaction *act, struct sigaction *oact)
{

 struct sigaction sa;
 printf("My sigaction called\n");

 if(sig==SIGUSR1)
 {
  temp_act=act; temp_old=oact; // user's variables stored for later restoration of his handler
  }
 if((Timerflag==1)&&(sig==SIGUSR1))
 {

   sa.sa_sigaction=my_handler;
   sa.sa_flags=0;
   return LT_SIGACTION(sig,&sa,NULL);

  }
 else if(Timerflag==0)
   return LT_SIGACTION(sig, act, oact);

}

Finally, i think everyone knows, how to get the libc handle using dlsym technique

Now, what do you say, Rubberman???

[Rubberman]

Clever, and a hat-tip to you Kingsmasher!

P.S. I presume you have tested this approach?

[kingsmasher1]

Clever, and a hat-tip to you Kingsmasher!

P.S. I presume you have tested this approach?

Thank you Rubberman
Yes, i have tested it.