Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2504508ioo; Mon, 23 May 2022 22:09:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywB2ox5xNRRSfRCk0XLyPQ+EdvPnpXYpdsQmKd+vVELtdjWEwTz5JYt7NlmZJIq+I0QwSF X-Received: by 2002:a05:6402:40cf:b0:42b:541e:4a8f with SMTP id z15-20020a05640240cf00b0042b541e4a8fmr12416293edb.95.1653368979937; Mon, 23 May 2022 22:09:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653368979; cv=none; d=google.com; s=arc-20160816; b=SChQZBUQY+4um8YMjM23w5j4jfVYuwizXccXK+NHe3ConMrvq7fquVYVYGziLLV3yP AAJtJNNHWQ4neg0twnFHCdDQJbPnWdh1+tmOz+xEAskrTVQCWCyQRwA8lzpbhvp57v5f aMyg3jEaa/NNbTW26CYsxvv5xvOB2GUnvlxNwZqs+ThIuonvth5mw+YnuDZHfTztY2A6 K274iqzhrUiUYYLYNfJStQXkEkZ2GI5hX2R5VaKd/4XpwLBydM/wHL5Ah9Qv6Z8iI5sk Sxe94Q5G33ynpG590Y1Jbhj6X1YDD2nIoQQJKpp8QOGNW99R7cx3X1D7voR7GAtpxI// RkMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3ji4sol5sENBEUR3FRJaaPGspSAIjqZFEyUSpEFLQDI=; b=A8X3TdYOoxkVOgNtr8LZ45uIT0gmgjAmf6197c0106zBOnuFsC2pf8LaWWqwNYsotn tWTF/OPoIIbKXmSBctMI1A+fYW0+xnBCtbow1V28Btfgw1GYgEk43GtsaxSSf+w9CxKg FjXE8dV1XmHqIAPPy14E6Fbv4VHc4MfKa4HC4igMJ/YJSd5Gq4QrgDs6o6F1qhcr04VN ARPVnQzJVSUrq7fmpRHLVjips4/Sn9y1sEqCh7uHAGulOnX97QvqhC7FV9j1qUZ4MSo/ lTc/7/NF/JYKI8E/B5npLswQQ1jAYMsAMkAuDPLrP2Bl2yYjmftAs6K6SLSikslUwgiu StAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hYQ0c6yY; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ne17-20020a1709077b9100b006e8a20ff3f4si19945478ejc.299.2022.05.23.22.09.02; Mon, 23 May 2022 22:09:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=hYQ0c6yY; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233676AbiEXEoz (ORCPT + 99 others); Tue, 24 May 2022 00:44:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232361AbiEXEoy (ORCPT ); Tue, 24 May 2022 00:44:54 -0400 Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D7448A324; Mon, 23 May 2022 21:44:53 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id x65so10053219qke.2; Mon, 23 May 2022 21:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ji4sol5sENBEUR3FRJaaPGspSAIjqZFEyUSpEFLQDI=; b=hYQ0c6yYUcVfmu71erT+6VDvx5G5eYcf4JX8bivgxAcVRq5T3YZxHLiHp7WVwTBBKX 2cOVjoP55GH4W2zie2kWBOVkgG9jKEKwEHZKlBMLHQoU3Yc8QfBpCdlzyGoKWq6exl2z CXs+AIZOVs51bvpDx4A3SsKyoRq8+ZebiCv1qR8S+d2mqUxAJ/h6mxa3tZBaewM+RluK 1wzAbw2iLe8Oy3Zk36z2kqKEuVS4oPAbyUAezph7jfU7+2GCbslF5ktHoXqlE7+7ecDQ 5aw2ZDoJlyjN0AESyO2s/eOFveXNANFGXQV6JyxvQmmQbEnlvdWqWNb53GgzP2Uj38Kk pnCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ji4sol5sENBEUR3FRJaaPGspSAIjqZFEyUSpEFLQDI=; b=KoXc4q7a5y2ykuEfAZKmZbJV7VUhmCnux/QTvN+YAMUSVv5fY/RcsmLDF4sPp2Rtl+ o597dGXixYNwAYCq3/VLHUV9+76PMNGiEFyO57vlBD7RTlnwMXFgC9nQOMZWeF+TEACi Sr8pNpc7czBELQFxCHG8GZFZhf6iHEoLnejaR3YTIxawmruPVT/nM03Ntz8d1v+o/KxG q4jRPVFzR8zOf0/rEER9JKA+mqSbrKjDlBnM+IoHBXrq4gH418HEb+cx5JGJ1tF+NxM9 1yp4mC8nZJU3crvXTmxg3yqPxPW33A2L/mfiDClB1L5ReDKiPOojfgzF0VbOJc7sPuOj 7Kug== X-Gm-Message-State: AOAM530KdmMNw3mGFbnwuJFgopAkLlfds/oxmDQEhtmpoP+A3ulWtfV9 qyo/AZN2WVonRAUhqrkVYXzb+pCu3XtahPtSkkN4qFScv4g= X-Received: by 2002:a37:8846:0:b0:6a0:f6f1:a015 with SMTP id k67-20020a378846000000b006a0f6f1a015mr16143176qkd.386.1653367492354; Mon, 23 May 2022 21:44:52 -0700 (PDT) MIME-Version: 1.0 References: <20220520212746.95075-1-fred@cloudflare.com> In-Reply-To: <20220520212746.95075-1-fred@cloudflare.com> From: Amir Goldstein Date: Tue, 24 May 2022 07:44:41 +0300 Message-ID: Subject: Re: [PATCH] cred: Propagate security_prepare_creds() error code To: Frederick Lawler Cc: linux-aio@kvack.org, linux-fsdevel , linux-kernel , linux-cachefs@redhat.com, CIFS , samba-technical , Linux MM , Linux NFS Mailing List , overlayfs , LSM List , Netdev , keyrings@vger.kernel.org, selinux@vger.kernel.org, kernel-team@cloudflare.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Sat, May 21, 2022 at 2:17 PM Frederick Lawler wrote: > > 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. > > Signed-off-by: Frederick Lawler > --- [...] > @@ -1173,7 +1173,7 @@ struct file *filp_open(const char *filename, int flags, umode_t mode) > { > struct filename *name = getname_kernel(filename); > struct file *file = ERR_CAST(name); > - > + stray whitespace > if (!IS_ERR(name)) { > file = file_open_name(name, flags, mode); > putname(name); > diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c > index f18490813170..905eb8f69d64 100644 > --- a/fs/overlayfs/dir.c > +++ b/fs/overlayfs/dir.c > @@ -589,28 +589,32 @@ static int ovl_create_or_link(struct dentry *dentry, struct inode *inode, > goto out_revert_creds; > } > > - err = -ENOMEM; > override_cred = prepare_creds(); > - if (override_cred) { > - override_cred->fsuid = inode->i_uid; > - override_cred->fsgid = inode->i_gid; > - if (!attr->hardlink) { > - err = security_dentry_create_files_as(dentry, > - attr->mode, &dentry->d_name, old_cred, > - override_cred); > - if (err) { > - put_cred(override_cred); > - goto out_revert_creds; > - } > - } > - put_cred(override_creds(override_cred)); > - put_cred(override_cred); > + if (IS_ERR(override_cred)) { > + err = PTR_ERR(override_cred); > + goto out_revert_creds; > + } > > - if (!ovl_dentry_is_whiteout(dentry)) > - err = ovl_create_upper(dentry, inode, attr); > - else > - err = ovl_create_over_whiteout(dentry, inode, attr); > + override_cred->fsuid = inode->i_uid; > + override_cred->fsgid = inode->i_gid; > + if (!attr->hardlink) { > + err = security_dentry_create_files_as(dentry, attr->mode, > + &dentry->d_name, > + old_cred, > + override_cred); > + if (err) { > + put_cred(override_cred); > + goto out_revert_creds; > + } > } > + put_cred(override_creds(override_cred)); > + put_cred(override_cred); > + > + if (!ovl_dentry_is_whiteout(dentry)) > + err = ovl_create_upper(dentry, inode, attr); > + else > + err = ovl_create_over_whiteout(dentry, inode, attr); > + It does not look like reducing the nesting level was really needed for your change. Was it? It is impossible to review a logic change with this much code churn. Please stick to the changes you declared you are doing and leave code style out of it. > out_revert_creds: > revert_creds(old_cred); > return err; > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > index 001cdbb8f015..b29b62670e10 100644 > --- a/fs/overlayfs/super.c > +++ b/fs/overlayfs/super.c > @@ -1984,10 +1984,11 @@ static int ovl_fill_super(struct super_block *sb, void *data, int silent) > if (!ofs) > goto out; > > - err = -ENOMEM; > ofs->creator_cred = cred = prepare_creds(); > - if (!cred) > + if (IS_ERR(ofs->creator_cred)) { > + err = PTR_ERR(ofs->creator_cred); > goto out_err; > + } > A non NULL must not be assigned to ofs->creator_cred use the cred local var for that check, otherwise things will go badly in ovl_free_fs(). Thanks, Amir.