LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-02-2013, 12:37 PM   #1
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 374

Rep: Reputation: 85
Pkgtool and security


I think there is a need for some added security to pkgtool. It overwrites existing files, it changes ownership and permission on existing directories, and it replaces existing symlinks with directories. A bad package can trash the whole system.

It'd be better if it first checks for file conflicts, and then gives a list of all files that already exist (and doesn't belong to the package that should be upgraded). Add a force flag if the user wants it to overwrite the files, but don't overwrite anything as default. And it should never overwrite existing directories.

I also find it strange that it removes the symlinks from the package and put them in the doinst.sh script. Why? Tar can handle symlinks, and if they are included in the package they are listed as files belonging to the package.
 
Old 07-02-2013, 01:08 PM   #2
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
Use
Code:
# installpkg --warn package.txz
before installation. Or write/find a package checking script (there are some out there already) to verify a package. If pkgtools doesn't overwrite files, then it would be a huge hassle -- packages with files also in aaa_elflibs would need to be forced every time, and installing a package but not installing certain files from the package is a recipe for disaster (ie. breaking the application). pkgtools places the burden of permissions on the package instead of the installer. If you install packages from trusted sources then there shouldn't be a problem.
 
Old 07-02-2013, 01:27 PM   #3
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 374

Original Poster
Rep: Reputation: 85
I know Slackware isn't a newbie distro, but still I think there should be some level of security while installing packages. Overwriting existing files should shouldn't be default.

Of course it shouldn't half-install a package. If there is a file conflict, error out (or list the conflicting files and ask) before starting to install the package.

Quote:
Originally Posted by T3slider View Post
pkgtools places the burden of permissions on the package instead of the installer.
I think that burden should be on the package manager, not the package.
 
Old 07-02-2013, 01:43 PM   #4
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105Reputation: 8105
Simple: do not install packages from an untrusted source. And do not run SlackBuild scripts that come from an untrusted source. Problem solved.
The package manager does only what the admin tells it to. If the admin wants to install a bad package, she probably has a reason for it. Slackware will not try to second-guess you.

Eric
 
4 members found this post helpful.
Old 07-02-2013, 01:54 PM   #5
hitest
Guru
 
Registered: Mar 2004
Location: Canada
Distribution: Void, Slackware
Posts: 7,341

Rep: Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744
With Slackware you have full control over your operating system. With this level of control comes an equal level of responsibility. You are free to screw up your OS by installing buggy software. I only install software from trusted sources like Eric and Robby(see signature). The good people at slackbuilds.org are also fully trustworthy.
 
3 members found this post helpful.
Old 07-02-2013, 03:31 PM   #6
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 2,464

Rep: Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373Reputation: 8373
Quote:
Originally Posted by Lennie View Post
A bad package can trash the whole system.
Such is the nature of all package systems that I've seen. I've yet to come across one that doesn't execute an install script as root, and of course that can do absolutely anything to your system.

The ability to overwrite existing files is necessary in order to do the dance of upgrading a package without making it unavailable during the upgrade process (for packages like coreutils you can imagine it wouldn't work well to lose those commands during the installation). And replacing directories with symlinks is commonly needed to follow the install locations as standards change. Concerning the placement of symlinks in the install scripts: perhaps tar can handle the odd cases now where a symlink needs to replace a directory (or a directory needs to replace a symlink), but it wasn't able to when the install script format was created. Changing it now would break compatibility with existing packages. This is also why the package tools don't use the latest/greatest version of GNU tar -- any change in the output format would break the comparisons between the incoming package and the lists of installed packages in /var/log/packages.

In short, a package system needs to manage your system completely, and to do so it needs full access. Any attempt to restrict what it can do will surely lead to a case where it can't make a required change and is painted into a corner. As AlienBob said, the only security that can really be provided is signing the packages, and the admin should be sure that they trust the source. Installing any package is the same as trusting the packager with your root password, and that is how it has always been.
 
6 members found this post helpful.
Old 07-02-2013, 03:44 PM   #7
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546
Quote:
It'd be better if it first checks for file conflicts, and then gives a list of all files that already exist (and doesn't belong to the package that should be upgraded). Add a force flag if the user wants it to overwrite the files, but don't overwrite anything as default. And it should never overwrite existing directories.
Been a while since I explicitly paid attention, but I believe both upgradepkg and installpkg do indeed check for existing files and directories from other packages.

I have used Slackware for many years. I don't recall a serious package FUBAR in all that time. I do recall some occasions when a package was rebuilt to fix nominal issues, but nothing as serious as you describe. OTOH, not to resurrect dead horses, I have run into many problems when I tinker with other distros with automated dependency checking.

Is there a particular example that prompted your post?

Quote:
...it wouldn't work well to lose those commands during the installation...
Yay! Woohoo! Yipee! Somebody finally wrote lose rather than loose!
 
Old 07-02-2013, 03:56 PM   #8
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
Blog Entries: 2

Rep: Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886Reputation: 4886
Quote:
Originally Posted by Woodsman View Post
Been a while since I explicitly paid attention, but I believe both upgradepkg and installpkg do indeed check for existing files and directories from other packages.
AFAIK, only removepkg does a check if a file exists in another installed package and skips removing it if it does.
 
Old 07-02-2013, 05:07 PM   #9
Lennie
Member
 
Registered: Aug 2012
Location: Sweden
Distribution: LFS, built with pacman
Posts: 374

Original Poster
Rep: Reputation: 85
Quote:
Originally Posted by volkerdi View Post
The ability to overwrite existing files is necessary in order to do the dance of upgrading a package without making it unavailable during the upgrade process (for packages like coreutils you can imagine it wouldn't work well to lose those commands during the installation).
That's why I said
Quote:
It'd be better if it first checks for file conflicts, and then gives a list of all files that already exist (and doesn't belong to the package that should be upgraded).
Of course it should overwrite the files from the old package when it gets upgraded.

Quote:
Originally Posted by volkerdi View Post
And replacing directories with symlinks is commonly needed to follow the install locations as standards change. Concerning the placement of symlinks in the install scripts: perhaps tar can handle the odd cases now where a symlink needs to replace a directory (or a directory needs to replace a symlink), but it wasn't able to when the install script format was created. Changing it now would break compatibility with existing packages. This is also why the package tools don't use the latest/greatest version of GNU tar -- any change in the output format would break the comparisons between the incoming package and the lists of installed packages in /var/log/packages.
The package manager I'm most used to is pacman. Arch has recently replaced directories with symlinks, so that is possible even with symlinks in the package.

Quote:
Originally Posted by TobiSGD View Post
AFAIK, only removepkg does a check if a file exists in another installed package and skips removing it if it does.
I have had crazy experience of this. One package overwrote some files from another package, and when I removed the second package it left the files because another package also used them. Well, those files were not the same, they only had the same name. So I anyway had to reinstall the first package.

Quote:
Originally Posted by hitest View Post
With Slackware you have full control over your operating system. With this level of control comes an equal level of responsibility. You are free to screw up your OS by installing buggy software. I only install software from trusted sources like Eric and Robby(see signature). The good people at slackbuilds.org are also fully trustworthy.
I remember a recent thread when a package from slackbuild.org for 13.37 screwed the system by changing permission of /usr/bin to no access. Even if it was for an older version, it should still be considered trustworthy.

I think the responsibility this puts on the user is way to heavy. I have experienced packages where my user ended up owning everything in the package, and when I installed it it changed ownership of system directories, and the system was foobared. That could never happen with pacman.
 
Old 07-02-2013, 05:11 PM   #10
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546Reputation: 546
Quote:
AFAIK, only removepkg does a check if a file exists in another installed package and skips removing it if it does.
Okay, but upgradepkg calls removepkg?
 
Old 07-02-2013, 05:27 PM   #11
TommyC7
Member
 
Registered: Mar 2012
Distribution: Slackware, CentOS, OpenBSD, FreeBSD
Posts: 528

Rep: Reputation: Disabled
You can put a variable in your SlackBuild scripts saying that it conflicts with certain packages so it won't build (much like the SlackBuild scripts that refuse to build if you don't have a specific user or group). slapt-get has a file for these packages that have conflicts with a certain package in the file:
Code:
$BUILD_ROOT/install/slack-conflicts
Also, I don't know which packages you're installing or what-not, but some people install packages that don't ship with the distribution into /usr/local or /opt/<package name/LANANA provider> as the FHS suggests.
 
Old 07-02-2013, 07:56 PM   #12
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
I really think the solution to the problem is to verify the package before installing with a separate command rather than forcing the issue. Again, scripts exist to do this already (and `installpkg --warn` offers a simplistic, if not ideal, solution as well). By forcing the installer to verify this stuff, it all of a sudden becomes a pain to do certain things. When util-linux-ng was renamed to util-linux, the easy solution was to install util-linux (which would overwrite basically everything from util-linux-ng) and then remove util-linux-ng (which only removes files not present in util-linux). Alternatively you could use `upgradepkg util-linux-ng%util-linux-*.t?z` or something similar, but upgrading through slackpkg (which, when done diligently, installs new packages with install-new, then upgrades packages with upgrade-all, then removes obsolete packages with clean-system) would now be broken since (I believe) it doesn't support the explicit upgrade of a package with a different name.

The current situation works and will only break if you install a broken package (and it is easy to verify a package before installing if you need to). Shoehorning in mandatory verification that must be explicitly disabled to skip it makes things *more* complicated than the current situation, and not less.

If you're afraid of borking your system, just verify packages before installing. Simple as that.
 
2 members found this post helpful.
Old 07-02-2013, 08:48 PM   #13
hitest
Guru
 
Registered: Mar 2004
Location: Canada
Distribution: Void, Slackware
Posts: 7,341

Rep: Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744Reputation: 3744
Quote:
Originally Posted by Lennie View Post
That could never happen with pacman.
An Arch user needs to be *very* responsible when using pacman and keep up with latest announcements. The casual use of pacman -Syu can break a system.
 
3 members found this post helpful.
Old 07-03-2013, 11:47 AM   #14
yars
Member
 
Registered: Apr 2012
Location: Russia
Distribution: Slackware64-current
Posts: 249

Rep: Reputation: 24
I see in a pkgtools only one problem. When you remove the package, if any files was overwritten, you see a warnings about that; these warnings can be see on a middle (or on any another place) of removepkg's output. Of course you can redirect this output in a file, for example, but I think is a good idea to make a summary about skipped files after the package was removed...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
pkgtool does nothing?! alienDog Slackware 8 10-31-2004 05:11 PM
Pkgtool Corallis Slackware 6 09-01-2004 11:49 PM
pkgtool sio Linux - General 0 07-30-2003 12:47 PM
using pkgtool ivans Slackware 2 05-28-2003 09:37 PM
pkgtool ktindle Slackware 4 12-15-2002 04:14 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:28 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration