[Monetdb-developers] Security & usability
After the checkin by Martin (about giving -u and -P default values on MapiClient), I had to laugh loudly for a minute (or two) after which I had to frown, thinking about the security aspect of this change. Not that it changes much, but being a little minded towards a better situation is not a bad thing IMHO. (Also for the reputation of monet by itself for the outside world)
Because I regularly get tired of typing long command line arguments as well, I propose the following solution, which might fit all kinds of tastes.
What if we would store some preferences we have in a file ~/.monetdb or something which can be shared by various applications, like MapiClient, JdbcClient, Mserver itself, and maybe any more...
The file would be simply a properties file containing something like username=monetdb password=monetdb language=sql startscript=~/monetdb/start_sql
which would instruct MapiClient to use sql language with username + pass monetdb and tell Mserver when it starts to load the script ~/monetdb/start_sql so I for instance would not have to type 'module(sql_server);' anymore.
Of course command line options override these defaults in this .monetdb file. It is up to the user to chmod it to 600.
How about this idea?
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.
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 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]
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.
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
Fabian wrote:
After the checkin by Martin (about giving -u and -P default values on MapiClient), I had to laugh loudly for a minute (or two) after which I had to frown, thinking about the security aspect of this change. Not that it changes much, but being a little minded towards a better situation is not a bad thing IMHO. (Also for the reputation of monet by itself for the outside world)
Because I regularly get tired of typing long command line arguments as well, I propose the following solution, which might fit all kinds of tastes.
What if we would store some preferences we have in a file ~/.monetdb or something which can be shared by various applications, like MapiClient, JdbcClient, Mserver itself, and maybe any more...
The file would be simply a properties file containing something like username=monetdb password=monetdb language=sql startscript=~/monetdb/start_sql
which would instruct MapiClient to use sql language with username + pass monetdb and tell Mserver when it starts to load the script ~/monetdb/start_sql so I for instance would not have to type 'module(sql_server);' anymore.
Of course command line options override these defaults in this .monetdb file. It is up to the user to chmod it to 600.
How about this idea?
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
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.
After the checkin by Martin (about giving -u and -P default values on MapiClient), I had to laugh loudly for a minute (or two) after which I had to frown, thinking about the security aspect of this change. Not that it changes much, but being a little minded towards a better situation is not a bad thing IMHO. (Also for the reputation of monet by itself for the outside world)
Because I regularly get tired of typing long command line arguments as well, I propose the following solution, which might fit all kinds of tastes.
What if we would store some preferences we have in a file ~/.monetdb or something which can be shared by various applications, like MapiClient, JdbcClient, Mserver itself, and maybe any more...
The file would be simply a properties file containing something like username=monetdb password=monetdb language=sql startscript=~/monetdb/start_sql
which would instruct MapiClient to use sql language with username + pass monetdb and tell Mserver when it starts to load the script ~/monetdb/start_sql so I for instance would not have to type 'module(sql_server);' anymore.
Of course command line options override these defaults in this .monetdb file. It is up to the user to chmod it to 600.
How about this idea?
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 . 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 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
participants (3)
-
Fabian -
Martin Kersten -
Stefan.Manegold＠cwi.nl