linux-kernel - overlayfs and inotify

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

Date:	Tue, 28 Feb 2012 14:20:41 +0000
From:	Andy Whitcroft <apw@...onical.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	mszeredi@...e.cz
Subject: overlayfs and inotify

I have recently been looking at reports of inotify issues with overlayfs.
As things stand there is essentially no inotify support, as dispite being
able to set watches they will never trigger as IO is always performed
against the underlying inodes and not where the watches are placed.
You can reproduce this trivially using tail -f against a file in an
overlayfs mount.

I have been playing with some ideas how this might be resolved.  I have
some very preliminary patches which turn overlayfs into an fsnotify
consumer.  When watches are placed against the upper overlayfs inode I
simply reflect them as an aggregate fsnotify mark against the underlying
inode in the active layer; moving the mark to the upper inode during any
copy_up operation.

While this works pretty well for a lot of use cases, it does not help
with tail -f.  When the change notification is emitted tail then fstat
its open file descriptor and if the size is changed it emits the new data.
Obviously with overlayfs tail may be connected to the original r/o layer
copy of the file, so any re-stat will indicate the file is unchanged and
emit nothing.

Now clearly we could fix tail in this case to stat the filename instead
which would avoid the issue.  But I am concerned that this might be a
common idiom in other inotify consumers.

I also wonder if we should be hinting to userspace that there is something
unusual going on during copy_up, for example emitting an IN_MOVE_SELF to
allow consumers to follow along more easily.

Before I spend any more time cleaning up these patches I wondered if
this approach even makes sense, can we really produce sensible semantics
for inotify in this case in the face of the direct to the underlying
filesystem semantics.

Thoughts?

-apw
--
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/