Re: RWOP queries for back-end secuirty: easy/hard? slow/fast?

google@xxxxxxxxxxxxxx wrote in
news:1139805114.973877.73770@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

"So far as I can see, the only way to implement back-end
user-level security that prevents viewing/importing of data by
users but still permits a user to view/edit data in the front end
is by using RWOP queries."

That is my understanding as well. Which is exactly why I'm trying
to understand Joan's comment.

I'm quite puzzled as to the discussion you're citing here. It seems
to me that a lot of different things are going on that aren't really
relevant to your specific question about Joan's quetionable comment.

"I really don't think you have any real understanding of Jet
user-level security."

I never made any claims to have a complete understanding of
anything. As I stated before, I THOUGHT that the workgroup file
only kept track of users, and validating them. I thought that
permissions had to be set within each database, based on the user
that the workgroup file validated. . . .

That is certainly correct. That is why I can make no sense out of
Joan's claim of preventing the creation of databases with a
particular MDW file -- it can't be done, unless there are aspects of
Jet user-level security that are left out of all the documentation
on the subject that I've ever seen.

. . . If you'd like to correct me, that's why I'm here asking
questions... to learn. I don't understand how to prevent someone
from creating a new database while logged in with a specific mdw.
. . .

As I said, it can't be done. Joan's remark makes no sense to me, and
the thread you referred to does not in any way address the original
assertion -- it's about importing, not the creation of fresh MDBs.

. . . I didn't
know that was even possible. Surely you can understand my
curiosity if something is presented that I don't understand.

"And Joan's original comment is still not explained by her reply
there. It says nothing about being able to prevent the creation of
new databases."

That's EXACTLY what she says. Someone asked:

"how do you prevent importing of tables from a secured file?"

And her reply was:

"As I suggested elsethread, remove their ability to create a new
database
while using the secured mdw. "

It seems pretty clear to me. And as I mentioned earlier, I've
even seen evidence elsewhere that this can be done. Take a look
towards the bottom of the post here:

But she offers no explanation of how to prohibit the creation of a
new database, only of how to prevent someone from importing secured
tables into a new MDB. I think the ability to accomplish the latter
makes the former completely irrelevant.

http://www.usenet-archive.de/comp.databases.ms-access/114736-Re_Imp
orting_from_secured_frontend_.php

"Mark" claimed to have disabled users' ability to create databases
while using his workgroup file (though he had a problem with them
working around that), and Keith Wilby, who I think knows a thing
or two about jet security, seemed to agree that they shouldn't be
able to. I'm simply trying to understand how this can be done.

I don't know that there's any way to do it. So far, no one has
supplied a set of instructions for accomplishing this task.

"There is no other way to do this if you're going to deny users
read access on the back end."

Yes, using RWOP queries is the only way I understand to prevent
"easy" access to the data. I was a bit concerned both about the
effect of the added layer of queries, as well as the possibility
that some existing code may stop working. Bri's response helped
ease my concern. But if there ARE other methods, I'd like to
learn about them. As Joan said in the other thread: "If they
can't create a new database while joined to your secure mdw then
how will they be able to import anything?" If that is indeed
possible, I'd like to understand that. I don't understand why my
curiosity must be met with such condescension.

I don't have a clue what Joan is talking about there. If she is
right, then it is *me* who knows nothing about Jet user-level
security.

I guess that's certainly possible, but given all the work I've done
with it over the years, it seems quite unlikely to me.

You described it correctly above, that the MDW holds the users and
groups, and the permissions are in the MDBs. There is no way to set
an MDW to control permissions of any kind so far as I'm aware.

I'd be glad to be enlightened, but I don't see that there would be
any point to having this capability, as it does nothing to protect
your data beyond what securing your actual tables accomplishes. If
the tables are secured, they can't be imported or linked to, so what
difference does it make for circumventing security if the user can
create an MDB file? They can't get at the secured data with that
newly-created MDB file, so how would preventing its creation enhance
security in any way?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: How to remove password dialog?
    ... I'd like to have no security setting at ... Backup your secure database ... >then open that bak file you renamed. ...
    (microsoft.public.access.security)
  • Re: Prevent copying to local HD
    ... probably confused issues by stating a database example. ... > security breach. ... We do have Citrix Metaframe. ... Even the passwords are not entirely secure ...
    (microsoft.public.windows.server.security)
  • Re: Securing data
    ... Access provides User Level Security, which is the most secure method ... Why would each staff member have their own database? ...
    (microsoft.public.access.security)
  • Re: locked out
    ... Access 2000 doesn't have Tools, security, workgroup administrator, so are ... Check in the folder where the mdb is located. ... the mdb that the wizard created before it secured your database. ... should know that the wizard is flawed; you'd need to secure it manually. ...
    (microsoft.public.access.security)
  • RE: Security of Password-Managers
    ... Another way that you could keep yourself secure is to group passwords into ... Personally, I don't like to keep everything in one database, it may seem ... 1024 should be hard to crack security. ... >By the way, your English is fine. ...
    (Security-Basics)
Loading