Message-ID: <20080926223404.7c4894df@lxorguk.ukuu.org.uk>
Date:	Fri, 26 Sep 2008 22:34:04 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	arjan@...radead.org, bunk@...nel.org, tytso@....edu,
	tvrtko.ursulin@...hos.com, david@...g.hm, hch@...radead.org,
	andi@...stfloor.org, viro@...IV.linux.org.uk, peterz@...radead.org,
	Jonathan.Press@...com, riel@...hat.com
Subject: Re: [RFC] 0/11 fanotify: fscking all notifiction and file access
 system (intended for antivirus scanning and file indexers)

> It all starts when 'something' registers a group.  Registering a group
> is as simple as 'echo "open_grp 50 0x10" > /security/fanotify/register.

I thought the operation was usually called "mkdir" which also nicely
deals with races and exclusion.

> open_grp is just the name of the group, 50 is the priority (only
> interesting for blocking/access events, will describe later) and 0x10 is
> FAN_OPEN. If one wanted open and close you would use 0x1c = (FAN_OPEN |
> FAN_CLOSE).  Inside the kernel this creates the new directory called

How do you change group on the fly in this model ?

> The listener process will get a string that looks like "fd=10 cookie=0
> mask=10."  This is telling the listener process that a new fd has been
> created, #10.  The cookie (if this notification required an access
> decision) was 0 and the mask of the event was 0x10 (FAN_OPEN.)

Ok that is foul as an interface, utterly gross. I guess it would be
useful to also be able to not want fds

> event is added to the group->access_list AND to the group->event_list.
> The original process is then blocked for a (now fixed 5 second) timeout
> waiting for the event to get a non-zero event->response on the
> group->access_waitq.

That raises security and correctness questions with things like "make it
swap hard" attacks. Given that any timeout can be configured its not a
big deal. Do need to handle process death or close of the notification
descriptors.

I think the mechanism is pretty sound. There are some "how do I" cases to
do with open and watching for events when I want to rescan something as
it has been dirty for a while. I'm not sure mmap dirty properly updates
the file mtime - that wants doing anyway for backups tho so is the real
fix.

The userspace API you propoe should however be taken out and shot, then
buried with a stake through its heart, holy water in its mouth and its
head cut off, at midnight in a pentacle at a crossroads in the presence
of a priest.

The two discussions are fortunately orthogonal. Is there any reason you
can't use the socket based notification model - that gives you a much
more natural way to express the thing


		socket
		bind(AF_FAN, group=foo+flags etc, PF_FAN);

		fd = accept(old_fd, &addr[returned info])

		close(fd);

as well as fairly natural and importantly standards defined semantics for
poll including polling for a new file handles, for reconfiguration of
stuff via get/setsockopt (which do pass stuff like object sizes unlike
ioctls) and for reading/writing data.

Its not quite the same as a normal socket given you accept and get a non
socket fd with the info you need in the return address area but its much
closer than the rather mad file system proposal.

It would certainly be sane enough to, for example, start righting
scanners in stuff like python-twisted or ruby on rails (not that this is
neccessarily a good thing!)

Alan

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