linux-kernel - Re: [GIT PULL] notification tree

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]

Date:	Mon, 16 Aug 2010 22:32:36 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Eric Paris <eparis@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Matt Helsley <matthltc@...ibm.com>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
	Michael Kerrisk <michael.kerrisk@...il.com>
Subject: Re: [GIT PULL] notification tree - try 37!

On Saturday 07 August 2010 21:15:14 Eric Paris wrote:
> On Fri, 2010-08-06 at 20:06 -0400, Christoph Hellwig wrote:
> > I'm also totally missing on any re-post of these patches or discussion
> > of the changes during the last development window.
> 
> I just searched lkml an fsdevel where I usually send everything don't
> see then.  I totally failed.

Oh yes.

This introduces two new syscalls which will be impossible to fix up after the 
fact, and those system calls are poorly documented: commits 2a3edf86 and 
52c923dd document the initial versions (in the commit message!), but 
subsequent commits then extend that interface.  The interface for replying to 
events is not documented at all beyond the example code [1].  There is no 
documentation in Documentation/filesystems/, either.

	[1] http://people.redhat.com/~eparis/fanotify/

Q: What happens when a process watching for FAN_OPEN_PERM or FAN_ACCESS_PERM 
events exits or dies while events are in flight?  I can't see anything in the 
code that would wake sleeping processes up when the fsnotify_group of the 
listener is torn down.

Q: What prevents the system from going out of memory when a listener decides 
to stop reading events or simply can't keep up?  There doesn't seem to be a 
limit on the queue depth.  Listeners currently need CAP_SYS_ADMIN, but somehow 
limiting the queue depth and throttling when things start to go bad still 
sounds like a reasonable thing to do, right?)

Don't get me wrong, I really appreciate your work on this (this shows through 
the patches I've committed), and what we have now is a lot better than what we 
had before.

Thanks,
Andreas
--
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/