RE: Configuration parameter request
Ben,
Thanks for responding, we will pass this on to our team.
Kind Regards
Linda
-----Original Message-----
From: Ben Hutchings [mailto:ben@decadent.org.uk]
Sent: Tuesday, July 19, 2016 1:37 PM
To: Linda Arens; debian-kernel@lists.debian.org
Cc: Olesya Golubkova
Subject: Re: Configuration parameter request
On Tue, 2016-07-19 at 16:38 +0000, Linda Arens wrote:
> Hi Ben and Debian Kernel team.
>
> Thank you for this information. I provided it to our team and we have
> an additional question and want to clarify what we see.
>
> 1. Could you please let us know when these changes/features will
> be added and in what branches?
Already done in experimental and will be enabled in unstable with the first upload based on Linux 4.7.
> 2. you mention the following:
> …it still looks prone to deadlocks and it doesn't really prevent
> reading malware.
> So I'll enable this but log a warning when it's used because
> it's not a
> feature I really want to support.
>
> KL: We have found that it is possible to create deadlocks using
> fanotify and even crash the whole operation system from the user
> space, the root cause of this is fanotify itself that is able to
> intercept file operations, not the fanotify access permission.
There's a big difference between implementation bugs, which can generally be fixed, and flaws in an API design, which cannot.
> Since fanotify is already enabled in the Debian kernel we are
> not adding risks for the end-users by enabling the access permission
> feature in the kernel. Therefore we are not sure why a warning would
> be given for enabling the access permission feature.
fanotify permission checking causes arbitrary tasks to block waiting for the checker, which can easily include tasks that the checker depends on to make its decision.
Ben.
--
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.
Reply to: