linux-kernel - Re: [PATCH =-v3 18/21] fanotify: all userspace to set timeouts

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:	Wed, 12 Nov 2008 16:14:32 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	viro@...iv.linux.org.uk, alan@...rguk.ukuu.org.uk,
	arjan@...radead.org, greg@...ah.com, tytso@....edu,
	akpm@...ux-foundation.org
Subject: Re: [PATCH =-v3 18/21] fanotify: all userspace to set timeouts

On Wed, 2008-11-12 at 11:56 -0500, Christoph Hellwig wrote:
> On Wed, Nov 12, 2008 at 11:12:01AM -0500, Eric Paris wrote:
> > fanotify when used to make access decisions has a default 5 second timeout.
> > This patch will allow userspace listeners to change their timeout on a
> > group wide basis.  Userspace listeners will still be able to reset the
> > timeout for individual events.
> 
> Really, I think you start to over-engineer.  I think this whole stuff
> would have a much higher chance if you could come up with a staged set
> of patchsets, ala:
> 
>  (1) unify the current *notify schemes
>  (2) add a filesystem wide notify scheme
>  (3) add blocking filesystem notifiers
> 
> and then maybe a fourth with all the misc little things that I doubt
> will have much of a chance.

This patch set is mostly lined up from most useful to least and every
patch comiles and runs on its own.  The request for per listener
timeouts is based on the array of potential users.  Mainly it was put in
to allow HSMs to set a high timeout while they ran off and pulled a tape
out of the robot.  I already let them reset the timeout if they need
more time, so I'm find with dropping it if it is so hard to handle.

I'll take a look at #1 but #2 and #3 is exactly what I did.  I added
fanotify.  I added an interface for it.  And then I flushed out #2 to
the point it was useful on it's own (and off list I've gotten e-mail
indicating we have non-AV/malware people interested in using this part
of fanotify )

#3 is filled out from patches 10-13.  14+ are all misc but aside from
this particular patch I can't see any other way to achieve the intended
goals.

I'd love to hear any ideas on how to unitfy the three.  Heck I'd be glad
to hear any idea how to unify even inotify and dnotify since all three
have such wildly different lifetimes and implementations..

I'll poke at this but for now I see my patches as (mostly) clean,
useful, and complete.

-Eric

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