lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 25 Dec 2008 08:52:07 +0100 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: dhaval@...ux.vnet.ibm.com, kaber@...sh.net, mingo@...e.hu, linux-kernel@...r.kernel.org, bharata@...ux.vnet.ibm.com, vatsa@...ux.vnet.ibm.com, balbir@...ibm.com Subject: Re: asterisk hangs with RT priority On Thu, 2008-12-25 at 09:07 +1100, Herbert Xu wrote: > Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote: > > > > So you have uid-group scheduling and RT-group scheduling enabled (a > > feature that's experimental for real and has never been enabled by > > default), looking at the sys_setuid() code, the real uid change is done > > by switch_uid() and that doesn't have a failable scheduler hook. > > An experimental marking is no excuse for being broken. True, and we strive to fix them -- so thanks for finding this one. > > The thing is, I suspect the uid you switch to doesn't have a RT runtime > > quota configured, therefore the RT task that gets placed in it by > > switch_uid() doesn't get to run. > > > > [ Please read Documentation/scheduler/sched-rt-group.txt > > when you enable RT group scheduling ] > > This seems broken to me. The only way for a process to get into > RR mode is if it had been set by someone with the right privileges > or if it was inherited from its parent. > > So having a default where such a process stops executing altogether > after performing a setuid is wrong. True, therefore the setuid must fail. > The default should be to give each user a non-zero allotment. That's sadly impossible. The thing is, you cannot over-commit this time -- nor change an active configuration. So the only possibility left is a default of 0. > > The correct thing would be for switch_uid() (or set_user) to fail with > > -EINVAL, much like cpu_cgroup_can_attach() currently does for cgroup > > grouping. > > > > After that it demonstrates a bug in your test program, which fails to > > check errors ;-) > > Well the program which this was based on, asterisk does check for > errors on setuid. However, even if setuid did return an error this > isn't much better than the status quo since the user will be left > with the question "why on earth is asterisk failing on setuid?". Maybe a more descriptive error like -ENOTIME ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists