[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1504241424330.11285@gentwo.org>
Date: Fri, 24 Apr 2015 14:25:46 -0500 (CDT)
From: Christoph Lameter <cl@...ux.com>
To: Serge Hallyn <serge.hallyn@...ntu.com>
cc: Andy Lutomirski <luto@...capital.net>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Andrew Lutomirski <luto@...nel.org>, Ted Ts'o <tytso@....edu>,
Andrew Morton <akpm@...uxfoundation.org>,
"Andrew G. Morgan" <morgan@...nel.org>,
Linux API <linux-api@...r.kernel.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Michael Kerrisk <mtk.manpages@...il.com>,
Austin S Hemmelgarn <ahferroin7@...il.com>,
linux-security-module <linux-security-module@...r.kernel.org>,
Aaron Jones <aaronmdjones@...il.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
LKML <linux-kernel@...r.kernel.org>,
Markku Savela <msa@...h.iki.fi>,
Kees Cook <keescook@...omium.org>,
Jonathan Corbet <corbet@....net>
Subject: Re: [RFC] capabilities: Ambient capabilities
On Fri, 24 Apr 2015, Serge Hallyn wrote:
> > I object because CAP_SETPCAP is very powerful whereas
> > CAP_NET_BIND_SERVICE, for example, isn't. I'm fine with having a
> > switch to turn off ambient caps, but requiring the "on" state to give
>
> Would only really be needed for the initial 'enable ambient caps for this
> process tree', though. Once that was set, add/remove'ing caps from the
> ambient set wouldn't need to be required.
Exactly. Its much simpler than alternate approaches. And its convoluted
enough.
--
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