On Fri, 05 Sep 2008 16:54:43 -0400 (EDT) "David A. Wheeler" <dwheeler@xxxxxxxxxxxx> wrote: > Matt Domsch wrote regarding gcl (GNU Common Lisp): > > > >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > > > > I would rather like to let die. It is a pain and does not build > > > > anymore on any architecture. Maybe someone have a try with it? > > From: G?rard Milmeister <gemi@xxxxxxxxxx> > > Tried that too. However that Fedora memory management and security > > features get in the way. > > Dropping gcl is a bad idea. gcl generates much better code in many > cases; dropping makes Fedora bad for running Common Lisp (CL) > applications. There are a lot of CL programs, and CL is still > important; "Practical Common Lisp" was published 2005 and was a > really popular book. > > For example, performance figures for ACL2 are here: > http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance > gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared > to the next-best implementation available on Fedora. > > This may illustrate a larger security issue: > the Fedora memory management/security features appear to > be tuned for C/C++ programs. Unfortunately, > they interfere with running programs written in some other languages. > It's especially silly when the language design prevents the problem > anyway. Take a look at the rant here, where Axiom explains how to run > on Fedora: > http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch > Axiom's solution is completely disable a lot of security functions > for the ENTIRE system, not just for that one program. That's not good. > > I think it'd better to create an SELinux security context that grants > additional memory privileges that can be used ONLY when the > program actually _NEEDS_ those privileges (e.g., it uses > a gcl runtime requiring additional privileges). > You could document a "recipe" for how to create such a > thing would be a good idea - but you'd need to recreate it for > every program compiled by gcl, ugh. I think it'd be better to > have a standard context for this case (the current "unconfined" really > is confined; maybe the new one is "really_unconfined"?). > Having some processes less confined is better than disabling > the security mechanisms for the entire system. This is the approach taken for mono and java, which have similar issues. If you use a context type of java_exec_t for something using the gcl runtime, does it work? Paul. > > --- David A. Wheeler > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
