On Thu, 2004-02-05 at 16:44, Benoit des Ligneris wrote: > I agree with you that it may be "overkill" at this time. However, I'm > afraid that it will became "messy" and difficult to maintain at this > time especiall if shortcuts for a given table/package can be created by > others.
It is not in the slightest way difficult to maintain. I didn't put it in, but it's trivial to add code to make sure that a package can't modify other package's shortcuts or tables/fields that are already in the database, and to insure that a package can always create/modify it's own shortcuts/tables/fields even if some other package previously created/modified them in the database first. > If we think of shortcuts as a library to acces the data then maybe > the shortcut should be provided by the package "responsible" ? No, I will not limit it that way. I will, if there are any problems with packages stomping on other packages name spaces, insure that a package is the final authority on it's own name space during the reading in of config.xml files. I want other packages to be able to create database fields in the pfilter database table package_pfilter_services_default for instance named something like PACKAGE_service_filtered so that pfilter can look through the database and find all the ones created by other package that need to be added or used in pfilter configuration. > In case of structural change, it is highly preferable to have shortcuts > concerning a given tables at the same location especially with > distributed packages that you have no control on... Again, a package will always be the ultimate authority on it's own name space that is imported from config.xml files. But I will not limit the capability of other packages to add things to that name space. This whole debate only applies to the process by which package config.xml files are processed once each to initialize certain shortcuts/tables/fields in the database. Once things are past that, any user/package that is root can change anything in the database that it wants. They can add, delete, rename, modify tables, fields, and field values. There is no possible/practical way to prevent root on a standard kernel linux machine from doing anything it wants to a database on that machine. Not without severe limitations imposed on the database. As there is no practical way to prevent a software package from wiping out important system directories and files as long as it is running as root. > Everyone is running as root yes but it should be possible to add some > "introspection" to the packages so that oda can know which package is > calling oda ? Impossible, un-needed, and useless. Users call oda, packages are run under user ids which in our case will probably always be root. You are confusing oda with the separate perl script that is only used to read in the config.xml package files once during cluster/package installation. One does not control the other. -- Neil Gorsuch <[EMAIL PROTECTED]> NCSA ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
