You are not logged in.

#1 2013-01-26 05:00:00

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

[SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

I understand that this is mostly cosmetic in Linux (shared libs don't have to have 755 permissions), but still... acl in [testing] removes executable bit from its libraries which now become 644. Is it intentional?

Thanks in advance.

Last edited by Leonid.I (2013-01-26 18:12:23)


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#2 2013-01-26 07:56:12

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Most libraries should not have the executable bit set and upstream acl does not set them.

For an example of a library that should have them set, run /usr/lib/libc.so.6

Offline

#3 2013-01-26 18:12:05

Leonid.I
Member
From: Aethyr
Registered: 2009-03-22
Posts: 999

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Cool... thanks. Although I had an impression that arch packages (samba for instance) usually manually set 0755 permissions on libraries...


Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd

Offline

#4 2013-01-26 22:23:56

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Yeah...  it is not necessarily right though...

Offline

#5 2013-01-28 19:45:48

JGC
Developer
Registered: 2003-12-03
Posts: 1,664

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Shared library permissions depend on what system they are installed to. On unix systems, the executable bit determines if a library can be loaded and executed, so there the +x bit has to be set, otherwise applications using it will coredump.
On linux systems, permissions don't matter. There's several different policies depending on the linux distribution used:
- Debian: if you execute shared libraries, you get crashes because the libraries don't define main(). As crashes are bad, theire policy defines that executable shared libraries (besides libc.so.6 and the ld-linux linker) are not allowed.
- Fedora/Redhat: their packaging tools depend on libraries being executable, so their policy is to make shared libraries executable

Now our policy seems to be: just ship whatever upstream decides it should be. If the package has a debian-origin this means 644, if it's from somewhere else this means 755. IMHO we should make up a policy here instead of mixing things from various upstreams.

Offline

#6 2013-01-28 23:11:17

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,365
Website

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

JGC wrote:

Now our policy seems to be: just ship whatever upstream decides it should be. If the package has a debian-origin this means 644, if it's from somewhere else this means 755. IMHO we should make up a policy here instead of mixing things from various upstreams.

I see this as a case of "does not matter" and we should leave upstream as god...

Offline

#7 2013-01-29 00:19:43

JGC
Developer
Registered: 2003-12-03
Posts: 1,664

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Which means that our distribution changes into a terrible inconsistent nightmare after a while.

The default for autotools is to install shared libraries as 755. The default for CMake is to check if it's running on Debian or something else and install it as 644 in case of debian and 755 in case of something else. Next thing is rules in CMake that checks for Archlinux, then its packager and try to guess what the packager prefers.

Leaving upstream as god is not sane here, there should be rules for such a simple thing as library permissions.

Offline

#8 2013-01-29 14:11:26

Snowman
Developer/Forum Fellow
From: Montreal, Canada
Registered: 2004-08-20
Posts: 5,212

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

I'm not sure but I believe namcap complains if shared libraries are not 755.

Offline

#9 2013-01-30 16:11:18

JGC
Developer
Registered: 2003-12-03
Posts: 1,664

Re: [SOLVED] acl 2.2.51-3 ships libacl.so.1.1.0 with 644 permissions

Namcap only complains about static library permissions, it doesn't complain about shared libraries. I guess you could just install them as 777 if you want, namcap won't complain.

Offline

Board footer

Powered by FluxBB