Martin Kersten wrote:
Fabian,
I didn;t realize I was a comedian ;-)
The default in most systems is to inherit the user name from the user account. This presupposes a policy to react on any 'new' user, or to first built de user table for any DB you create.
obviously, users need to be added to the database permissions table. In SQL this can be done using CREATE USER or just GRANT ALL ON <table> TO <user> and various commands.
Storing passwords is only safe if you are assured that the identity provides the least possible facilities, e.g. like a guest account. The access permissions are determined at the server side, which means it can simple ignore the 'guest'
Conclusion. Any default guest name embedded in a front-end is safe when the DBA has the right to revoke its grants. (compare with anonymous ftp)
The monetdb:monetdb account is NOT a guest account. It can create tables, and apart from that, if it does, it creates them in the 'sys' schema, instead of the 'default' schema. Everything looks like the monetdb:monetdb account is a full root account, which a client should never default to, since it's password should be resetted also. Under windows you would have a point, since it's normal to leave default passwords like they are there.
The access policy should be consistent over all entry points into the system, which means that authorization as currently in SQL should also apply to MIL interaction.[tobedone]
In fact there would be some kernel access controll object, granting access and tokens and stuff. Well ok, that's a lot of work.
A central, all product client property file is hard to maintain. For example, Mknife contains quite a lot of session info already, while hooking up to AquaDataStudio would lead to double administration.
AquaDataStudio is an external tool, which we don't ship as product. The idea of a .monetdb file is after the .my.conf file for mysql which has exact the same behaviour.
The real solution is that you should always connect the Mserver with the omnipresent 'guest' account, which ships further details for interpretation as part of its startup. Eg, we envisioned that user properties for database interaction could come from the database.
regards, Martin
Good idea. And the file does already exist: it's called "monet.conf", and its default location (on a unix system) is /etc/monet.conf .
If you install it right there, yes, but if you don't... besides that, I don't want that another user can log in using 'my' account and password and/or settings. A system administrator (root) specifies the default configuration, and non-overridable settings, users can change (override) behavioural settings.
There was a lengthy discussion about whether and which (alternative) user default locations to use (~/.monet.conf , ./.monet.conf), but I have to admit, I don't recall the final outcome. In any case, Mserver has the -c/--config option to expicitely specify an alternative monet.conf ; other tools (MapiClient, JdbcClient, etc.) do/should provide a similar set of commandline options and use
Yes, but the main point was that we wanted to avoid typing lengthy command line arguments. b.t.w. synching command line arguments is a good thing, but another discussion.
MonetDB/src/common/monet_options.{mx,py}.in to parse them conveniently. Maybe, we should also add a MonetDB/src/common/monet_options.java.in? ! Let's make sure that we use the same "Look&Feel" for all our tools ! (Which means: If you change one, be sure to keep the others in sync! If you add one, be sure it follows the "rules"!) See MonetDB/conf/monet.conf.in and MonetDB/src/common/monet_options.*.in for further details. Stefan
I prefer all tools reading from the same properties. Just a developers aid, the nice and clean way.