From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82AC5C5DF60 for ; Tue, 5 Nov 2019 16:56:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38F1B21928 for ; Tue, 5 Nov 2019 16:56:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="X5GLbJc8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38F1B21928 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D3AAA6B000C; Tue, 5 Nov 2019 11:56:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CEA6F6B000D; Tue, 5 Nov 2019 11:56:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFFC06B000E; Tue, 5 Nov 2019 11:56:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id A88BB6B000C for ; Tue, 5 Nov 2019 11:56:04 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 68D75181AC9CC for ; Tue, 5 Nov 2019 16:56:04 +0000 (UTC) X-FDA: 76122826248.05.title19_8c340c29bcd34 X-HE-Tag: title19_8c340c29bcd34 X-Filterd-Recvd-Size: 4062 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Nov 2019 16:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572972963; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6/CYal2Ht1Wk+CkyE9G0+kWfB1JTDB8P2q0I4iMUmUk=; b=X5GLbJc87sD0Sj1XQzotQR5Ss6SN7U4lrHzs1FaHl60hZFAwAz68MirRp2yJ5uYYDUe8R4 zUqP5aTbNTJZhFmRd83wZLkwSsnKaOb8d8QEyCbe6lJoW8dq3uAuVxyknB7/HNumrNShmr TC+0zTy6X5dL9UiPbUZ0Of/v1FGzJ84= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-264-fND83D8KND2PRYRlMZm3mw-1; Tue, 05 Nov 2019 11:55:59 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C4106107ACC3; Tue, 5 Nov 2019 16:55:57 +0000 (UTC) Received: from mail (ovpn-121-157.rdu2.redhat.com [10.10.121.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9AAD827065; Tue, 5 Nov 2019 16:55:57 +0000 (UTC) Date: Tue, 5 Nov 2019 11:55:56 -0500 From: Andrea Arcangeli To: Daniel Colascione Cc: Andy Lutomirski , Mike Rapoport , linux-kernel , Andrew Morton , Jann Horn , Linus Torvalds , Lokesh Gidra , Nick Kralevich , Nosh Minwalla , Pavel Emelyanov , Tim Murray , Linux API , linux-mm Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK Message-ID: <20191105165556.GK30717@redhat.com> References: <1572967777-8812-1-git-send-email-rppt@linux.ibm.com> <1572967777-8812-2-git-send-email-rppt@linux.ibm.com> <20191105163316.GI30717@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: fND83D8KND2PRYRlMZm3mw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 05, 2019 at 08:39:26AM -0800, Daniel Colascione wrote: > I'm not suggesting that we fail userfaultfd(2) without CAP_SYS_PTRACE. > That would, as you point out, break things. I'm talking about > recording *whether* we had CAP_SYS_PTRACE in an internal flag in the > uffd context when we create the thing --- and then, at ioctl time, > checking that flag, not the caller's CAP_SYS_PTRACE, to see whether > UFFD_FEATURE_EVENT_FORK should be made available. This way, the > security check hinges on whether the caller *at create time* was > privileged. Until now it wasn't clear to me you still wanted to do the permission check in UFFDIO_API time, and you only intended to move the "measurement" of the capability to the syscall. So you're suggesting to add more kernel complexity to code pending for removal to achieve a theoretically more pure solution in the band-aid required to defer the removal of the posix-breaking read implementation of the uffd fork feature?