Hi Detlev,
I really thank you for your reply. Yes you are absolutely right about
signal problems. And
I share the same idea with you but I do not have chance to change that
module. I did not approved
that signal based timer mechanism, but that module already developed
before my project.
In fact, timer module knows the originator pid of the process. But the
problem is such that when the timer
expires, it is not guarantee that kernel is in the originator process'es
context. So "current" can be a different
process with a different uid. Is there a way for timer module to handle
this ?
I am really tired nowadays. So I did not think a bad side effect for
disabling uid check for signal deliveration,
but when you said "any user can kill an application started by the
superuser", I said aha, that is the reason.
Thank you very much
I.yi çal?s,malar ...
_lvnd_
(^_^)
On 28.10.2010 18:35, Detlev Zundel wrote:
Hi Levend,
We have a ppc 852 based embedded board. We are running 2.4.25
kernel. We implemented a kernel module
for timer mechanism. A process can set a timer with this module and
when that timer expires module notifies the process with an RT signal.
Not that I want to criticize what you did, but I am not a big friend of
signals. I've seen way too many problems connected with them and try to
circumvent them whenever possible.
Just for your information - in Linux 2.6 the kernel developers have
solved the same "problem" by introducing timerfd's [1] which fit the
regular (synchronous) "select/poll" methodology of Unix much nicer than
(asynchronous) signals do.
Until today, we had just "root" user. But a few weeks ago
we added a web server application (hiawatha) that runs with "nobody"
user. So we added "nobody" user also.
Later we noticed that some signals sent from kernel to userland are
missing. The reason is this.
process A with uid root
process B with uid nobody
kernel module M
process A sets a timer with module M.
While B is running, timer expires and module M want to send signal to A.
But M uses send_sig_info (kernel/signal.c). That function makes some
permission checks (bad_signal). It checks euid of "current" with euid
of signal destination process.
If these are different, it does not deliver signal.
Ouch, it seems like your kernel module has a serious problem. When the
signal is delivered from "the process running at the time the timer goes
off", then the behaviour is essentially non-deterministic. One fix
would be to somehow remember the pid of the process that created the
timer and use that as the "originator" of the signal. Note that this is
only theory and I do _not_ know how to code that.
So as a remedy, we bypassed bad_signal code. Do you think will this
have some bad side effects ? Or do you suggest a better solution ?
Of course this will have bad side effects - this means that any user can
kill an application started by the superuser. Now this may not be
critical for your embedded system (if you don;t have any actual users),
but in general this is a no-go. It was for good reason that there were
checks in the code ;)
Cheers
Detlev
[1] http://www.kernel.org/doc/man-pages/online/pages/man2/timerfd_create.2.html
_______________________________________________
eldk mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/eldk
