Re: [RFC] capabilities: Ambient capabilities

[Andrew G. Morgan]

On Sat, Mar 14, 2015 at 3:55 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> It occurs to me that my previous reply was unnecessarily long and
> missed the point.  Trying again:
>
> On Sat, Mar 14, 2015 at 3:17 PM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote:
>> On Sat, Mar 14, 2015 at 2:45 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> On Sat, Mar 14, 2015 at 2:09 PM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote:
>>>> My Nack remains that you are eliminating the explicit enforcement of
>>>> selective inheritance. A lockable secure bit protecting access to your
>>>> prctl() function would address this concern.
>>>
>>> Would a sysctl or securebit that *optionally* allows pA to be disabled
>>> satisfy you?
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It would be kind of nice to remove your nack.  I think that the above
> is the relevant question.  Could you answer it?

I thought I did. Please implement a lockable secure bit and I will
remove my Nack.

I don't understand your confusion. Perhaps you are defining
*optionally* in a way I don't follow? Perhaps you are saying that you
want the default behavior of kernels to change to include your new
feature, and that you want the secure bit, when set, would put it into
pA suppressed mode?

Other folk are probably better at anticipating the ramifications of
changing default behavior. I'd prefer you default to pA being off, but
I shall remove my Nack either way if you implement a lockable secure
bit.

Clear enough?

Thanks

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/