linux-kernel - Re: [RFC 1/2] fanotify: new event FAN_MODIFY

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170316103859.GR12989@quack2.suse.cz>
Date:   Thu, 16 Mar 2017 11:38:59 +0100
From:   Jan Kara <jack@...e.cz>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Jan Kara <jack@...e.cz>,
        Filip Štědronský <r.lklm@...narg.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [RFC 1/2] fanotify: new event FAN_MODIFY_DIR

On Wed 15-03-17 16:34:11, Amir Goldstein wrote:
> On Wed, Mar 15, 2017 at 4:05 PM, Jan Kara <jack@...e.cz> wrote:
> >> So the string fields in my proposal are optional.
> >> userspace opts-in to get them by specifying the  FAN_EVENT_INFO_NAME flag:
> >>
> >>     fanotify_init(FAN_CLOEXEC | FAN_CLASS_NOTIF |
> >>                        FAN_EVENT_INFO_PARENT | FAN_EVENT_INFO_NAME,
> >>
> >> If you don't specify FAN_EVENT_INFO_NAME, you can get filename events
> >> FAN_MOVE|FAN_CREATE|FAN_DELETE without the name.
> >
> > So when thinking about this again, I'm again concerned that the names need
> > not tell userspace what it thinks. I know we already discussed this but
> > in our last discussion I think I forgot to point out that inotify directory
> > events (and fanotify would be the same AFAICT) may come out of order compared
> > to real filesystem changes. E.g. sequence:
> >
> > Task 1          Task 2
> >
> > mv a b
> >                 mv b c
> >
> > may come out of inotify as:
> >
> > IN_MOVED_FROM "b" COOKIE 1
> > IN_MOVED_TO   "c" COOKIE 1
> > IN_MOVED_FROM "a" COOKIE 2
> > IN_MOVED_TO   "b" COOKIE 2
> >
> 
> Really? How come?
> 
> fsnotify_move() inside vfs_rename() is serialized with lock_rename()

Sorry, I got confused by the unlocking in vfs_rename() however that unlocks
only the moved file / directory but not the directory in which the rename
is happening. Taking my objection back.

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