[sudo-workers] SIGINT signal before exec
michael at felt.demon.nl
Thu Feb 2 11:19:35 MST 2017
On 02/02/2017 00:19, Aurélien Rausch wrote:
> I'm developping a PAM module for sudo and I would like to be able to catch the
> SIGINT signal from the shell (Ctrl-c) before exec. (Because my module can take
> some time to end)
My 'guess' in this - as you should take it as implementation dependent -
is that signal() is limited to processes with the same euid as the
process that receives the signal. SU powers permits to send a signal()
to any process regardless of the process sense of euid.
> I know some suid authentication apps block signals (like 'su', user can't
> Ctrl-c during the password prompt), as it seems the case in sudo (after
> password prompt and until command exec).
> I have tried to unblock the SIGINT signal from my module, but it doesn't seem
> to work. If I understood properly, sudo block signals sent by the kernel ?
> (When app is running or before too ?) How I can unblock (and reset after use)
> these signals ?
My time for playing with signals pre-dates system5 (i.e., I was using
UNIX v7 - with fewer than 64 system calls compared to the thousands
these days, in other words - system calls were powerful and versatile.
Things that are now system calls were in libc. I mention this as may
'proto-code' may not look like clean 'current syntax'
a) get and save current signal behavior
b) make sure my routine can call that (at it's end)
c) set my new "handler"
d) wait for signal to occur, if ever
> What I have tried for the moment: (simplified code)
What I would try - is to use sudo "kill SIGINT processid" and see if it
gets caught. If it does, then your signal handling is correct - and the
issue is getting the proper authentification, better priviledge, to send
SIGINT to a process "you" do not own.
> sigset_t sigmask;
> struct sigaction sa;
> sa.sa_flags = 0;
> sa.sa_handler = sigint_handler;
> sigaddset(&sigmask, SIGINT);
> sigprocmask(SIG_UNBLOCK, &sigmask, NULL);
> sigaction(SIGINT, &sa, NULL);
> sudo-workers mailing list <sudo-workers at sudo.ws>
> For list information, options, or to unsubscribe, visit:
More information about the sudo-workers