| 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
| ||
|
Message-ID: <alpine.DEB.2.00.0907271739230.29815@chino.kir.corp.google.com> Date: Mon, 27 Jul 2009 17:45:01 -0700 (PDT) From: David Rientjes <rientjes@...gle.com> To: Paul Menage <menage@...gle.com> cc: Andrew Morton <akpm@...ux-foundation.org>, Rik van Riel <riel@...hat.com>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, linux-kernel@...r.kernel.org Subject: Re: [patch -mmotm] mm: introduce oom_adj_child On Mon, 27 Jul 2009, Paul Menage wrote: > > Ok, we can allow oom_adj_child to be less than oom_adj for > > CAP_SYS_RESOURCE. > > Sounds fine to me, since you already need CAP_SYS_RESOURCE to set > oom_adj anyway. But actually, shouldn't you just be requiring > CAP_SYS_RESOURCE to set oom_adj_child at all? > Tasks can elevate their own oom_adj value without that capability. > Otherwise an unprivileged process that starts with oom_adj=0 could set > its oom_adj_child value to something slightly less immune than its > oom_adj, say 1; then even if the sysadmin sets if oom_adj value to > very non-immune, it would still be able to create children with > oom_adj 1. > Perhaps we should simply always change oom_adj_child to match oom_adj when oom_adj changes? oom_adj_child could then change, but only more immune if CAP_SYS_RESOURCE. -- 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