[Devel] [PATCH rh7] fanotify: Use ve-capable instead of plain capable test

[Vladimir Davydov]

On Fri, Nov 27, 2015 at 05:19:09PM +0300, Cyrill Gorcunov wrote:
> On Fri, Nov 27, 2015 at 04:47:35PM +0300, Vladimir Davydov wrote:
> > On Wed, Nov 25, 2015 at 06:00:00PM +0300, Cyrill Gorcunov wrote:
> > > To create fanotify objects one have to be sysadmin of a container.
> > > The main potential problem is unlimited number of marks and queue,
> > > but since it uses kmem cgroup to obtain objects this should be
> > > controllable via memory cgroup settings.
> > 
> > There are lots of kernel objects having the same potential problem that
> > are not restricted to CAP_SYS_ADMIN though. So I don't think this is the
> > real cause why access to fanotify was restricted. Have you found any
> > other explanation of using CAP_SYS_ADMIN there? In commit message or man
> > pages, perhaps.
> 
> The man pages says:
> 
>  | Calling fanotify_init() requires the CAP_SYS_ADMIN capability.
>  | This constraint might be relaxed in future versions of the API.
> 
> I think the main reason is due to ability to create a local DoS
> when there was no queue depth limit (in first api version). Then
> @max-depth was set but still one can override it if has CAP_SYS_ADMIN.
> Thus we still can make a local DoS. With kmem controller this should
> be safe under container (if only I've not missed something).
> 
> > Next, do we really want to enable this feature inside containers? We
> > don't have it in PCS6 and nobody seems to care.
> 
> The former issue is due to tests in CRIU -- we test c/r of fanotify
> object there. So test has been failed and I had to figure out why.
> The centos-7 container which we testing now doesn't use fanotify
> but it may be changed in future. Actually I'm not against to disable
> it until we get a request from some real case. So up to you and Kostya.

OK

Reviewed-by: Vladimir Davydov <vdavydov at virtuozzo.com>