[Bugs] [Bug 1421649] When using a fuse mount for client, EC volumes do not mount.

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1421649



--- Comment #11 from Xavier Hernandez <xhernandez at datalab.es> ---
(In reply to Siddharth Sharma from comment #7)
> 1. Why does it have to generate dynamic binary at runtime?

Basically because the amount of possible combinations that may be needed to
encode/decode the data is too big (in the order of tens of thousands). On
normal circumstances, only a bunch of combinations are really needed, but in
relatively big configurations, things can fail in multiple ways and all of them
need to be supported though not at the same time (as an example, in a 16+4
configuration, there are 4845 different ways in which 4 of the 20 bricks can
fail, and each combination needs a different matrix to be computed).

It can be done without dynamic code (it has been working this way till
recently) using more generic functions, but the performance is significantly
worse.

The addition of SSE and AVX support makes this problem even worse because it
would need to build specific functions for each of the possible extensions for
each combination.

> 
> 2. Can user be added to group which has permissions to generate this dynamic
> binary and then drop privileges, so there is no chance to escalate
> privileges at any later stage.

I don't think so. The code doesn't really need to be stored anywhere. In a
previous patch it was created only on memory but, because of selinux, it needed
to be stored into a file. The file is volatile though: the code creates the
file and then immediately deletes it, keeping only an open fd. The generated
code only needs to be there while the process is running.

Since creating all possible combinations would be impractical, only the needed
combinations are created as they are needed on run-time, so we cannot create a
file with all the code and then revoke privileges.

> 
> 3. Solution in comment 5 in this bug seems to be fine, but what are the
> effects of re-using pre-compiled code ? That brings me to first question
> 'why dynamic binary generation is required' ?

Well, solution in comment 5 basically disables dynamic code generation if
something fails, so we are at the starting point again. The performance
benefits are lost, though it's true that it works in all cases.

The detailed problem is this:

First solution:

An mmap() call was used to create an anomymous memory area where dynamic code
was generated. It had read/write/execute privileges and it was not backed by
any file. The problem here is that selinux forbids this.

Second solution:

Looking at how some internet browsers solve this problem (they generate dynamic
code for javascript), I tried to use the double mmap() approach, that also
seems to be the recommended solution to support selinux. With this approach I
need a backing file mmapped to two distinct memory regions, one with read/write
access and another one with read/execute access.

This works fine and selinux really allows this, but the problem here is that
the backing file must have the bin_t selinux's type. Otherwise selinux doesn't
allow the file to be mmaped to an executable region.

With the help of Anoop, we found that /usr/libexec/glusterfs has this type set,
so we used it and everything worked fine with selinux activated.

The problem here (I didn't know that) is that this directory can be read-only
in some cases, so it cannot be used. Also, it requires root privileges, while
some gfapi applications may not run as root.

So the questions are:

1. Is there any way to improve security in this approach ?

2. Where can we store the backing file with bin_t type ? Niels proposed
/run/glusterfs for root and /run/<user>/glusterfs for regular users. Is this ok
?

3. Can an selinux policy be distributed with gluster to make the previous
directories of type bin_t ?

Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=6Piaccgw6a&a=cc_unsubscribe