By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,998 Members | 2,921 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,998 IT Pros & Developers. It's quick & easy.

MS Access 2000 DB w/ Multi Read Only Users + Folder permissions & the Lock File

P: n/a
Database Users need to have Read/Write etc... permissions to the
folder where the Database resides in order to create the lock file.
I have read only users.

I have set up the Shortcut that links to the 'Workgroup Info File'
with permissions for said database.
Within this 'WIF' File I have "Read Only" user's who are only provided
access to the DB only so they can view the data.

Now if I give them full permissions to the folder where the database
resides, what am I to do to keep them from going to this folder &
opening up the database directly using thier local 'WIF' File?
Help would be greatly appreciated.
Thanks

Mar 13 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On 13 Mar 2007 11:53:38 -0700, pa****@gmail.com wrote:

What can be preventing them from using the db any way but RO is the
proper application of user-level security. If you do it properly, they
can only do with the mdb (I'm assuming a back-end database) what you
have already setup for them to be allowed to do.

Applying this level of security is an advanced topic. Download, read,
and fully understand the Access Security FAQ from microsoft.com before
proceeding on a copy of your database (just in case you mess up).

This level of security can reportedly be defeated by password crackers
available on the internet. It is also a deprecated feature in Access
2007, so don't bet on it staying around forever. If you want real
security, SQL Server is your ticket.

-Tom.
>Database Users need to have Read/Write etc... permissions to the
folder where the Database resides in order to create the lock file.
I have read only users.

I have set up the Shortcut that links to the 'Workgroup Info File'
with permissions for said database.
Within this 'WIF' File I have "Read Only" user's who are only provided
access to the DB only so they can view the data.

Now if I give them full permissions to the folder where the database
resides, what am I to do to keep them from going to this folder &
opening up the database directly using thier local 'WIF' File?
Help would be greatly appreciated.
Thanks
Mar 14 '07 #2

P: n/a
The User's can access the DB via the Shortcut (linking the Workgroup
Info File) no problem.
Both my Read Only & Write Users...no problem. Permissions are working
fine.

My problem is that since all user's requre full access to the folder
containing the DB, they are able to copy the database, rewrite over
the database with thier new copy etc...
I cant really see my user's wanting to screw it all up in this
fashion, although you never know.

I read in other discussions some options
Applying Read Only permissions to the database itself. While keeping R/
W to its folder.
In another they had R/W to the containing folder & applied the
Traverse Folder special Permission as Deny to stop access to the
folder containing the DB.

Im just trying to figure out what the best option would be...
On Mar 13, 10:29 pm, Tom van Stiphout <no.spam.tom7...@cox.netwrote:
On 13 Mar 2007 11:53:38 -0700, paq...@gmail.com wrote:
Mar 14 '07 #3

P: n/a
So since ive removed the default admin permissions on the database im
not worried about users altering the data contained within the DB.

My only worry is "silly" users deleting or overwriting the database.

Currently my only recourse is Daily backups.

Mar 14 '07 #4

P: n/a
pa****@gmail.com wrote:
Database Users need to have Read/Write etc... permissions to the
folder where the Database resides in order to create the lock file.
I have read only users.

I have set up the Shortcut that links to the 'Workgroup Info File'
with permissions for said database.
Within this 'WIF' File I have "Read Only" user's who are only provided
access to the DB only so they can view the data.

Now if I give them full permissions to the folder where the database
resides, what am I to do to keep them from going to this folder &
opening up the database directly using thier local 'WIF' File?
Help would be greatly appreciated.
Thanks
If you applied security properly then it will not open with their local WIF
file.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Mar 14 '07 #5

P: n/a
In you post you stated;

If you applied security properly then it will not open with their
local WIF
file.

Do you mean when then open the database via the shortcut ive created
or when they open the database directly?
When they open via the shortcut, the WIF ive created applies. When
they open the DB directly, thier WIF applies.
Now, according to the Microsoft support articles I read, there are
only 2 ways to apply a custom WIF File.

1. Use the "MS Access Workgroup Administrator" utility to have the
users join the WIF
(Which applies to all databases, & I only require it for this one
database)
Hence I went with option 2;
2. Create a shortcut to the DB with the cmd line argument " /wrkgrp"
This is what I did & it works fine, only if they use this shortcut.
If they go direct, they use thier own local WIF, which is useless
for this DB as I removed the default Admin permissions. Although they
do have access to the database's containing folder due to the required
permissions.

Mar 14 '07 #6

P: n/a
pa****@gmail.com wrote:
In you post you stated;

If you applied security properly then it will not open with their
local WIF
file.

Do you mean when then open the database via the shortcut ive created
or when they open the database directly?
When they open via the shortcut, the WIF ive created applies. When
they open the DB directly, thier WIF applies.
Now, according to the Microsoft support articles I read, there are
only 2 ways to apply a custom WIF File.

1. Use the "MS Access Workgroup Administrator" utility to have the
users join the WIF
(Which applies to all databases, & I only require it for this one
database)
Hence I went with option 2;
2. Create a shortcut to the DB with the cmd line argument " /wrkgrp"
This is what I did & it works fine, only if they use this shortcut.
If they go direct, they use thier own local WIF, which is useless
for this DB as I removed the default Admin permissions. Although they
do have access to the database's containing folder due to the required
permissions.
Okay, so now you are saying that if they try to open the file with their local
WIF they won't be able to because you removed the default Admin permissions. Is
that correct? If so then that is what I stated should happen. That makes this
question from your previous post a bit puzzling.
what am I to do to keep them from going to this folder &
opening up the database directly using their local 'WIF' File?

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Mar 14 '07 #7

P: n/a
On 14 Mar 2007 10:37:46 -0700, pa****@gmail.com wrote:

That is a good recourse.
Additionally you can have the db on an NTFS partition and turn off the
ability of users to delete the file. You can also turn on logging so
you would know who deleted the file if that happened. Then be ready
with your tar and feathers :-)

You know about the /readonly switch on the Access command line, right?

-Tom.

>So since ive removed the default admin permissions on the database im
not worried about users altering the data contained within the DB.

My only worry is "silly" users deleting or overwriting the database.

Currently my only recourse is Daily backups.
Mar 15 '07 #8

P: n/a
So ive applied the proper NTFS file Permissions to the Database
itself. Leaving the Full Permissions to the folder.

I didnt use any Read/only switches in the cmd line though.
I applied the Read Only attribute within the Workgroup file. Thats
fine right?

SO as far as I can tell, all is well. I'll still do the daily backups
though & keep my tar & feathers handy in case some power user wants to
play tricks.
Hopefully I can move this all to SQL Server sooner than later.
THanks for the help guys.

Mar 15 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.