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

Leonid.I · 2013-01-26 05:00:00

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)

Allan · 2013-01-26 07:56:12

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

Leonid.I · 2013-01-26 18:12:05

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

Allan · 2013-01-26 22:23:56

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

JGC · 2013-01-28 19:45:48

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.

Allan · 2013-01-28 23:11:17

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...

JGC · 2013-01-29 00:19:43

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.

Snowman · 2013-01-29 14:11:26

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

JGC · 2013-01-30 16:11:18

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.

Arch Linux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Board footer