[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLWr8+GpGG+geibKQqPxGHtPQbzYjEptjA4r+jNcRrMWvw@mail.gmail.com>
Date: Thu, 15 Dec 2016 16:31:40 -0800
From: John Stultz <john.stultz@...aro.org>
To: Casey Schaufler <casey@...aufler-ca.com>
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 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.
thanks
-john
Powered by blists - more mailing lists