Advanced Security Issue

[theriaup]

I have a secured database and have created 2 mdw's - one for development and
one for distribution. In the development file, I have created the user
SuperUser, who has no permissions, but is a member of the Admins group which
has all permissions (the Admin user has no permissions, and is a member of
the Users group which has no permissions either).

In the second file, which was created seperately (different
Name/Organization info, not just a copy of the first mdw), I have created a
RemoteUser account, who has permission to create new users and maintain
groups. But because it has been created seperately, there are no users
capable of modifying permissions on the database.

However, I discovered that if I recreate the SuperUser with my RemoteUser
account in the second file with the same PID as the SuperUser in the first
file, I suddenly have full permissions on the database. It was my
understanding that because the original SuperUser didn't have permissions,
and only inherited them through the Admins group, and because the Admins
group is not a universal group (basically, the Admins group in the first file
is not the same as the Admins group in the second file), that the second
SuperUser wouldn't actually be the equivalent of the first SuperUser because
it's in a different workgroup file with a different Admins group.

So where is it getting these permissions from? Does the mdb just recognize
the SuperUser account and apply the original permissions from the first
Admins group?

Boy I hope this makes sense...

 

[Guest]

However, I discovered that if I recreate the SuperUser with

file, I suddenly have full permeations on the database. It was my

Who is the /owner/ of the objects in the database?

(david)

 

[TC]

I have a secured database and have created 2 mdw's - one for development and
one for distribution. In the development file, I have created the user
SuperUser, who has no permissions, but is a member of the Admins group which
has all permissions (the Admin user has no permissions, and is a member of
the Users group which has no permissions either).

Sounds good. We have DEV.mdw with user/pid=SuperUser/1234 (say).

In the second file, which was created seperately (different
Name/Organization info, not just a copy of the first mdw),
I have created a RemoteUser account, who has permission to
create new users and maintain groups.

So now we have PROD.mdw with user/pid=RemoteUser/4567.

But because it has been created seperately, there are no users
capable of modifying permissions on the database.

Your other comments make it clear that you understand how it all works.
So I'm sure you'll agree, on reflection, that the second half of the
above statement does not follow from the first half. You could easily
create a ModifyDesign user in PROD.MDW & explicitly grant him Modify
Design permission to the objects in the database. Be that as it may ...

However, I discovered that if I recreate the SuperUser with my RemoteUser
account in the second file with the same PID as the SuperUser in the first
file, I suddenly have full permissions on the database.

Do you mean, that if you create user/pid=SuperUser/1234 in *PROD*.mdw,
that user then has full permissions to the database?

It was my understanding that because the original
SuperUser didn't have permissions, and only
inherited them through the Admins group, ...

That does match how you say that you set up that user.

... and because the Admins group is not a universal group
(basically, the Admins group in the first file is not the
same as the Admins group in the second file), ...

That is correct. The Admins group is specific to each unique
combination of company/organization/WID values.

... that the second SuperUser wouldn't actually be
the equivalent of the first SuperUser because it's in
a different workgroup file with a different Admins group.

No, that is not correct. If two users in different workgroup files have
the exact same username and PID, they are considered to be /identical/
by Access and Jet. (Indeed, they are /indistinguishable/ to Access and
Jet.) For more information on this, google this group for posts from me
(TC) containing the word SID.

So where is it getting these permissions from?

Um - my bet is, it's getting them from the groups to which it belongs
in *PROD*.mdw !!

Also, as the other respondent said, you need to look at who owns the
various objects. If SuperUser *owns* the objects, then of course, he
will have full access to them.

Note that regardless of common belief, the owner of the database /is
not/ one of the people who always has (or can retrieve) full access to
the database. You can easily create a database in which the owner of
the database /does not/ have full access to one or more of the objects
therein.

Does the mdb just recognize the SuperUser account and
apply the original permissions from the first Admins group?

Nice try! But you know the answer. (no)

Boy I hope this makes sense...

Sure does. Keep me posted!

HTH,
TC

 

[theriaup]

Awesome, thank you I guess the only part I wasn't sure of was the impact
of similar users in different groups. Because I had two SuperUsers with the
same PID, but two mdw's with different WID's, I thought they would be treated
as not being the same (by the way, SuperUser from Dev.mdw is the owner of the
objects).

So basically, I could ship my software with Prod.mdw, but if somebody could
guess the Name/Organization/WID (and username) of my SuperUser account from
Dev.mdw, they could still get full access. Pretty unlikely, I would think,
and more secure than only having the one mdw.

Thanks for taking the time to clear that up.

 

[theriaup]

As I just posted in reply to TC, SuperUser (from the first mdw) is the owner.
I thought that even though SuperUser from the second mdw had the same PID,
that the two different WID's would be taken into consideration when
determining permissions. Apparently not

 

[TC]

Awesome, thank you

Yea usenet!

I guess the only part I wasn't sure of was the impact
of similar users in different groups. Because I had two SuperUsers with the
same PID, but two mdw's with different WID's, I thought they would be treated
as not being the same (by the way, SuperUser from Dev.mdw is the owner of the
objects).

It's very smart, the way they've designed it. Say you have two Fred
Smith's in different workgroup files. If those Fred Smith's are
actually the same individual, you'd give them the same PID, and voila:
Access/Jet would see them as a single person; but if they were
different individuals with the same name, you give them different PIDs,
and Access/Jet would see them as a single person!

So basically, I could ship my software with Prod.mdw, but if somebody could
guess the Name/Organization/WID (and username) of my SuperUser account from
Dev.mdw, they could still get full access.

If someone could guess just the Name/Organization/WID of your dev mdw,
they could create a new mdw with the same values. The Admins group of
that new file, would be identical to the Admins group of your dev file.
So, the /default Admin user/ of that new file, would have full access
to your database. They wouldn't need to guess any /user/ details from
your dev (or prod) files.

Pretty unlikely, I would think,
and more secure than only having the one mdw.

Absolutely unlikely for anyone to guess the values, if they are well
chosen.

Thanks for taking the time to clear that up.

No probs, glad I could help.

TC

 

[TC]

TC wrote:

(snip)

... but if they were
different individuals with the same name, you give them different PIDs,
and Access/Jet would see them as a single person!

Um, last line should read "as two different people".

TC
(off for the day)

 

[theriaup]

Was typing faster than I could think. What I meant to say was... Yes, they
could either guess the Name/Org/WID and recreate the workgroup file itself,
or just guess the Username/PID and recreate the user (one less field to guess
that way!).

 

[theriaup]

Yep... figured that one out