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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Thu, 2 Mar 2017 17:41:33 +0100
From:   Andreas Schärtl <andreas@...aertl.me>
To:     eparis@...hat.com, linux-kernel@...r.kernel.org
Cc:     markus.buettner@....de, artur.wasinger@....de,
        burak-kernel@...0k.de
Subject: fanotify: Support for file creation and deletion

Hello,

we are a group of students, for a course we would like to create an
efficient backup/file synchronization tool that supports file system
trees with lots of directories. Currently such tools use the inotify
interface but we would rather not use it because (1) inotify requires
a watch descriptor for each watched directory and (2) we would rather
not create new watches every time a directory was created.

fanotify already supports watching full mount points without needing
many watch descriptors. It can log file modifications with the
FAN_MODIFY mask, but we also need a way to get notified when files are
created/deleted. We would like to extend fanotify to support those
events.

The problem with the current fanotify_event_metadata is that it
doesn't support a way to do this. This is why we want to extend the
struct with the path of the newly {created, deleted} file or
directory. To facilitate this, we are considering the following
structure for create and delete events:

    struct fanotify_event_metadata {
            __u32 event_len;
            __u8 vers;
            __u8 reserved;
            __u16 metadata_len;
            __aligned_u64 mask;
            __s32 fd;
            __s32 pid;
            __u32 path_len;
            char path[];
    };

One thing we do not quite understand is the difference between
event_len and metadata_len. If metadata_len is actually the length of
the not variable part (anything but path), path_len is not
necessary. It may make sense to introduce a new structure just for the
create and delete events.

We are wondering what you think about this proposal. Whether it makes
sense to follow this idea or if you have other ideas. Thank you!

-- Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ