[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Safer package installation

In message <[🔎] Pine.SUN.3.91.970404133322.21954E-100000@moray> you wrote:
> 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.)

Aint that simple -- the standard debian-provided script released
yesterday has to know how to handle a new package I will release
tomorrow.  So we need to wait for the new version of the script,
then ppl can install my new package, report bugs, then I release
a new version, then we wait for the new version of the script etc.
Multiply by slightly more than 1000, which is the current number
of debian packages.

Ok, the alternative is that the script uses the information provided
inside the package, which is precisely what we have now and the
only benefits of your scheme is a different (read non-standard) 
directory structure and heaps of symlinks -- waste of [nowadays cheap]
disk space, possibility of symlinks pointing to unmounted filesystems,
[ add more here ] ...  And don't tell me I can't exploit the script
to screw up people's systems: it has to modify at least /etc, in addition
to changing symlinks (unless of course we move all the configuration
files from /etc -- nice thing about standards is that we don't have
to follow them.)

"Aieee, /vmlinuz is a symlink pointing to /usr/kernel-image/vmlinuz, 
but /usr is not mounted! Not a good day to die!"

> Yes, there are exceptions.

Indeed.  Eg. all packages that have system-wide config files have them
in /etc.

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

Read: "do you want to suspend dselect, su to root and continue?"
"Do you want to suspend dselect, login as root, install and configure
su and then continue?"  "Do you want to do all of the above, go learn
Perl, examine the script and _then continue?" Oh f@#$, why didn't I run 
dselect as root in the first place?  Where's my nearest RedHat mirror?

> This does require revision of dpkg, dselect, and the .deb format.

And in the end, we will still rely on the very same thing -- that 
people involved didn't insert malicious code in the package, and 
that bugs will be soon found by us users, and promptly corrected.
Your scheme simply removes debian package maintainers from the list
of "people involved".  Since I kinda trust them (have since .93R6),
I don't think it's worth the hassle.

reply to emaziuk at curtin.edu.au
Avoid reality at all costs.

Reply to: