Please confirm security limitations

  • Thread starter Thread starter Brad Wood
  • Start date Start date
B

Brad Wood

I've been tasked with creating a small internal project (used by a dozen
users) that requires a back end database.

I just upgraded to Access 2003, so I am experiencing the security
limitations for the first time.

I merely create a new database and then attempt to re-open it and I'm
prompted with the security warning. This is analagous to getting an
ActiveX control warning for every web page I open whether there is a
control on the page or not.

I just want to store some data and create a few reports, I'm not
embedding any code within; I *should not* see any security warnings. Am
I correct in concluding that Access is no longer an option unless I:
- Have our users revert to an older version (not an option)
- Have our users set their security settings to low (probably not an option)
- Buy a certificate (not an option)

??
 
Brad said:
I've been tasked with creating a small internal project (used by a
dozen users) that requires a back end database.

I just upgraded to Access 2003, so I am experiencing the security
limitations for the first time.

I merely create a new database and then attempt to re-open it and I'm
prompted with the security warning. This is analagous to getting an
ActiveX control warning for every web page I open whether there is a
control on the page or not.

I just want to store some data and create a few reports, I'm not
embedding any code within; I *should not* see any security warnings. Am I
correct in concluding that Access is no longer an option unless I:
- Have our users revert to an older version (not an option)
- Have our users set their security settings to low (probably not an
option) - Buy a certificate (not an option)
Click to expand...

What your seeing is how Access 2003 works unless you set macro security to low
which is what just about everybody who uses it does. It "sounds" dangerous, but
all it does is make Access 2003 behave the way every other version of Access has
ever behaved.
 
Brad Wood wrote:

(snip)
Am I correct in concluding that Access is no longer an option unless I:
- Have our users revert to an older version (not an option)
- Have our users set their security settings to low (probably not an option)
- Buy a certificate (not an option)
??
Click to expand...

No, there is another (better) option. It is trivially simple to try it
out. Google this group for posts from me (TC) including the term
"automationsecurity", to find the details.

HTH,
TC
 
TC said:
No, there is another (better) option. It is trivially simple to try it
out. Google this group for posts from me (TC) including the term
"automationsecurity", to find the details.
Click to expand...

Thanks; that will work fine. I still think there should be no reason to
bother with security unless the database I'm opening itself contains
code (as opposed to mere data).
 
Even if the database only contains "data", there is potential for harm. For
example, if someone entered Shell("del *.*") into one of your fields and the
Jet sandbox was not being used. Still, Microsoft's solution is a PITA and
very poorly implemented. The sandbox is TOO restrictive (i.e., Eval is a
very useful function in queries but is sandboxed), but there is some risk
running without it.
 
Paul,

Slightly off-topic.
I havent gone into .NET yet. But how does this security PITA (i.e. security
level warnings, dig. certificates, etc, etc.) fit in the .NET framework. I
know there is a concept of *managed* vs. *unmanaged* programs, but will we
still have to deal with the whole security PITA as it is now?


Immanuel Sibero
 
I can't see how .NET would affect this. The warnings come from Access &
Jet. If a .NET component used Jet somehow, I image the warnings would
still appear, unless .NET dropped the Office macro security level, set
the relevant registry keys, used the AutomationSecurity property, & so
on.

But I'm no .NET expert ...

Cheers,
TC
 
Glad that it will work for you.

I agree with Paul that a data-only database can still cause harm. But
IMO, Microsoft should have provided some way for a user to say: "I
trust this specific application, please stop giving me friggin'
warnings about it!" In theory you can do this using a "self certified"
certificate. But that is way too difficult & unpredictable for most
users, IMO.

Cheers,
TC
 
The macro security warning comes from Access, not Jet, and is not relevant
when not using automation. You won't see that warning when using Jet via
..NET, though you would if you automated Access via .NET.

This is not to suggest that there are no security issues in .NET, of course.
There are security issues in all development environments.
 
Brendan said:
The macro security warning comes from Access, not Jet
Click to expand...

Doh! I should have realized that. Otherwise, a VBScript
createobject("dao.dbengine.nn") would get the warning (and it doesn't).

Cheers,
TC
 
Back
Top