From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423866AbcBQW3c (ORCPT ); Wed, 17 Feb 2016 17:29:32 -0500 Received: from mail-yw0-f172.google.com ([209.85.161.172]:34711 "EHLO mail-yw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423585AbcBQW3a (ORCPT ); Wed, 17 Feb 2016 17:29:30 -0500 MIME-Version: 1.0 In-Reply-To: <20160217121813.8a49986ebf66cedaf43e901b@linux-foundation.org> References: <1455671191-32105-1-git-send-email-john.stultz@linaro.org> <1455671191-32105-3-git-send-email-john.stultz@linaro.org> <20160217113547.6487174b9c6d365927095080@linux-foundation.org> <20160217121813.8a49986ebf66cedaf43e901b@linux-foundation.org> Date: Wed, 17 Feb 2016 14:29:29 -0800 Message-ID: Subject: Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface From: John Stultz To: Andrew Morton Cc: Kees Cook , Thomas Gleixner , Arjan van de Ven , lkml , Oren Laadan , Ruchi Kandoi , Rom Lemarchand , Android Kernel Team Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2016 at 12:18 PM, Andrew Morton wrote: > On Wed, 17 Feb 2016 12:09:08 -0800 Kees Cook wrote: >> On Wed, Feb 17, 2016 at 11:35 AM, Andrew Morton >> > The procfs file's permissions are 0644, yes? So a process's >> > timer_slack is world-readable? hm. >> >> This should be 600, IMO. > > Sounds safer. So I've gone ahead and addressed this and the other feedback you had. But this bit made me realize that I may have missed a key aspect to the interface that Android needs. In particular, the whole point here is to allow a controlling task to modify other tasks' timerslack to limit background tasks' power usage (and to modify them back to normal when the background tasks become foreground tasks). Note that on android different tasks run as different users. Currently, the controlling process has minimally elevated privileges (CAP_SYS_NICE). The initial review suggested those privileges should be higher (PTRACE_MODE_ATTACH), which I've implemented. However, I'm realizing that by moving to the proc interface, the filesystem permissions here put yet another barrier in the way. While the 600 permissions makes initial sense, it does limit these controlling tasks with extra privileges (though not root) from modifying the timerslack, since they cannot open the file to begin with. So.... Does world writable (plus the PTRACE_MODE_ATTACH_FSCREDS check) make more sense here? Or is there a better way for a system to tweak the default permissions for procfs entries? (And if so, does that render the PTRACE_MODE_ATTACH... check unnecessary?). Apologies. I'm fighting a head-cold, so I'm not feeling particularly sharp here. thanks -john