Date: Wed, 20 Jun 2001 10:23:32 -0400 From: "Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca> To: Jordan Hubbard <jkh@osd.bsdi.com> Cc: alex@big.endian.de, jhb@FreeBSD.ORG, richy@apple.com, libh@FreeBSD.ORG, will@physics.purdue.edu Subject: Re: packagetool.tcl Message-ID: <3B30B1E4.80909@lmc.ericsson.se> References: <3B2FAA21.4020307@lmc.ericsson.se> <20010619161234.Q65489@bohr.physics.purdue.edu> <20010619231951.B4230@zerogravity.kawo2.rwth-aachen.d> <20010619142832K.jkh@osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan Hubbard wrote: > It's a good goal, but don't be surprised if you end up having to > compromise a fair bit in achieving it. You can't simply "wrap" > old packages because they suffer from several problems: Well, let's see here. > 1. The PLIST and other descriptive meta-data in old packages > is a significant subset of the libh meta-data, and you may > not find it to be expressive enough in all cases to get close > enough to a 1-to-1 mapping for an old package to work as a new > package. Of course. But we don't want that. What we want is *libh* to be expressive enough to understand plists. :) Of course some things will be missing, but these will have to be created or converted as libh packages will be created themselves. I'm not sure I follow you here. We don't want the old package system to be compatible with the new one. But we would probably want the new one to be compatible with the old one, ie. that it could at least *understand* it. > 2. The PLISTs allow arbitrary executables and scripts to be run > as part of their actions. For some arguments that a PLIST entry > wants to pass to system(3), like mv(1) or cp(1) lines, you may > be able to convert it to a plausible TCL command which will then > be appropriately checked against the package or system's > current security policy. This you can probably do in 70-80% of > the cases if you're willing to put in the work of parsing the > PLIST arguments. This shouldn't be a problem. I tried to implement a hacky perl script to cleanup /var/db/pkg of duplicate packages that parsed +CONTENTS files and I found that in most cases, the lines are quite simple. The "@-directives" are not that common. > The others will have to be rejected because > a very STRONG part of libh's advertised feature set is that the > administrator now gets total control over what a package will > attempt to do to their system. Not necessarly. Since we would have a much more interactive and integrated package system, we could just *warn* or *ask* the user precisely what he wants to do with specific directives. The package would do *exactly* as told. > You can't simply propagate > arbitrary shell commands forward or you've seriously violated > the trust model. Indeed. But you can *ask* the user to confirm or refuse a specfic command or the review the ones that are about to be started. I mean what are we talking about here, in pkg_add... @exec and @unexec tags? Is that it? Most of the time, these are used for silly info(1) things, IIRC. I don't think there's that much scripting around, except for packages adding users and stuff like that. Maybe we could just display the @exec line and tell the operator to go do it himself because our trust model doesn't allow it, and indeed, shouldn't have this functionality at all. :) > In that respect, it would be better for > old packages to stay in their old format so that the admin > has to explicitly run pkg_add(1) instead and know that in so > doing, [s]he's back in the bad old world of no seat belts. Well, that's a sad world, isn't it? ;) I think that given an arbitrary package, we could: - handle as much as we could "securely" through some kind of translation between the old format and libh's (that would be what, 80, 90% of the package's functionality getting translated correctly?), - warn the user that the package isn't completely setup, if it's really the case (which should be only 20-30% of the packages, by your figures) and, - maybe output residue (what left of the package, the "insecure" part) of the old package in a pkg_add format for the user convenience or, - give the user directives to complete the installation (as in "the package require me to execute this command, but I do not know what it means, so please do it yourself"). Then we would have the best of both world. Old packages that are libh compatible would get happily converted, and old rebel packages would get partly converted with a happy pkg_add hack. What do you people think? -- Antoine Beaupré Jambala TCM team Ericsson Canada inc. mailto:antoine.beaupre@ericsson.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B30B1E4.80909>