GCL and SELinux: help requested

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganjerry@xxxxxxxxx> wrote:
> I don't believe that anybody looks at those pull requests on a regular
> basis.  Should somebody be doing so?  There are 8 pull requests,
> dating back to about the time of the above conversation.  Five of
> those don't contain a single comment.
>
> I opened one for gcl on July 29, and added a comment a month later
> asking if somebody was going to look at it.  No response.  This is a
> bit annoying, considering that I opened a bugzilla request asking for
> the same thing 4 years ago, and no action has ever been taken on it.
> I thought maybe a PR would finally get something to happen.

Nearly a week has gone by, and no answer.  I'm really stumped about
what to do.  Let me summarize the whole long saga and solicit help.

GCL is a Common Lisp implementation.  It is known for its speed
compared to other CL implementations.  It has a long lineage,
summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp.  I
took over maintenance of the package in late 2008 when the previous
maintainer did not have time to continue.  At that point, the package
did not build in Rawhide and was slated to be dropped from Fedora
soon.  I got it working with help from upstream and Daniel Walsh, who
provided advice on putting together an SELinux policy to account for
the fact that GCL produces executable code on the fly by calling
mprotect on selected pages.

Fast forward to 2013.  By that time, the GCL policy also had to
mention maxima executables, since executables built with GCL also use
the GCL memory allocator.  I figured that meant it was time to merge
the GCL policy into the system policy, and consequently opened a
bugzilla ticket.  In spite of me trying to reboot the conversation a
couple of times, those involved who held the SELinux reins for Fedora,
Just.  Could.  Not.  Stay.  On.  Topic.  We talked about the execheap
permission in general, and its place in the universe.  Some of them
sneeringly, condescendingly wondered why upstream and I were both so
incompetent that we didn't just rewrite the allocator to use mmap.
(Hint: it isn't easy, and upstream isn't interested in the exercise.)
After multiple failures on my part to get something to happen, I gave
up in despair.

Fast forward to 2017.  Attempts to build maxima with gcl on aarch64
started hanging at package install time.  See
https://bugzilla.redhat.com/show_bug.cgi?id=1435395.  This was blamed
on gcl, incorrectly I believe.  As I pointed out in the bug, nothing
built from gcl sources runs at package install time, so the hang must
be happening inside one of fixfiles, semodule, or restorecon, which
ARE run from the gcl install scripts because GCL has to install its
own SELinux policy, due to that policy not being merged into the
system policy.  So, policycoreutils maintainers!  Something Is Afoot
on aarch64!

But that's not the end of the fun.  GCL failed the mass rebuild this
summer.  It built successfully on every architecture but s390x.  On
s390x, the build failed due to a failed call to mprotect(), almost
certainly a sign that SELinux was in enforcing mode on the builder.
Was that a known issue with s390x builders?  And, if so, has it been
rectified since?  If so, I'll try building again.

I still want the system policy to account for GCL, in some way or
another.  But, as you can see from the quoted text above, submitting a
pull request to the relevant git repository has resulted in months of
<crickets chirping>.  And pointing that out on this list last weekend
has resulted in still more of the crickets.

So ... what is a packager supposed to do????  Why is it so hard to get
any attention for submissions to the system SELinux policy?  There
should be a barrier to entry; I understand that.  But I can't even get
the gatekeeper to have a conversation with me.  Heeeeellllllppppp!!!

Frustratedly yours,
-- 
Jerry James
http://www.jamezone.org/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux