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: <1226524472.3353.45.camel@localhost.localdomain>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ