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.

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

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.

I think that burden should be on the package manager, not the package.

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

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.

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.

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?

Yay! Woohoo! Yipee! Somebody finally wrote lose rather than loose! :D

AFAIK, only removepkg does a check if a file exists in another installed package and skips removing it if it does.

That's why I said
Of course it should overwrite the files from the old package when it gets upgraded.

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.

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.

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.

Okay, but upgradepkg calls removepkg? :)

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

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.

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.

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