all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: root <daly@axiom-developer.org>
Cc: gcl-devel@gnu.org, emacs-devel@gnu.org,
	Matt Kaufmann <kaufmann@cs.utexas.edu>,
	axiom-developer@nongnu.org, Sandip Ray <sandip@cs.utexas.edu>
Subject: [camm@enhanced.com: Re: [Gcl-devel] Re: unexec and fedora core 4]
Date: Fri, 9 Dec 2005 17:49:50 -0500	[thread overview]
Message-ID: <200512092249.jB9Mnoq03577@localhost.localdomain> (raw)

Emil,

If you can find the SELinux people please tell them to start using
GCL as a test case for their ideas. Apparently they seem to believe
that there is no reason for self-modifying code, executable heap
objects, stack execution, dynamic load/store/link, etc.

We in the lisp community are finding SELinux to be less than useful
and, as you can see, the general solution is to "turn it off".

While I agree with SELinux in principle it seems that every new
release adds yet another mindless breakage. 

The least they could do is issue an advisory bulletin on how to
make lisp work with their new restrictions each month. It would
save us a lot of debugging.

A frustrated maintainer,
Tim

------- Start of forwarded message -------
To: Juho Snellman <jsnell@iki.fi>
Cc: Matt Kaufmann <kaufmann@cs.utexas.edu>, Sandip Ray <sandip@cs.utexas.edu>,
   gcl-devel@gnu.org, emacs-devel@gnu.org, root <daly@axiom-developer.org>,
   axiom-developer@nongnu.org
Subject: Re: [Gcl-devel] Re: unexec and fedora core 4
From: Camm Maguire <camm@enhanced.com>
Date: 09 Dec 2005 16:43:44 -0500
In-Reply-To: <54wtiee1up.fsf@intech19.enhanced.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Content-Type: text/plain; charset=us-ascii

Greetings!

OK, here is what I believe now to be the case -- the SELinux option
allow_execmem, which is 'active' on the bad box, is causing the
problem.  All is well if one takes the drastic action of 

sudo /bin/sh -c "/usr/sbin/setenforce 0"

but will probably allso work if one changes

/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem false;

to

/etc/selinux/strict/src/policy/domains/user.te:bool allow_execmem true;

and 

sudo /bin/sh -c "cd /etc/selinux/strict/src/policy && make load"

though I have not confirmed this not wanting to hose the machine in
question. 

The security people appear to persist in their (IMHO quite erroneous)
assumption that there is no legitimate need for an executable heap.
Tim Daly likely has further thoughts on this, but I saw the comment
again here:

http://copilotconsulting.com/mail-archives/selinux.2005/msg02006.html

Take care,

Camm Maguire <camm@enhanced.com> writes:

> Juho Snellman <jsnell@iki.fi> writes:
> 
> > <camm@enhanced.com> wrote:
> > > Greetings!  I am a developer of GCL, which shares unexec with emacs.
> > > I have noticed on certain recent Fedora Core 4 machines, binaries
> > > produced with unexec cannot mprotect memory (allocated with brk)
> > > PROT_EXEC (returning EACCESS, i.e. permission denied), whereas
> > > binaries output by ld can do so just fine.  This does not vary with
> > > exec-shield or randomize_va_space settings, and appears quite machine
> > > specific.  The same binary which functions perfectly normally on one
> > > fc4 machine shows this failure only on another machine.  I have as yet
> > > been unable to correlate this with dynamic library placement, or other
> > > settings in /proc/sys.
> > 
> > Just a guess, but this might be related to SELinux. Do the machines
> > have differences in /etc/selinux/config?
> > 
> 
> Bingo! (I think)  The config files are identical, but the problem
> machine has a 'strict' subdirectory with a host of files and options.
> Any idea of what I should look for herein, and what this could have to
> do with unexec vs ld?
> 
> Thank you so much!
> 
> > -- 
> > Juho Snellman
> > 
> > 
> > 
> > _______________________________________________
> > Gcl-devel mailing list
> > Gcl-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> > 
> > 
> > 
> 
> -- 
> Camm Maguire			     			camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

- -- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
------- End of forwarded message -------

                 reply	other threads:[~2005-12-09 22:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200512092249.jB9Mnoq03577@localhost.localdomain \
    --to=daly@axiom-developer.org \
    --cc=axiom-developer@nongnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=gcl-devel@gnu.org \
    --cc=kaufmann@cs.utexas.edu \
    --cc=sandip@cs.utexas.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.