All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Stefan Berger <stefanb@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
	serge@hallyn.com, brauner@kernel.org, containers@lists.linux.dev,
	dmitry.kasatkin@gmail.com, ebiederm@xmission.com,
	krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com,
	mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com,
	puiterwi@redhat.com, jejb@linux.ibm.com, jamjoom@us.ibm.com,
	linux-kernel@vger.kernel.org, paul@paul-moore.com,
	rgb@redhat.com, linux-security-module@vger.kernel.org,
	jmorris@namei.org, jpenumak@redhat.com,
	John Johansen <john.johansen@canonical.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Micah Morton <mortonm@chromium.org>,
	Kentaro Takeda <takedakn@nttdata.co.jp>
Subject: Re: [PATCH v15 01/26] securityfs: rework dentry creation
Date: Fri, 10 Feb 2023 02:39:19 +0200	[thread overview]
Message-ID: <Y+WSDX/zxRpxzqLP@kernel.org> (raw)
In-Reply-To: <20230206140253.3755945-2-stefanb@linux.ibm.com>

On Mon, Feb 06, 2023 at 09:02:28AM -0500, Stefan Berger wrote:
> From: Christian Brauner <brauner@kernel.org>
> 
> When securityfs creates a new file or directory via
> securityfs_create_dentry() it will take an additional reference on the
> newly created dentry after it has attached the new inode to the new
> dentry and added it to the hashqueues.
> If we contrast this with debugfs, which has the same underlying logic as

nit: "Constrating this with debugfs"

Passive form is better when there is no well-defined definition of "we".

> securityfs, it uses a similar pairing as securityfs. Where securityfs
> has the securityfs_create_dentry() and securityfs_remove() pairing,
> debugfs has the __debugfs_create_file() and debugfs_remove() pairing.
> 
> In contrast to securityfs, debugfs doesn't take an additional reference
> on the newly created dentry in __debugfs_create_file() which would need
> to be put in debugfs_remove().
> 
> The additional dget() isn't a problem per se. In the current
> implementation of securityfs each created dentry pins the filesystem via
> securityfs_create_dentry() until it is removed. Since it is virtually
> guaranteed that there is at least one user of securityfs that has created
> dentries the initial securityfs mount cannot go away until all dentries
> have been removed.
> 
> Since most of the users of the initial securityfs mount don't go away
> until the system is shutdown the initial securityfs won't go away when
> unmounted. Instead a mount will usually surface the same superblock as
> before. The additional dget() doesn't matter in this scenario since it
> is required that all dentries have been cleaned up by the respective
> users before the superblock can be destroyed, i.e. superblock shutdown
> is tied to the lifetime of the associated dentries.
> 
> However, in order to support ima namespaces we need to extend securityfs
> to support being mounted outside of the initial user namespace. For
> namespaced users the pinning logic doesn't make sense. Whereas in the
> initial namespace the securityfs instance and the associated data
> structures of its users can't go away for reason explained earlier users
> of non-initial securityfs instances do go away when the last users of
> the namespace are gone.

"for reason explained earlier" ?

> So for those users we neither want to duplicate the pinning logic nor
> make the global securityfs instance display different information based
> on the namespace. Both options would be really messy and hacky.
> 
> Instead we will simply give each namespace its own securityfs instance
> similar to how each ipc namespace has its own mqueue instance and all
> entries in there are cleaned up on umount or when the last user of the
> associated namespace is gone.
> 
> This means that the superblock's lifetime isn't tied to the dentries.
> Instead the last umount, without any fds kept open, will trigger a clean
> shutdown. But now the additional dget() gets in the way. Instead of
> being able to rely on the generic superblock shutdown logic we would
> need to drop the additional dentry reference during superblock shutdown
> for all associated users. That would force the use of a generic
> coordination mechanism for current and future users of securityfs which
> is unnecessary. Simply remove the additional dget() in
> securityfs_dentry_create().
> 
> In securityfs_remove() we will call dget() to take an additional
> reference on the dentry about to be removed. After simple_unlink() or
> simple_rmdir() have dropped the dentry refcount we can call d_delete()
> which will either turn the dentry into negative dentry if our earlier
> dget() is the only reference to the dentry, i.e. it has no other users,
> or remove it from the hashqueues in case there are additional users.
> 
> All of these changes should not have any effect on the userspace
> semantics of the initial securityfs mount.
> 
> Signed-off-by: Christian Brauner <brauner@kernel.org>
> Cc: John Johansen <john.johansen@canonical.com>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: Micah Morton <mortonm@chromium.org>
> Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
> Cc: James Morris <jmorris@namei.org>
> Cc: Jarkko Sakkinen <jarkko@kernel.org>
> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> Reviewed-by: Serge Hallyn <serge@hallyn.com>
> 
> ---
> v13:
>   - Slight improvements in 1st paragraph of commit message
> ---
>  security/inode.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/security/inode.c b/security/inode.c
> index 6c326939750d..13e6780c4444 100644
> --- a/security/inode.c
> +++ b/security/inode.c
> @@ -159,7 +159,6 @@ static struct dentry *securityfs_create_dentry(const char *name, umode_t mode,
>  		inode->i_fop = fops;
>  	}
>  	d_instantiate(dentry, inode);
> -	dget(dentry);
>  	inode_unlock(dir);
>  	return dentry;
>  
> @@ -302,10 +301,12 @@ void securityfs_remove(struct dentry *dentry)
>  	dir = d_inode(dentry->d_parent);
>  	inode_lock(dir);
>  	if (simple_positive(dentry)) {
> +		dget(dentry);
>  		if (d_is_dir(dentry))
>  			simple_rmdir(dir, dentry);
>  		else
>  			simple_unlink(dir, dentry);
> +		d_delete(dentry);
>  		dput(dentry);
>  	}
>  	inode_unlock(dir);
> -- 
> 2.37.3
> 

BR, Jarkko

  reply	other threads:[~2023-02-10  0:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-06 14:02 [PATCH v15 00/26] ima: Namespace IMA with audit support in IMA-ns Stefan Berger
2023-02-06 14:02 ` [PATCH v15 01/26] securityfs: rework dentry creation Stefan Berger
2023-02-10  0:39   ` Jarkko Sakkinen [this message]
2023-02-06 14:02 ` [PATCH v15 02/26] securityfs: Extend securityfs with namespacing support Stefan Berger
2023-02-06 14:02 ` [PATCH v15 03/26] ima: Define ima_namespace struct and start moving variables into it Stefan Berger
2023-02-06 14:02 ` [PATCH v15 04/26] ima: Move arch_policy_entry into ima_namespace Stefan Berger
2023-02-06 14:02 ` [PATCH v15 05/26] ima: Move ima_htable " Stefan Berger
2023-02-06 14:02 ` [PATCH v15 06/26] ima: Move measurement list related variables " Stefan Berger
2023-02-06 14:02 ` [PATCH v15 07/26] ima: Move some IMA policy and filesystem " Stefan Berger
2023-02-06 14:02 ` [PATCH v15 08/26] ima: Move IMA securityfs files into ima_namespace or onto stack Stefan Berger
2023-02-06 14:02 ` [PATCH v15 09/26] ima: Move ima_lsm_policy_notifier into ima_namespace Stefan Berger
2023-02-06 14:02 ` [PATCH v15 10/26] ima: Switch to lazy lsm policy updates for better performance Stefan Berger
2023-02-06 14:02 ` [PATCH v15 11/26] ima: Define mac_admin_ns_capable() as a wrapper for ns_capable() Stefan Berger
2023-02-06 14:02 ` [PATCH v15 12/26] ima: Only accept AUDIT rules for non-init_ima_ns namespaces for now Stefan Berger
2023-02-06 14:02 ` [PATCH v15 13/26] userns: Add pointer to ima_namespace to user_namespace Stefan Berger
2023-02-06 14:02 ` [PATCH v15 14/26] ima: Implement hierarchical processing of file accesses Stefan Berger
2023-02-06 14:02 ` [PATCH v15 15/26] ima: Implement ima_free_policy_rules() for freeing of an ima_namespace Stefan Berger
2023-02-06 14:02 ` [PATCH v15 16/26] ima: Add functions for creating and " Stefan Berger
2023-02-06 14:02 ` [PATCH v15 17/26] integrity/ima: Define ns_status for storing namespaced iint data Stefan Berger
2023-02-06 14:02 ` [PATCH v15 18/26] integrity: Add optional callback function to integrity_inode_free() Stefan Berger
2023-02-06 14:02 ` [PATCH v15 19/26] ima: Namespace audit status flags Stefan Berger
2023-02-06 14:02 ` [PATCH v15 20/26] ima: Remove unused iints from the integrity_iint_cache Stefan Berger
2023-02-06 14:02 ` [PATCH v15 21/26] ima: Setup securityfs for IMA namespace Stefan Berger
2023-02-06 14:02 ` [PATCH v15 22/26] ima: Introduce securityfs file to activate an " Stefan Berger
2023-02-06 14:02 ` [PATCH v15 23/26] ima: Show owning user namespace's uid and gid when displaying policy Stefan Berger
2023-02-06 14:02 ` [PATCH v15 24/26] ima: Limit number of policy rules in non-init_ima_ns Stefan Berger
2023-02-06 14:02 ` [PATCH v15 25/26] ima: Restrict informational audit messages to init_ima_ns Stefan Berger
2023-02-06 14:02 ` [PATCH v15 26/26] ima: Enable IMA namespaces Stefan Berger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+WSDX/zxRpxzqLP@kernel.org \
    --to=jarkko@kernel.org \
    --cc=brauner@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jamjoom@us.ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=jpenumak@redhat.com \
    --cc=krzysztof.struczynski@huawei.com \
    --cc=lhinds@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lsturman@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=mortonm@chromium.org \
    --cc=mpeters@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=puiterwi@redhat.com \
    --cc=rgb@redhat.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=stefanb@linux.ibm.com \
    --cc=takedakn@nttdata.co.jp \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.