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

[Cyrill Gorcunov]

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.

	Cyrill