[Gcl-devel] Re: sgc issue

[Camm Maguire]

Greetings!

Piete Brooks <address@hidden> writes:

> > I know of one condition which can cause this -- running under an
> > SELinux box (i.e. certain redhat boxes come with this by default)
> > configured in strict mode.
> 
> It fails on a targeted enforcing FC3 box.
> It works on a disabled FC2 box.
> 

Hmm.  Not sure what 'targeted enforcing means'.  All this todo about
security -- I still wonder why most people don't run and single user
machine behind an IP firewall opening no ports and accepting no
incoming traffic, then using the machine to solve problems, but I am
certainly not the expert in these matters.

> The fault is:
>       mprotect(0x839a000, 126386176, PROT_READ|PROT_WRITE|PROT_EXEC) = -1
>               ENOMEM (Cannot allocate memory)
> 

OK, presumably this is from strace.  The issue I thought of would have
given EACCESS, not ENOMEM.  Is it possible the available memory is
limited on this machine?

> It has been suggested that http://www.gnu.org/software/gcl/ERRATA-2.6.5.html 
> might fix it: "Fedora Core 3 makes brk added pages non-executable by default. 
> This patch ensures executable permissions on all x86 Linux flavors."
> I've not tried it, as we build our RPM from debian (or some such) binaries.
> 

This patch is in recent GCL, and in any case, adds more (not fewer)
such mprotect calls.  Even without this patch and without sgc, GCL
still needs to be able to mprotect heap memory PROT_EXEC.

> > Turning off strict mode (I think 'kickstart' can do this) is a workaround.
> 
> (or tweaking /etc/sysconfig/selinux)
> 
> > There is also likely a less severe but more involved workaround (not yet
> > tested) posted earlier on gcl-devel -- rebuilding the SELinux policy with
> > the memory protect access explicitly granted
> 
> ... just for the acl binary I assume ...
> 
> > (cannot remember the flag name at present, but I can dig it up if you want.)
> (may be useful)
> 

OK, if I'm wrong above and this is indeed a permission issue, will
report this.

> > Most drastically, one can simply disable SELinux, at least temporarily to 
> > test.
> 
> I tried that "setenforce 0" doesn't seem to help :-(
> 

Perhaps a memory limitation, not permission, issue then?

ERRORS
       EINVAL addr is not a valid pointer, or not a  multiple  of
              PAGESIZE.

       EFAULT The memory cannot be accessed.

       EACCES The  memory  cannot  be given the specified access.
              This can happen, for example, if you mmap(2) a file
              to  which you have read-only access, then ask mpro­
              tect to mark it PROT_WRITE.

       ENOMEM Internal kernel structures could not be  allocated.

EXAMPLE


> > Please keep me posted if this does not work.
> 
> Fraid so :-(
> 
> > Alas, there is no workaround at GCL configure time possible for a system
> > which refuses executable memory access, as we load and execute code on the
> > fly all the time.
> 
> The patch URL above overrides the default non-execute access.


Take care, and please keep me posted.


> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah