There's been some discussion on the list lately about the possibility of secure package installation, and whether it's possible, desirable, or practical. Secure installation of Unix software can be complicated, but there are some principles that can simplify things and make it less error-prone and bug-ridden. Scripts to implement safer software installation already exist in the form of "opt_depot." Bob Meier and I plan to investigate the notion of integrating this type of procedure into dpkg/dselect. The following is a sketch of our ideas and a call for comments and suggestions.
Installed packages go to a specific place in the file hierarchy, e.g. "/usr/packages/<package-name>/". There's "/usr/packages/<name>/lib/", "/usr/packages/<name>/bin/", etc. A script then makes symlinks from, say, "/usr/lib/<file-name>" to "/usr/packages/<package-name>/lib/<file-name>". Deinstallation is a snap. All you do is use "find" to track down and remove all the symlinks to "/usr/packages/<package-name>/*", and then remove the "/usr/packages/<package-name>/" directory. Note that these two steps have a very high reliability. You will almost never have extra files laying around because the maintainer forgot to update a removal script. Let us reflect for a moment about the contrast between this and Windows. It also enhances security noticeably. The package maintainer can screw up the whole system because of a buggy script the way things currently stand. Imagine the havok caused by the canonical single-typo error "rm -r / usr/lib/somedir". I'm pretty sure everyone reading this list has run into problems with buggy install scripts. Bugs happen, and we have to try to minimize the problems any one bug can cause. If we use the "/usr/packages/*" method, though, we can separate installation into two steps. The maintainer supplies normal install scripts that handles everything under "/usr/packages/<package-name>/". It runs as, say, user "tool", group "bin". After that's finished, a separate, *standard*, Debian-provided script runs (as root) that sets up the symlinks, and changes the ownership of "/usr/packages/<package-name>" to, e.g., "bin:bin". (Or "root:root", or "<package>:dialout,dip", or whatever is needed.) Thus, a new package cannot affect older, installed packages during installation (they are owned by another user and group, after all). Root's job is simple and well-defined, and pretty hard to subvert. Yes, there are exceptions. Shadow passwords have to muck with /usr/passwd. PPP has to stick a few things in /etc. Mosaic wants to set up three separate directories (one for the software, one for config files, one for documents). Support for installation in more than one directory will be needed. In more complicated cases the maintainer can supply a special script that handles these chores, that will be run as another user, perhaps root. "But wait," you say, "aren't you giving up your security right there?" No, for a couple of reasons. First off, one can determine which packages are most likely to cause system problems simply by asking the question, "Which packages need a specially-privileged pre- or post-install script?" These can then be singled out for special attention. Dselect and dpkg can be set to prompt, "This package requires a script to run as user "root". Do you want to [e]xamine the script, [r]un it, or [a]bort installation?" Second, the riskier, privileged operations are concentrated in easy-to-find areas by design. A maintainer can't scatter them around multiple places in multiple scripts. They are thus easier to find and therefore easier to monitor and debug. (And probably will receive more attention in the first place when they're written.) This dovetails pretty well with the idea of maintainer certification. You can have looser certification for those packages which don't need special installation handling and rigorous certification for those packages which need root access. (This also helps to make a more standard environment for building source-only packages, BTW. Some have called for more of that sort of thing. :-> ) No, this is not a panacea. Bugs will still happen, and security flaws can still be found. But the advantages are clear and, I think, worthwhile. Just knowing that if I uninstall something it won't leave useless files around wasting disk space is wonderful. (How much cruft does the average Windows setup accumulate per year?) Enhanced reliability and security is just a very welcome bonus. (But a *nice* bonus.) This does require revision of dpkg, dselect, and the .deb format. We hope to make the benefits worth the changes. Again, suggestions welcome! Sincerely, Ray Ingles (810) 377-7735 [EMAIL PROTECTED] "Is knowledge knowable? If not, how do we know this?" -- Woody Allen