Re: Security without signon

Tech-Archive recommends: Speed Up your PC by fixing your registry

Sorry to post so long after the fact, but I just came upon this very
interesting discussion while researching my own related problem with RWOP
queries.

After seeing Joan state so unequivocally that RWOP queries will work even if
the owner is not in the production mdw, I decided to investigate further why
this was not my experience. Turns out that she is right, of course, but I'll
share with you why it wasn't working for me.

The owner of all of the objects in my front-end mdb, including the queries,
was an individual "super user" (i.e., not a group). When I secured the
back-end mdb, I gave table permissions to the administrator group (not
Admins) that this user was a member of and gave no table permissions
explicitly to the individual "super user", assuming that permissions would
flow through to the "super user" by virtue of membership in the administrator
group.

Well, with one important 'Gotcha', it appears as if the permissions do flow
through as you would normally expect, as the "Super User" was able to access
the tables as per usual. However, anyone using the default System mdw would
get error 3112 (no read permission) even though the default Admin user had
appropriate permissions on the queries in the secured front-end. When I
changed security in the back-end so that the "Super User" was explicitly
granted permissions on the tables, then everything worked for users with the
default System mdw just as Joan suggested it would.

So the 'Gotcha' is that, with RWOP queries, permissions do not flow-through
from a Group to a user. If an individual user is specified as the owner of
the query, then for that query to work as a RWOP query, that individual owner
must have explicit permissions on the back-end table, not permissions that
are inherited by virtue of group membership.

It will also work if the owner of the query is a group and the group has
permissions on the back-end table. You can change the ownership of the query
to a group if you want. The important point is that the names must
match--the owner of the query must also have explicit permissions on the
back-end table, whether that be a group or an individual user.
.

Relevant Pages

  • Re: Query Security
    ... that creates a query, that query is owned by the user who ran that code. ... WITH OWNER ACCESS OPTION is irrelevant for queries that ... > You could also dynamically create the queries on opening of the form & Add ... > With OWNER permissions etc ...
    (microsoft.public.access.security)
  • Re: backend security question
    ... I have thought about using RWOP, and actually have all the queries ... >> open the backend and view that table, it has everyone's SS#'s, ... > permissions) queries for all data interaction. ...
    (microsoft.public.access.security)
  • Re: rwop
    ... Your clarification of rwop does help me think through the process, ... If my query doesn't ... users from entering data, but no, they will have owner's permissions. ... permissions of the owner. ...
    (microsoft.public.access.security)
  • Re: RWOP /table permissions question
    ... Create a RWOP query for each table. ... base all your SQL statements on these queries rather than the tables. ... users will need appropriate permissions on the RWOP queries, ... I have some admin users trying to some bad things to the program. ...
    (microsoft.public.access.security)
  • Re: Running update queries with update permissions for an read onl
    ... You can make your Update Queries RWOP - they will run with the query owner's ... and they won't need any permissions on the table. ... >> _should_ only have read-only privileges. ...
    (microsoft.public.access.security)