[Monetdb-developers] Security & usability

Fabian Fabian.Groffen at cwi.nl
Sun Apr 4 19:26:26 CEST 2004

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 

> 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.

More information about the developers-list mailing list