LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Managing the aaa_elflibs package (https://www.linuxquestions.org/questions/slackware-14/managing-the-aaa_elflibs-package-4175537158/)

drmozes 03-18-2015 03:42 PM

Managing the aaa_elflibs package
 
Hello

Apparently there is some confusion around upgrading the aaa_elflibs package.

I had collated notes from Patrick about 10 years ago, which were correct at the time but the use of the aaa_elflibs package has changed since then. The package now can and should now be upgraded at certain points.

I have updated the document and it has been reviewed by Patrick.
http://www.slackware.com/~mozes/docs/aaa_elflibs.txt

ReaperX7 03-18-2015 03:57 PM

Everything but the directory package can be updated. I usually snag aaa_elflibs myself without penalty. It's aaa_base you NEVER EVER touch... which brings a good question, why is aaa_base even version controlled at all?

T3slider 03-18-2015 04:34 PM

Quote:

Originally Posted by ReaperX7 (Post 5334294)
Everything but the directory package can be updated. I usually snag aaa_elflibs myself without penalty. It's aaa_base you NEVER EVER touch... which brings a good question, why is aaa_base even version controlled at all?

aaa_base mostly extracts empty directories over the existing filesystem, which won't clobber anything but will reset permissions to their defaults (which, unless you've been mucking things up, shouldn't be any different anyway). It may include new directories that did not exist in a previous version of Slackware. It includes /etc/os-release and /etc/slackware-version, which should always match the version of Slackware you are running or scripts that depend on this information may choke (slackpkg parses this but I'm not sure if it actually uses it, but third-party scripts like sbopkg do).

Thus, I must conclude that, contrary to your advice, aaa_base should *always* be updated following very much the same instructions as for aaa_elflibs in the OP -- do not upgrade aaa_base from -current if you are and will continue to be running a stable release because it may throw /etc/slackware-version out of whack, but do upgrade from version to version and keep up to date in -current (not that this will have much of an effect until the version gets bumped in an rc).

ReaperX7 03-18-2015 09:56 PM

I'm surprised that this package doesn't receive something as trivial as a patch if you run -Current, rather than a set release number if you run RTM. A patch ran against the system could add any missing directories with sed arguments made for any specific files that check for version controls, and updates as necessary using if/else. That wouldn't reset permissions, but it would keep aaa_base up-to-date without touching anything heavily. Plus, wouldn't it better better to have aaa_base listed as a dated file rather than a version file such as aaa_base-20150317-x86_64-1.txz? I don't see where new directories would be worrisome as most packages create directories as needed themselves.

Didier Spaier 03-19-2015 04:05 AM

This thread is intended to provide an information about aaa_elflibs, useful for people who upgrade to -current and follow its evolution. It would save readers' time to stick to that topic.

the3dfxdude 03-20-2015 11:24 AM

So I came back to this again, even though for years, I understood the package, realizing I do not remember any instance of a security update for the aaa_elflibs. Does something need to be said here?

Basically, on "Stable Slackware releases", security updates would be similar but slightly variant of drmozes rules. Meaning, since the aaa_elflibs package is not updated, but the actual library package is, then the user must update the actual library package, and never reinstall aaa_elflibs. An example I found of this is that Slackware 8.1 the pcre package had a patch version, but then elflibs as it was then called was not updated. So if sticking with 8.1, just make sure you never reinstall elflibs--no big deal. That covers part of it. If on -current, following the rules of the "rolling" -current, then you are fine there too for security updates.

But what I am wondering is what happens for stable slackware if there is a security vulnerability in an superceded library version, that is still provided with aaa_elflibs for compatibility reasons? If I can remember a point which this happened, I would go with that as an example, but I can't. My guess is that if aaa_elflibs needs a patch rolled out, the libs will have to be snapshot to the latest in the stable version, and at that time, if aaa_elflibs is upgraded to or installed first, then it is okay. Same as -current really.

genss 03-21-2015 03:12 AM

the libraries in aaa_elflibs are from other packages
libz, libncurses, libelf, etc.

GazL 03-21-2015 07:04 AM

It's possible/likely that any legacy libraries that are included only in aaa_elflibs are not even supported upstream anymore, which may be why we never see updates show up.

The implications of aaa_elflib are something that those who don't do 'Full' installs might want to keep in mind: you might end up missing an update should a package you don't have installed show up in patches/.

Interesting observations 3dfx. I hadn't previously considered any of this.

the3dfxdude 03-21-2015 09:32 AM

Quote:

Originally Posted by genss (Post 5335481)
the libraries in aaa_elflibs are from other packages
libz, libncurses, libelf, etc.

Yes, that was my first part of my point. My general point is that more might need to be said about how security updates are handled.

1) On stable slackware, aaa_elflibs should never be reinstalled, otherwise you might get vulnerable libraries back on the system, and a false impression of the patch still installed.

2) If a patch to aaa_elflibs had to be released (assuming upstream has not completely abandoned or Pat applies a contributed patch), then it would have to be updated first, in order, and then follow stable rules again. This is my guess, since I do not remember an example.

55020 03-21-2015 10:05 AM

Quote:

Originally Posted by the3dfxdude (Post 5335211)
But what I am wondering is what happens for stable slackware if there is a security vulnerability in an superceded library version, that is still provided with aaa_elflibs for compatibility reasons? If I can remember a point which this happened, I would go with that as an example

With dynamic libraries, executables should not use the exact library name; they should use the major version of the library name, which is symlinked to the exact library. When a Slackware a package is installed or updated, the doinst.sh will create the right symlinks.

The example you are looking for is freetype; libfreetype is in the original aaa_elflibs_14.1, and freetype got a security patch on 17-Jan-2015.

aaa_elflibs-14.1-x86_64-3 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.0.1-x86_64-1 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.5-x86_64-1_slack14.1 contains usr/lib64/libfreetype.so.6.11.4

Before the patch:
Code:

lrwxrwxrwx 1 root root    21 Dec 11  2013 /usr/lib64/libfreetype.so -> libfreetype.so.6.10.2
lrwxrwxrwx 1 root root    21 Dec 11  2013 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2

After the patch:
Code:

lrwxrwxrwx 1 root root    21 Jan 29 10:12 /usr/lib64/libfreetype.so -> libfreetype.so.6.11.4
lrwxrwxrwx 1 root root    21 Jan 29 10:12 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.11.4
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 614576 Jan 13 22:22 /usr/lib64/libfreetype.so.6.11.4

In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.

the3dfxdude 03-21-2015 10:49 AM

Quote:

Originally Posted by 55020 (Post 5335571)
With dynamic libraries, executables should not use the exact library name; they should use the major version of the library name, which is symlinked to the exact library. When a Slackware a package is installed or updated, the doinst.sh will create the right symlinks.

The example you are looking for is freetype; libfreetype is in the original aaa_elflibs_14.1, and freetype got a security patch on 17-Jan-2015.

aaa_elflibs-14.1-x86_64-3 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.0.1-x86_64-1 contains usr/lib64/libfreetype.so.6.10.2
freetype-2.5.5-x86_64-1_slack14.1 contains usr/lib64/libfreetype.so.6.11.4

Before the patch:
Code:

lrwxrwxrwx 1 root root    21 Dec 11  2013 /usr/lib64/libfreetype.so -> libfreetype.so.6.10.2
lrwxrwxrwx 1 root root    21 Dec 11  2013 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2

After the patch:
Code:

lrwxrwxrwx 1 root root    21 Jan 29 10:12 /usr/lib64/libfreetype.so -> libfreetype.so.6.11.4
lrwxrwxrwx 1 root root    21 Jan 29 10:12 /usr/lib64/libfreetype.so.6 -> libfreetype.so.6.11.4
-rwxr-xr-x 1 root root 593032 Jul 10  2013 /usr/lib64/libfreetype.so.6.10.2
-rwxr-xr-x 1 root root 614576 Jan 13 22:22 /usr/lib64/libfreetype.so.6.11.4

In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.

Well that is not what I am looking at. It is a interesting scenario I have seen, but not my concern.

So you point out a trivial case, that works in the described rules no matter what happens since the files are differently named. If you look at the pcre patch case from Slackware 8.1, it kept the exact same file version number before and after the patch. This means that a reinstall of elflibs would overwrite the exact file, causing an unintended downgrade.

In my other question, my concern is with libs that have a major number version change, and use specially named libs. An example of these are jpeg6, png12, db-3, etc that their obsolete versions were kept around for some time after the specific lib package was dropped.

T3slider 03-21-2015 11:45 AM

Quote:

Originally Posted by 55020 (Post 5335571)
In this scenario, any executable that used libfreetype.so.6.10.2 instead of libfreetype.so.6 might as well be statically linked, and it would have the same security problem that a statically linked executable would have. And that is why there should not be any such executables. However, by keeping the old file libfreetype.so.6.10.2, Slackware ensures that any such executables are not broken and will still work, even though they don't benefit from the patch. And that is why the aaa_elflibs package does not get patched.

Quote:

Originally Posted by GazL (Post 5335523)
The implications of aaa_elflib are something that those who don't do 'Full' installs might want to keep in mind: you might end up missing an update should a package you don't have installed show up in patches/.

If you don't have the freetype package installed, the old vulnerable library will still be installed on the system (thanks to aaa_elflibs) and a patched version will never be installed. So as GazL points out, unless you have a full install, the dynamic nature of library versioning won't matter -- you don't get a patch to aaa_elflibs and therefore you will remain vulnerable. A proper solution would be to rebuild aaa_elflibs, keeping the old freetype version around but also including the new one. Then your description would be appropriate for both full installs and partial installs. As of now, this only happens when a new stable version is released (or once in a while when necessary in -current), but never during the lifetime of a stable release.

drmozes 03-22-2015 12:57 PM

I have updated the doc with how to manage it from a security point of view. If you do a full installation of Slackware then the contents of that package will be overwritten by upgrading to a newer patch package of that owns an affected library.
The remaining 7 (at present) libraries would not receive any security updates since they are only provided by aaa_elflibs. In this case if you were really concerned, you might want to determine whether they're still needed and move them out of the way.

the3dfxdude 03-22-2015 05:07 PM

Thanks for the update.

rworkman 12-23-2015 01:59 AM

It's now worth noting that aaa_elflibs is no longer blacklisted in the default slackpkg configuration, so hopefully this entire post will slide into irrelevance once 14.2 is released :-)


All times are GMT -5. The time now is 07:46 AM.