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: <5169477D.1000400@gmx.de>
Date:	Sat, 13 Apr 2013 13:54:37 +0200
From:	Heinrich Schuchardt <xypron.glpk@....de>
To:	Justin Maggard <jmaggard10@...il.com>
CC:	linux-kernel@...r.kernel.org, eparis@...hat.com,
	LinoSanfilippo@....de, tzvetanc@...mtouch.com
Subject: Re: fanotify: fix support of large files

Dear Justin,

looking at the example at
http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c
the large file support is enabled by passing O_LARGEFILE to fanotify_init:

   if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
                                     O_RDONLY | O_CLOEXEC | 
O_LARGEFILE)) < 0)

Could you, please, check if this solves your issue.

(I am resending this message because HTML was rejected by
linux-kernel@...r.kernel.org).

Best regards

Heinrich Schuchardt

On 14.02.2013 18:29, Justin Maggard wrote:
> Opening a file of>2GB in an area of the filesystem that has been marked for
> fanotify events currently results in an EOVERFLOW error.  This is particularly
> problematic if you are using fanotify permissions checking, because it prevents
> large files from being opened at all.  Fix this by setting the O_LARGEFILE flag
> on the new file handle.
>
> Signed-off-by: Justin Maggard<jmaggard10@...il.com>
>
> ---
> fs/notify/fanotify/fanotify_user.c |    6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index 9ff4a5e..ef02b3d 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -64,6 +64,7 @@ static int create_fd(struct fsnotify_group *group,
>   			struct file **file)
>   {
>   	int client_fd;
> +	int f_flags;
>   	struct file *new_file;
>
>   	pr_debug("%s: group=%p event=%p\n", __func__, group, event);
> @@ -82,12 +83,11 @@ static int create_fd(struct fsnotify_group *group,
>   	 * we need a new file handle for the userspace program so it can read even if it was
>   	 * originally opened O_WRONLY.
>   	 */
> +	f_flags = group->fanotify_data.f_flags | FMODE_NONOTIFY | O_LARGEFILE;
>   	/* it's possible this event was an overflow event.  in that case dentry and mnt
>   	 * are NULL;  That's fine, just don't call dentry open */
>   	if (event->path.dentry&&  event->path.mnt)
> -		new_file = dentry_open(&event->path,
> -				       group->fanotify_data.f_flags | FMODE_NONOTIFY,
> -				       current_cred());
> +		new_file = dentry_open(&event->path, f_flags, current_cred());
>   	else
>   		new_file = ERR_PTR(-EOVERFLOW);
>   	if (IS_ERR(new_file)) {
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ