OOM-killer prevention for master kdeinit process

[Lubos Lunak]

On Thursday 03 August 2006 11:52, Lubos Lunak wrote:
> On Thursday 03 August 2006 00:17, Dirk Mueller wrote:
> > On Wednesday, 2. August 2006 23:21, Lubos Lunak wrote:
> > However, what we have to ensure is that kdeinit itself, when launched via
> > start_kdeinit, does not process any command line arguments or config file
> > options that would cause it to launch code / processes directly without
> > dropping the OOM killing score. Thats a bit non trivial to achieve, given
> > the number of libraries kdeinit links against. Therefore, this helper is
> > really really hard to get right.
>
>  Actually, thinking more about it, it's perhaps rather simple simple to get
> right. Currently the situation is like this: You get OOM, your klauncher,
> kwin and who knows what else are more or less guaranteed to be killed ->
> kiss your KDE session good-bye. Since the helper would only set the
> adjustment to normal value and then immediately drop privileges, the only
> thing that could go wrong would be having some process with default oom_adj
> set to normal. Also, some unwanted launching of something from kdeinit with
> the adjustment inherited (even though I don't quite see how that could
> happen in practice) would just at worst result in a process that wouldn't
> get killed by the OOM-killer in the unlikely case it misbehaves, causing
> the OOM-killer go nuts - which is exactly what happens now. Or am I missing
> something?

 Ok, hopefully last try, either way. I'll probably go to hell one day for 
writing such hacks. Based on http://www.lst.de/~okir/blackhats/node120.html 
the start_kdeinit setuid wrapper sets up the protection, creates a pipe, 
forks, drop privileges and execs kdeinit. The child keeps privileges. Kdeinit 
after each fork sends the new pid using the pipe and sigstops itself, the 
child resets the protection and sigconts the pid.

 The only things done as root are sprintf() with a number, 
open()/write()/close() of the /proc file, pipe(), reading from the pipe char 
by char, atol() and kill(). No C++ involved, nobody else can write to the 
pipe than kdeinit, which only writes getpid() there.  Should be perfectly 
safe (fingers crossed ;) ).

 Any objections to commit?

 BTW, does somebody have any idea what's the point of safe_argv in kdeinit?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kinit.patch
Type: text/x-diff
Size: 8659 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060804/6a937f2b/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: startkde.patch
Type: text/x-diff
Size: 509 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060804/6a937f2b/attachment-0001.patch>