lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241121104428.wtlrfhadcvipkjia@quack3>
Date: Thu, 21 Nov 2024 11:44:28 +0100
From: Jan Kara <jack@...e.cz>
To: Josef Bacik <josef@...icpanda.com>
Cc: kernel-team@...com, linux-fsdevel@...r.kernel.org, jack@...e.cz,
	amir73il@...il.com, brauner@...nel.org,
	torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
	linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-mm@...ck.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v8 10/19] fanotify: introduce FAN_PRE_ACCESS permission
 event

On Fri 15-11-24 10:30:23, Josef Bacik wrote:
> From: Amir Goldstein <amir73il@...il.com>
> 
> Similar to FAN_ACCESS_PERM permission event, but it is only allowed with
> class FAN_CLASS_PRE_CONTENT and only allowed on regular files and dirs.
> 
> Unlike FAN_ACCESS_PERM, it is safe to write to the file being accessed
> in the context of the event handler.
> 
> This pre-content event is meant to be used by hierarchical storage
> managers that want to fill the content of files on first read access.
> 
> Signed-off-by: Amir Goldstein <amir73il@...il.com>

Here I was wondering about one thing:

> +	/*
> +	 * Filesystems need to opt-into pre-content evnets (a.k.a HSM)
> +	 * and they are only supported on regular files and directories.
> +	 */
> +	if (mask & FANOTIFY_PRE_CONTENT_EVENTS) {
> +		if (!(path->mnt->mnt_sb->s_iflags & SB_I_ALLOW_HSM))
> +			return -EINVAL;
> +		if (!is_dir && !d_is_reg(path->dentry))
> +			return -EINVAL;
> +	}

AFAICS, currently no pre-content events are generated for directories. So
perhaps we should refuse directories here as well for now? I'd like to
avoid the mistake of original fanotify which had some events available on
directories but they did nothing and then you have to ponder hard whether
you're going to break userspace if you actually start emitting them...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ