[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a6b5f38-de8e-d8d4-e6f7-feae3f8d192e@schaufler-ca.com>
Date: Thu, 15 Dec 2016 16:44:30 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: John Stultz <john.stultz@...aro.org>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
"Serge E. Hallyn" <serge@...lyn.com>,
James Morris <jmorris@...ei.org>,
Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...capital.net>,
Jann Horn <jann@...jh.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
linux-man <linux-man@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: capabilities(7): notes for kernel developers
On 12/15/2016 4:31 PM, John Stultz wrote:
> On Thu, Dec 15, 2016 at 12:40 PM, Casey Schaufler
> <casey@...aufler-ca.com> wrote:
>> On 12/15/2016 11:41 AM, Michael Kerrisk (man-pages) wrote:
>>> On 12/15/2016 05:29 PM, Casey Schaufler wrote:
>>>> CAP_WAKE_ALARM could readily be CAP_TIME.
>>> Actually, I don't quite understand what you mean with that sentence.
>>> Could you elaborate?
>> Should have said CAP_SYS_TIME
>>
>> Setting an alarm could be considered a time management function,
>> depending on what it actually does.
> Just a nit here. CAP_WAKE_ALARM is more about the privilege of waking
> a system from suspend, while CAP_SYS_TIME covers the ability to set
> the time. One wouldn't necessarily want to give applications which
> could wake a system up the capability to also set the time.
Doesn't really matter, except that an ignorant developer
might make the mistake I did and assume that WAKE_ALARM
was somehow related to time management. If you want to use
it as an example don't let my dunderheadedness get in your
way.
> thanks
> -john
Again, thank you for taking this on. It should be a
big help.
Powered by blists - more mailing lists