This is normal. This is how Unix works. Whether its a good idea is more
complex
> Consider user running passwd, waiting to just right moment, and then
> killing passwd with SIGKILL (which it can not block). There even was
That is harmless. passwd uses rename() as it must be atomic. The off switch
and sigkill are not dissimilar issues.
> talk about that on bugtraq: they used it to simulate flood ping
> without needing uid==0:
>
> while [ true ]; do killall -14 ping; done
Thats irrelevant. Run 20 pings and send them sigkill and keep respawning them
or do UDP flooding
> BSD solved by only allowing you to send certain signals (that
> generated from keyboard) to programs with different euid but same real
> uid.
It doesnt work. I can still generate SIGIO arbitarily for one. Work out what
you are trying to achieve first of all. If it is to provide totally safe
areas of code then you are probably doing the wrong thing, hardware and
off switches must be allowed for.
Various people have bounced around some ideas. There is certainly a possible
case for a sigblockmask for signals from setuid tasks. However it is nothing
like as trivial an argument as it may appear from random bits of bugtraq.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu