Message-Id: <1249582695.20644.35.camel@dhcp231-106.rdu.redhat.com>
Date:	Thu, 06 Aug 2009 14:18:15 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Tvrtko Ursulin <tvrtko.ursulin@...hos.com>,
	Douglas Leeder <douglas.leeder@...hos.com>,
	Pavel Machek <pavel@....cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"malware-list@...sg.printk.net" <malware-list@...sg.printk.net>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	"greg@...ah.com" <greg@...ah.com>,
	"jcm@...hat.com" <jcm@...hat.com>, "tytso@....edu" <tytso@....edu>,
	"arjan@...radead.org" <arjan@...radead.org>,
	"david@...g.hm" <david@...g.hm>,
	"jengelh@...ozas.de" <jengelh@...ozas.de>,
	"aviro@...hat.com" <aviro@...hat.com>,
	"mrkafk@...il.com" <mrkafk@...il.com>,
	"alexl@...hat.com" <alexl@...hat.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"mmorley@....in" <mmorley@....in>
Subject: Re: fanotify - overall design before I start sending patches

On Thu, 2009-08-06 at 13:23 +0200, Peter Zijlstra wrote:

> But yes, if its so invasive to the filesystem as to make it unusable I'd
> argue it to be part of the filesystem, we do filesystem encryption in
> the filesystem, so why should we do such invasive scanning outside of
> it?

In kernel?  yes.  In filesystem?  No.  This isn't fileystem specific,
it's system wide.  Didn't we have the discussion about fuse not being as
all encompassing as a number of people wanted?  Think nfsd.  Dazuko is I
believe working on generic stackable filesystems which might eventually
be able to implement a better set of hooks, but that is a LONG way from
a solved problem last I heard.

> 
> We are taking about the kind of fanotify client that says: No you cannot
> open/read/write/mmap/etc.. this file until I say you can, right?

Only open and read (or first mmap for read).  Nothing available for
write.  Noone purports this to be an LSM.

> By the above you're hosed anyway since starting a new one will fail due
> to there being no daemon, right? Might as well forfeit all security
> measures once the daemon dies. That is let security depend on there
> being a daemon connected.

Nope.  You should stop calling and thinking of it as a security system.
As I've said multiple times it is at best an indexing and integrity
checking system.  We fail open.  We don't prevent or care about
malicious local attacks.  When a group is evicted everything is going to
just work.  The whole reason for the timeout is because I don't trust
userspace not to get it wrong and I'd rather not lose my box because of
it.  Yes, the reset I'm proposing allows userspace to screw the system
forever, but at least that is an active operation, not an accidental
segfault bringing down the whole system.

> Seems like a weird thing to me, suppose you DoS the system on purpose
> and all clients start getting wonky, you kill them all, and are left
> with non, then you cannot access any of your files anymore and
> everything grinds to a halt?

Nope, you DoS the system on purpose all the listeners get evicted, now
everything else will be able to open/read data without those listeners
paying attention.  When a group is evicted it's evicted.  It no longer
needs to say yes or no.

> Like said, having the filesystem block actions based on external
> processes seems just asking for trouble.

Or it seems like exactly what hierarchical storage management systems
want....

-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