Re: Advance Security Issue Part II

Just thinking this through... I have the overview of how it all works now,
but some of the inner details elude me.

The mdw contains Users and Groups, generates SIDs for each of those, and
contains the User/Group relationships. It also has the user passwords, of
course.

The mdb contains the db objects, the object/SID relationships, and the SID
of the Admins group that created the mdb (I think). I would also guess that
it contains the SID of the owner of each object.

But I'm not sure where the permissions themselves reside (for example, the
Read/Insert/Update/Delete permissions on a table or query). I would think
those would reside in the mdb. Therefore, the mdb (in the MSysACEs table),
would contain Object/SID/Permissions.

If that's the case, I can't see a use for the mdw once you've logged in.
After the mdw verifies your username/login, does it pass your user SID and
group SID's to the mdb? Or does the mdb go back to the mdw every time you
attempt to open an object?

Now if I'm logged in as DBAdmin from DEV.MDW, with READ permission on a RWOP
query, what happens? I assume from your answer that the mdb goes back to the
mdw, but for what? If I log in as SiteAdmin from USER.MDW, with the
SuperUser information missing, then the mdb must be checking the mdw for
something that isn't there (SuperUser information of some kind).

Is it because the mdb knows the SID of the owner, but doesn't know what
permissions the owner has until it checks with the mdw?

If a query has WITH OWNER ACCESS, and the mdb knows who the owner is (or at
least the owner's SID), AND my SiteAdmin user from USER.MDW is a member of a
group that has READ access on that query, what's missing? I would have
thought that would be enough. If my assumption that the mdb contains the
permission information is correct, then I'm not sure why the missing
SuperUser information would really matter.

And if you can answer this, where the heck did you learn all this in the
first place? There isn't a whole lot of documentation on this, and what I've
learned about Access security has taken an awful long time (and there's still
a ways to go!).

I attempted to go back through what I'd just written to try to simplify it,
but I think my brain just short-circuited...

Thanks muchly,
Phillip Theriault

"TC" wrote:

>
> theriaup wrote:
>
> > Okay, I've got the dual-mdw thing all straight, now I have a permissions
> > question.
>
> Permission granted!
>
>
> > In my master mdw, DEV.MDW, I have the SuperUser who owns all objects and has
> > all permissions. SuperUser has created a table called SYSTABLE. He has also
> > created a Snapshot query to read that table. The DBUSERS group has no
> > permission on the table, but READ permission on the query (which is set to
> > use the owner's access).
>
> Looks good so far.
>
>
>
> > When I create the user DataUser in DEV.MDW, and add him to the DBUSERS
> > group, all is fine. He can't touch the table, or view the design of the
> > query, but can run the query and view the data.
>
> Still looks good - but I have this strange feeling that something is
> about to go wrong! :-)
>
>
>
> > Now when I create the user SiteUser in the second mdw - USER.MDW, and add
> > SiteUser to the DBUSERS group (which has been created with the same PID as
> > DBUSERS in DEV.MDW), he has no access to the query at all.
>
> I'm not surprised! (Um, actually, I was: until I read your next
> paragraph!)
>
>
>
> > Is this because SuperUser doesn't exist in USER.MDW (thereby nullifying the
> > effects of the owner access option)? Or have I just missed something?
>
> No, you got it spot-on. That is the cause of the problem. But it's not
> because the effects of the WITH OWNER ACCESS (WOA, aka RWOP) option are
> being "nullified". It's quite the opposite: the effects of that option
> are exactly what they should be in that circumstance.
>
> You've told Jet to execute the query with the permissions of a user who
> does not exist in the current workgroup file. So, Jet does not know
> /what/ permssions to use, so it can not afford to run the query at all.
>
>
>
> > I was thinking of creating another user in both workgroup files that has
> > read permissions on the table and using him to create the query (that way
> > he'll own the query and can pass permissions on through the owner access
> > option).
>
> Yes, I believe that is exactly what you'll have to do. If anyone else
> can think of a better way, chime in here!
>
>
>
> > That creates a potential security hole though (direct access to the
> > tables, which I'm trying to avoid), since somebody could crack that password.
>
> Yes. The ability to reverse-engineer the passwords from the workgroup
> file, is very unfortunate. It is /not/, as many people mistakenly say,
> due to the fact that the workgroup file is freely available for people
> to play with. It is instead due to a simple, "schoolboy howler" mistake
> in how the passwords are encrypted. I've submitted a suggestion on how
> to eliminate this, with what I believe would be a 2 line fix to the Jet
> sourcecode! Whether that will ever be done is, of course, a matter for
> conjecture by us mere mortals.
>
> Here's what I'd do. Create the new user, and give him (via VBA code) a
> password like "s3crrrxx3t", where the two x's represent the hex
> character for BACKSPACE - 0x08, from memory. Then, when the user runs a
> cracking utility to display the passwords, the utility - unless it is
> /very/ smart - will send the following character sequence to the
> screen: s 3 c r r r BACKSPACE BACKSPACE 3 t. So the user will
> see: "s3cr3t". That sure looks like a secret password!! But it will not
> work, from the login box, or via VBA, because it actually isn't the
> password, at all!
>
> I think that would deter all but the most determined & technically
> sophisticted users. You could throw some ENTERs (0x0D) and LINEFEEDs
> (0x0A) into the mix, as well, if you wanted. You could easily see how
> your choice, would look on the screen:
>
> debug.print "s3crrr"; chr$(8); chr$(8); "3t"
>
> Remember: 1% of effort will deter 99% of hacking users. But *no amount*
> of extra effort, will deter the remaining 1%.
>
> HTH,
> TC
>
>
.

Relevant Pages

  • Re: User access on a company intranet
    ... Yes they need full permissions on the folder where the backend is. ... You wouldn't need to do this in your copy of the database. ... However you can toggle the shiftkey bypass from another mdb file. ... When you want to implement security, you create a new mdw file, ...
    (microsoft.public.access.security)
  • Re: MDB remembers old MDW
    ... There were 2 reasons that I thought that the mdb had a link to the mdw: ... When you looked at the Workgroup Administrator dialog it displayed ... Group permissions the old groups from 'Security.mdw' were displayed. ...
    (microsoft.public.access.security)
  • Re: MDB remembers old MDW
    ... There were 2 reasons that I thought that the mdb had a link to the mdw: ... Group permissions the old groups from 'Security.mdw' were displayed. ... migrating all of our back-end databases to SQL Server 2005. ...
    (microsoft.public.access.security)
  • Re: Advance Security Issue Part II
    ... discovered the dual mdw thing. ... >> The mdb contains the db objects, the object/SID relationships, and the SID ... The owner of the query is stored in the MSysObjects ...
    (microsoft.public.access.security)
  • Re: MDB remembers old MDW
    ... The workgroup file is used for a session of Access - any number of databases ... The mdw defines the usernames/passwords and group memberships. ... permissions are stored in the mdb file with the objects. ...
    (microsoft.public.access.security)
Loading