In message <[EMAIL PROTECTED]> you wrote: ... >>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.
Actually you're assuming that package maintainers' scripts have bugs while the "standard" one doesn't. IMO what happens is that you introduce a single point of failure -- the standard script. ( One can argue both ways here, you see. Anyway, that's all a side note.) ... > 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. Which is even worse, in a sense -- they waste a whole disk block each, using only a few bytes in it. ... >> 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". It's not the point. The point is, there's a 20 MB read-only /, and the rest is NFS-mounted (for example), and NFS server is down. Bummer. I mentioned /etc simpy because it was the one more packages use; there's also /bin, /sbin, /lib, /dev, /initrd... Packages that need to modify these should be clearly marked as requiring more attention than the others -- "required packages in section base", perhaps? ;-) ... > If you don't want extra security, you don't have to have it. No, I don't want extra security on a single-user box with a dialup network connection. I also want my Debian system to fit on 212 MB hd and run on a 486-66. (And a pot of gold would be nice, thanks.) ;-) ... > 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.) You misunderstood: when a package screws up my system I file a bug report -- not a patch -- and start crying on the Usenet. I didn't mean that "us users" fix bugs and generate patches (not that this is really the case.) Anyway, that is actually what I meant when I said about trust -- if you want to go through the code, you should start with the source for the package you're installing. So it's Perl, awk, sed, shell of various flavours, C, C++, Elisp, Java... Machine codes (for eg. Netscape.) You have to stop somewhere. ... > 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. Linux' security is in its openness, as you well know (I think the "bliss -uninfect_files_please" (or whatever) got to Usenet before McAffee "discovered" bliss.) That and bugs in installation scripts are separate issues. ... >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. I agree, in theory. I just can't see that your method of doing that is feasible -- you've got to change the whole package management system, substantially change filesystem layout, change programs (like ls, file and others that will undoubtedly pop up); note that the last two are covered by standards -- FHS (?) and POSIX resp. As I pointed out, all these changes minimize the damage caused by bugs in installation scripts; they don't help with bugs in the packaged applications, viruses in packaged binaries and so on. You're proposing to invest a lot of time and effort into a rather minor stage in package development process. Of course, all of the above is IMO only. Also, IMO, we could try to implement a capability-type system where dpkg matches install-script's key against locks on each file the script tries to modify (stored in /var/lib/dpkg/info/<package>.list, possibly, or Contents.gz.) This would be quite inefficient, of course, but then lock-key capability systems usually are. -- Dimitri ------- sig: "By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meet the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or $500, whichever is greater, for each violation." (Solicited advertisements <huh?> and other such can be sent to emaziuk at curtin.edu.au)