ColdFusion 9 ORM does not respect security settings on the DSN

This post is more than 2 years old.

Now this this is surprising. During my first presentation on ColdFusion 9 and ORM, I was asked about security permissions on DSNs and how they impact ORM. So for example, if you go into the Advanced Settings of a DSN and only allow certain operations (Select, Update, etc), will that impact ORM? I told the attendee that I honestly wasn't sure, but that I'd assume it would.

Turns out I was completely wrong. I edited one of my examples so that only SELECT operations were allowed. But this had no impact on the ORM operations I was allowed to do. I could still update, delete, and insert.

As I said - surprising - but I'm guessing that the DSN security operations must be something that ORM just doesn't go through.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Don posted on 10/7/2009 at 7:50 PM

I always thought that permissions were better handled at the database level anyway so the restrictions applied no matter how a user accessed the database.

Comment 2 by Gary Gilbert posted on 10/7/2009 at 9:44 PM

Im honestly not surprised by this, since the dsn security settings are meant to be applied to cfquery operations and the ORM is really a complete other layer where, I would bet, no cfqueries are used.

Comment 3 by Adam Cameron posted on 10/7/2009 at 11:58 PM

I agree with Gary that it's not surprising, but disagree about the rationale, as it requires a bit of a retcon to make sense. Obviously those settings didn't consider the ORM integration previously (only considering CFQUERY and CFSTROEDPROC), because the ORM integration didn't exist when they were implemented.

However now the ORM integration is there, and it's tied to the DSN so it should respect the settings of the DSN.

I would say this is an oversight on the part of the Adobe dev team, not the result of a specific decision being made. And I think it's a bug.

And, lastly: well-spotted, Ray!


Comment 4 by JC posted on 10/8/2009 at 12:18 AM

The DSN security stuff has never worked well. Set a select only DSN, then execute a query with multiple parts.. it'll only stop you if the first action the query takes isn't a select. Much safer to have multiple DSNs with different users and only use the higher permission level DSNs where the code actually requires it.

Comment 5 by Adam Cameron posted on 10/8/2009 at 12:40 AM

Probably good grounds for raising an enhancement request / bug fix, I'd say:


Comment 6 by Amy posted on 10/8/2009 at 11:15 AM

Thanks Ray, I'll update my co-worker who asked that! Good to know..

Thanks again for a great presentation of CF and ORM!

Comment 7 by Kevin Benore posted on 10/9/2009 at 7:51 AM

Not to nitpick but the last sentence uses the acronym DNS instead of DSN.

Comment 8 by Raymond Camden posted on 10/9/2009 at 7:56 AM

Fixed. Thanks.

Comment 9 by Adam Cameron posted on 10/9/2009 at 2:32 PM

Not to nitpick, but neither "DSN" or "DNS" are acronyms.

But I'm sure your nitpick had more value than this one here ;-)


Comment 10 by Kevin Benore posted on 10/9/2009 at 6:26 PM

@Adam. I agree your are correct. But also note, that definition has altered since I was a kid (and perhaps you). It is now an open debate. So I may be correct too. Some view acronyms and initialisms as synonymous. The best example of this is <a href="http://www.merriam-webster...." target="_blank">Webster's</a> definition. Wikipedia also describes the debate. But boy, now we are way off original topic. :)

Comment 11 by Kevin Benore posted on 10/9/2009 at 6:27 PM

I guess I forgot how to format a link in blog comments ... see here http://www.merriam-webster.... .