On Sun, 6 Apr 1997, Dima wrote:
>...
>Aint that simple -- the standard debian-provided script released
>yesterday has to know how to handle a new package I will release
>tomorrow. [...]
Well, actually, my description wasn't entirely complete. The idea is,
you have a set of directories that specify how links are made. For
example:
/usr/packages/<name>/usr/doc <-> /usr/doc
/usr/packages/<name>/usr/lib <-> /usr/lib
/usr/packages/<name>/usr/local/lib <-> /usr/local/lib
/usr/packages/<name>/bin <-> /usr/bin
/usr/packages/<name>/etc <-> /etc
/usr/packages/<name>/etc/ppp <-> /etc/ppp
Thus, all the package needs to do is set up the appropriate directory
structure in its own area and this is mapped to the wider system
in a straightforward fashion. Obviously there are files and
directories that shouldn't be mucked with, like /etc/passwd, which
Debian *already* prompts for before replacing. This would of course
continue.
>Ok, the alternative is that the script uses the information provided
>inside the package, which is precisely what we have now [...]
With the exception that the package doesn't muck with the rest of the
filesystem directly. It has to go through a script with some sanity
checks.
> 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...
As you state, disk space is now pretty cheap. That's not an excuse to
wantonly waste disk a la Microsoft, but symlinks aren't exactly huge.
Almost everyone uses ELF nowadays even though a.out has a very small
performance advantage, and I think the benefit/drawback ratio is about
the same here.
> possibility of symlinks pointing to unmounted filesystems,
Now *here* is a substantial objection. This *does* require careful
attention. The ideal is for /usr to be mountable read-only (as off a
CD), which is why we assumed we'd put the "packages" directory under
"usr".
>[ add more here ] ...
Well, at least one advantage is a *very* quick way to switch between
versions of software. If an upgrade doesn't work, it's pretty quick to
downgrade if the old /usr/packages/<pkgname> directory is still around.
Also, it can simplify the support of multiple architectures. That's how
it's used at work.
Also, customization is simpler. If you go to /usr/packages/<pkgname>,
then everything that has to do with that package is right there. You
don't have to do as much guessing and searching and such to figure out
what files the program needs and where it puts them and so on.
> 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.)
No, the config files still go there, if that's where the software
wants them.
>"Aieee, /vmlinuz is a symlink pointing to /usr/kernel-image/vmlinuz,
>but /usr is not mounted! Not a good day to die!"
A kernel image is a wonderful example of a package that needs a
root-level script to run, to replace /vmlinuz. Some packages *have* to
do fundamental system-level operations. That is entirely clear, thank
you. What we are proposing is minimizing the number of packages that
do that, and mimimizing the number of operations that are performed by
the packages that do.
>> Yes, there are exceptions.
>
>Indeed. Eg. all packages that have system-wide config files have them
>in /etc.
And we have taken that into account, sorry my description didn't make
that clear at first.
>... 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 [EMAIL PROTECTED], why didn't
>I run
>dselect as root in the first place? Where's my nearest RedHat mirror?
If you don't want extra security, you don't have to have it.
Dselect/dpkg can be configured to avoid prompting if it's already
root, or a command-line option can be set up. This is not a reason to
ditch the idea of providing extra security to those that want it. Even
if dpkg is running as root, it can still run the non-privileged
scripts as a less-empowered user to minimize the damage that bugs in
those scripts can cause.
>...
>> 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.
Provided that "us users" learn Perl, etc., so we *can* debug them.
(That same objection applies here too. You can't have it both ways.)
What this offers is (a) clear indications of which packages need more
attention than others, and (b) fewer places that bugs or malicious
code can hide.
Yes, we still need to trust that the actual binaries of the packages
don't have holes or trojan horses compiled in. (Anyone remember the
first Linux version of SATAN?) That's part of why the source packages
are available. If someone wants the extra security, they can have it.
>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.
Even if they are trustworthy (and I agree with you on this, BTW), I
think it's clear that they (and we) are human beings, and therefore
capable of error. (Incapable of perfection?) This framework minimizes
the damage that bugs can cause, and makes major bugs easier to find.
Note that, as Larry Niven pointed out, "There is no cause so noble
that it will not attract its share of kooks." The BLISS virus is an
unfortunate case in point. If Debian becomes as popular as we all
hope, then it will inevitably attract the type of losers who like to
screw up other people's systems. RootKit is available for Linux, now.
I'd prefer that we at least not make it easy for them.
Sincerely,
Ray Ingles (810)377-7735 [EMAIL PROTECTED]
Modern deductive method: 1) Devise hypothesis. 2) Apply for grant.
3) Perform experiments. 4) Revise hypothesis. 5) Backdate revised
hypothesis. 6) Publish.
