I think we can take care of this pretty cleanly using existing Keel capability. Currently createdb does not implement Securable. We can change that, and simply put am=nullauth for createdb. As Mike has said, it doesn't do anything harmful, even if run by "unauthorized" users. But if one was concerned with it, after running createdb the initial time, the am attribute could be changed to defaultauth, and createdb will be secured.
Shash
I did not know what its behaviour was in regards to alreday existing tables. If it does not clobber, than not a bad thing. I wonder if an appropriate "lockdown" would be to rig it so that it can only be run from localhost?
Given ASP use of Keel apps (e.g. BahamasCommerce!) that wouldn't work well for me personally. Sometimes I don't visit the server for quite a long time in person :-)
And/or require the system root password as a parameter? I am thinking about what would happen if some kid tried it for a lark.
Essentially it would do nothing, assuming all tables are already there. The only downside would be that if you deleted/dropped some tables it would just put them back again. Ditto with default records in tables - if there's already a record with that key, it does nothing, so it won't do anything nasty like set all your passwords back to default. I suppose it's a risk for a DOS attack, essentially, but not much else.
I'm experimenting with configuring models to require SSL, and in addition to that can require some models to use client-side certif SSL, which might be one way to go. That way there's no way to run dbcreate unless you have a certain client-side certificate - although I wouldn't do it this way by default. The other way to do it would be to simply remove the config for createdb from system.xconf once you've created the tables - then it can't be run by anyone.
Just some thoughts - these issues could apply to many models, I suppose.
Mike
Regards, Steve
Michael Nash JGlobal.com wrote:
Steve:
Good idea to lock the model down, but we'll still need some way to run it as a special exception if you're logging in via the svc-authentication/authorization-persist. Of course, we could use a combo of svc-authentication-config and svc-authentication-persist, that way a basic username for createdb could be right in the configuration.
OTOH, running createdb is pretty harmless, actually - it never deletes anything, only creates it if it isn't there, so it's not the worst in terms of security problems.
Mike
http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
