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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 145DEC43334 for ; Tue, 14 Jun 2022 04:44:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 852388D0207; Tue, 14 Jun 2022 00:44:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78FC28D020D; Tue, 14 Jun 2022 00:44:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E14A8D0207; Tue, 14 Jun 2022 00:44:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3F02E8D0207 for ; Tue, 14 Jun 2022 00:44:39 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1324032E7A for ; Tue, 14 Jun 2022 04:44:39 +0000 (UTC) X-FDA: 79575600678.01.3D8DD9D Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf20.hostedemail.com (Postfix) with ESMTP id 5A4031C0080; Tue, 14 Jun 2022 04:44:38 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]:60056) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1o0yPs-002t3o-D4; Mon, 13 Jun 2022 22:44:36 -0600 Received: from ip68-227-174-4.om.om.cox.net ([68.227.174.4]:40374 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1o0yPr-008Y07-9H; Mon, 13 Jun 2022 22:44:36 -0600 From: "Eric W. Biederman" To: Frederick Lawler Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-security-module@vger.kernel.org, netdev@vger.kernel.org, keyrings@vger.kernel.org, selinux@vger.kernel.org, serge@hallyn.com, amir73il@gmail.com, kernel-team@cloudflare.com, Jeff Moyer , Paul Moore References: <20220608150942.776446-1-fred@cloudflare.com> <87tu8oze94.fsf@email.froward.int.ebiederm.org> Date: Mon, 13 Jun 2022 23:44:28 -0500 In-Reply-To: (Frederick Lawler's message of "Mon, 13 Jun 2022 15:52:38 -0500") Message-ID: <87y1xzyhub.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1o0yPr-008Y07-9H;;;mid=<87y1xzyhub.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.174.4;;;frm=ebiederm@xmission.com;;;spf=softfail X-XM-AID: U2FsdGVkX1+prA+7T4gv0KWu4+rCykKSU9Ye39R87hA= X-SA-Exim-Connect-IP: 68.227.174.4 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v3] cred: Propagate security_prepare_creds() error code X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655181878; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=Qxq+RXuKRrwWSuHRjAzQs8pgW10yTEpnQzoOp+QhWTc=; b=ztk8j/XxKSzXtO4tCOPawpvfir5iUNvgKfeMIKqtf3P7TylnX74beJMPC81Oz35A9TC9Gw F8mUnHA80YPJORkhengjdZIhcTVHUrqphP/BfWYqgfZi5cy5ggg/jzaURR8FK3t1NSJ5KR oE+k6SkJr4aWfoifSIOb6AfGVf9yGz4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf20.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655181878; a=rsa-sha256; cv=none; b=vKTD0CSqBtK3qbrru0rHatyq+j0jNiH5LxWuvgvkYrZRkYpE4IHdJANC3nVBQj0cJyw76O JapivAlWzFJA+6wynSbDQsbqIFj8DYJAUUGmwlevgUQChoIfYqKqSbXNddkUj/oYxkBPjt ICdhvZnI9Z2rcOYoDApJdeXcTronfHY= X-Stat-Signature: 8gqtbj6dn1qzkfozh4zk1kag13w8esmn X-Rspamd-Queue-Id: 5A4031C0080 X-Rspam-User: X-Rspamd-Server: rspam05 Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf20.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com X-HE-Tag: 1655181878-143213 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: Frederick Lawler writes: > Hi Eric, > > On 6/13/22 12:04 PM, Eric W. Biederman wrote: >> Frederick Lawler writes: >> >>> While experimenting with the security_prepare_creds() LSM hook, we >>> noticed that our EPERM error code was not propagated up the callstack. >>> Instead ENOMEM is always returned. As a result, some tools may send a >>> confusing error message to the user: >>> >>> $ unshare -rU >>> unshare: unshare failed: Cannot allocate memory >>> >>> A user would think that the system didn't have enough memory, when >>> instead the action was denied. >>> >>> This problem occurs because prepare_creds() and prepare_kernel_cred() >>> return NULL when security_prepare_creds() returns an error code. Later, >>> functions calling prepare_creds() and prepare_kernel_cred() return >>> ENOMEM because they assume that a NULL meant there was no memory >>> allocated. >>> >>> Fix this by propagating an error code from security_prepare_creds() up >>> the callstack. >> Why would it make sense for security_prepare_creds to return an error >> code other than ENOMEM? >> > That seems a bit of a violation of what that function is supposed to do >> > > The API allows LSM authors to decide what error code is returned from the > cred_prepare hook. security_task_alloc() is a similar hook, and has its return > code propagated. It is not an api. It is an implementation detail of the linux kernel. It is a set of convenient functions that do a job. The general rule is we don't support cases without an in-tree user. I don't see an in-tree user. > I'm proposing we follow security_task_allocs() pattern, and add visibility for > failure cases in prepare_creds(). I am asking why we would want to. Especially as it is not an API, and I don't see any good reason for anything but an -ENOMEM failure to be supported. Without an in-tree user that cares it is probably better to go the opposite direction and remove the possibility of return anything but memory allocation failure. That will make it clearer to implementors that a general error code is not supported and this is not a location to implement policy, this is only a hook to allocate state for the LSM. >> I have probably missed a very interesting discussion where that was >> mentioned but I don't see link to the discussion or anything explaining >> why we want to do that in this change. >> > > AFAIK, this is the start of the discussion. You were on v3 and had an out of tree piece of code so I assumed someone had at least thought about why you want to implement policy in a piece of code whose only purpose is to allocate memory to store state. Eric