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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA0BBC05027 for ; Wed, 1 Feb 2023 19:47:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230032AbjBATrI (ORCPT ); Wed, 1 Feb 2023 14:47:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57416 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231712AbjBATrA (ORCPT ); Wed, 1 Feb 2023 14:47:00 -0500 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0610A83253; Wed, 1 Feb 2023 11:46:47 -0800 (PST) Received: by linux.microsoft.com (Postfix, from userid 1052) id 5F2CE20B7102; Wed, 1 Feb 2023 11:46:47 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5F2CE20B7102 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1675280807; bh=8MDyb8NfMEMA+gvGsYIH3Hk92qnGUNCXXiiUGYDGeY0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aGiTEE1l0zxKt35hRAw5O5rUjHIWcAoDjTu0gK/pqVOhoxy2wEnsm8ZNcF03j15OU toc+XIsocCQ+PUZLhpiUjHGzrPbYhknyZg79wHeR50uEX2RjoQI/xWZzNaX8eA9EKw t8/KxyA0u4mFqi9fvZeO3cXFFwKkFGDUqHnC4vOk= Date: Wed, 1 Feb 2023 11:46:47 -0800 From: Fan Wu To: Roberto Sassu Cc: corbet@lwn.net, zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com, tytso@mit.edu, ebiggers@kernel.org, axboe@kernel.dk, agk@redhat.com, snitzer@kernel.org, eparis@redhat.com, paul@paul-moore.com, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, linux-audit@redhat.com, roberto.sassu@huawei.com, linux-kernel@vger.kernel.org, Deven Bowers Subject: Re: [RFC PATCH v9 05/16] ipe: add userspace interface Message-ID: <20230201194647.GA11892@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1675119451-23180-1-git-send-email-wufan@linux.microsoft.com> <1675119451-23180-6-git-send-email-wufan@linux.microsoft.com> <255c119de8f8665b88c411d981762fddc0fe7eaa.camel@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255c119de8f8665b88c411d981762fddc0fe7eaa.camel@huaweicloud.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org On Tue, Jan 31, 2023 at 11:49:44AM +0100, Roberto Sassu wrote: > On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote: > > From: Deven Bowers > > + > > +/** > > + * new_policy - Write handler for the securityfs node, "ipe/new_policy". > > + * @f: Supplies a file structure representing the securityfs node. > > + * @data: Suppleis a buffer passed to the write syscall. > > Typo: Suppleis. > Thanks for spotting the typos! > > + * @len: Supplies the length of @data. > > + * @offset: unused. > > + * > > + * Return: > > + * * >0 - Success, Length of buffer written > > + * * <0 - Error > > + */ > > +static ssize_t new_policy(struct file *f, const char __user *data, > > + size_t len, loff_t *offset) > > +{ > > + int rc = 0; > > + char *copy = NULL; > > + struct ipe_policy *p = NULL; > > + > > + if (!file_ns_capable(f, &init_user_ns, CAP_MAC_ADMIN)) > > + return -EPERM; > > + > > + copy = memdup_user_nul(data, len); > > + if (IS_ERR(copy)) { > > + rc = PTR_ERR(copy); > > + goto err; > > + } > > + > > + p = ipe_new_policy(NULL, 0, copy, len); > > + if (IS_ERR(p)) { > > + rc = PTR_ERR(p); > > + goto err; > > + } > > + > > + rc = ipe_new_policyfs_node(p); > > + if (rc) > > + goto err; > > Uhm, don't you need to do cleanup of allocated memory or revert the > actions of ipe_new_policy()? > Yes that should be cleaned up but should be done in ipe_new_policy instead, will add a ipe_free_policy call at the end. Thanks for pointing that out. > > I would like more to see all the functions managing the policy > together. If the patch is too long, you could further split by adding > the helpers (that don't directly deal with the policy) in a separate > patch. > > Here you would simply instantiate dirs/files in securityfs and call the > existing functions previously introduced. > > Roberto > I will try to split them in the next version. Thanks for the suggestion. -Fan