Bug report on yate-core: accfile.yate crashes with exit status 139

[Tzafrir Cohen]

On Thu, Jun 27, 2013 at 01:04:30PM +0200, Jeroen Dekkers wrote:
> At Thu, 27 Jun 2013 12:21:33 +0300,
> Tzafrir Cohen wrote:
> > On Thu, Jun 27, 2013 at 11:26:54AM +0300, Paul Chitescu wrote:
> > > On Linux the Yate modules are ELF shared objects and they are marked 
> > > executable by the linker. However, they are placed away from $PATH in a 
> > > separate subdirectory so noone should try to execute them directly.
> > > 
> > > Note that there are platforms where security rules dictate a shared object is 
> > > not loaded if it's not marked executable so please leave them untouched.
> > 
> > What platforms? How do other programs with loadable modules deal with
> > it?
> 
> There is apparently a policy difference between Red Hat and Debian, a
> quick search returned this thread:
> 
> https://lists.fedoraproject.org/pipermail/devel/2011-March/149822.html
> 
> My guess is that the debian tools that normally take care of making
> sure the shared objects have proper permissions don't work because
> yate modules have a .yate extension instead of .so.

So what I gather from that thread: most libraries should not be
executable. Libraries like libc is a special case (someone noted there
that there were 3 executable libraries on his /lib that didn't segfault).

The thread also doesn't really answer the question. I asked where the
executable permission is actually needed (rather than mandated by policy
for compatibility).

Tom Lane writes there:

| I don't know all that much about the conventions for this under Linux,
| but I'm familiar with other Unix-oid platforms where shared libraries
| *must* have execute permission or they flat out don't work.  (HPUX is
| that way for sure, and I think most BSDen as well.)

I don't have access to any HP/UX system. On the single BSD system I
have access to:

[tzafrir:~]$ uname -a
NetBSD sdf 6.0.1 NetBSD 6.0.1 (SDF61) #0: Mon Jan 16 18:14:29 UTC 2012
root at ol:/src/sys/arch/amd64/compile/SDF61 amd64

[tzafrir:~]$ ls -l /lib | grep -v ^l
total 10236
-r--r--r--  1 root  wheel  1440465 Dec 21  2012 libc.so.12.181
-r--r--r--  1 root  wheel    30961 Dec 21  2012 libcrypt.so.1.0
-r--r--r--  1 root  wheel  2281448 Dec 21  2012 libcrypto.so.8.0
-r--r--r--  1 root  wheel   131899 Dec 21  2012 libdevmapper.so.1.0
-r--r--r--  1 root  wheel   198870 Dec 21  2012 libedit.so.3.0
-r--r--r--  1 root  wheel   113398 Dec 21  2012 libevent.so.3.2
-r--r--r--  1 root  wheel    54170 Dec 21  2012 libgcc_s.so.1.0
-r--r--r--  1 root  wheel    66979 Dec 21  2012 libipsec.so.3.0
-r--r--r--  1 root  wheel    36006 Dec 21  2012 libkvm.so.6.0
-r--r--r--  1 root  wheel     7266 Dec 21  2012 liblzf.so.0.0
-r--r--r--  1 root  wheel   162217 Dec 21  2012 liblzma.so.1.1
-r--r--r--  1 root  wheel   160005 Dec 21  2012 libm.so.0.10
-r--r--r--  1 root  wheel    25287 Dec 21  2012 libppath.so.0.0
-r--r--r--  1 root  wheel    83022 Dec 21  2012 libprop.so.1.1
-r--r--r--  1 root  wheel    25572 Dec 21  2012 libradius.so.4.0
-r--r--r--  1 root  wheel    74774 Dec 21  2012 librumpclient.so.0.0
-r--r--r--  1 root  wheel    61635 Dec 21  2012 libterminfo.so.1.0
-r--r--r--  1 root  wheel   102071 Dec 21  2012 libutil.so.7.19
-r--r--r--  1 root  wheel    88200 Dec 21  2012 libz.so.1.0

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com