Shash:

Of course - that makes much sense, and is even easier. Great idea!

Mike

On Fri, 24 Oct 2003 18:06:02 -0500
"Sasvata (Shash) Chatterjee" <[EMAIL PROTECTED]> wrote:

> Mike and Steve,
> 
> 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


Michael Nash

JGlobal Ltd.
 http://www.jglobal.com

Bahamas Commerce and Trade
http://www.bahamascommerce.com

http://keelframework.org/documentation
Keelgroup mailing list
[EMAIL PROTECTED]
http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com

Reply via email to