On Fri, 2004-02-06 at 01:56, Benoit des Ligneris wrote: > My concern with this is that if pfilter changes its table structure and > remove the column "protocol" in order to normalize its db structure by > creating a table protocol_id and referring to this id then every > shortcut using the protocol column is broken by this structural > change and you will have to track down every reference to this column in > every config.xml on every package.
If a package has a published database interface, whether it's a shortcut name/parameters, a database table that other packages can add records to, or a naming convention of table names in a package's name space, it's an API and therefore should not be changed. That is the definition of an API. If a package author is dumb enough to change and API and wreck compatibility with other things, yes, it's their problem and responsibility to fix things. > As we are moving toward a distributed packaging system, you have no > control on others packages. > > That's why, for me, having all the shortcuts using/modifying table data > linked to a given package at the same place makes sense... That would be a severe limit that is impossible to enforce. Again, all we are talking about is the conversion of config.xml files. And the name space rights of a package at that time are easily enforceable. But there is no possible way to enforce this after the config.xml files are read in when you have packages running code as the system id root. > One question however, why is oda using the root user of the database ? > Most of the time, one DB user is created by application and this in > order to protect data and db coherency in general. For instance,; if > phpmyadmin is installed, a phpmyadmin user will be created that will > have some reduce rights. > > As such, the root account for the MySQL database should only be used for > "superuser" operations : grant permission, create db, add/remove users > and a regular account should be used for regular operations. This is > very similar to a unix like system way of managing security. You should try a few simple mysql commands before you make wrong assumptions. All oda access is through the database user "oscar" on a database named "oscar". No other mysql database users or databases are impacted in any way by the oda/oscar combination, except, of course, that other people can't make their own "oscar" database or try to use the "oscar" database user in other ways. Oscar packages and glue code use the root system id to initially create the oscar database. After that, anyone with access to the "oscar" database user and password can have fun with the database. The system id root is used to limit which users can trivially do oscar database modifications via the /etc/odapw file that is only readable by root. If we want to get more complicated than that, we can, at a later time, but not now. -- 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
