I'm not talking Access Users & Groups, I may or may not implement that. Even
if I do file/folder rights still need to be managed.
I've searched the archives and read the many postings. The basic problem
seems to be this:
Access is a 'file server' based system. So if you want your users to use the
db they've got to have access to the file. And can do stuff to it you might
not want.
David Fenton had a good idea, ShareName$ hides the Share. But you need admin
privileges to name shares, and in this case I won't ever have them.
So this is what I came up with. The app is FE/BE split. FE on whichever
workstations, BE on a network share. MIS have set the share up for me, and I
have
full control permissions over that. I just tried this on my network, which
is the same config as the one at work (roughly speaking!) - XP clients,
Win2K
Server.
On the folder containing the backend I give users write privileges, but
nothing else, specifically denying them List Folder/Read Data. But letting
them delete subfolders/files (to get rid of the ldb.)
On the backend mdb (which is in that folder) I give them Read, Read &
Execute
rights, and don't allow inherited rights. This is for a user I intend to
only be read only. This seemed to work. Logging on as my 'ReadOnly' user I
could read the data, but couldn't update it, insert or whatever. The ldb
file was created and deleted fine, but I couldn't examine the contents of
the folder. Am I missing something?
Often I've heard it said that you can't stop people simply copying the file,
whatever you do with NT permissions. That doesn't seem to be the case here.
Or am I right in thinking that they could just copy the whole folder?
I'll try it now, and see what happens with my read/write user too......
Nope, neither user could copy the whole folder (to get at the file). Both
users could connect to the data in the way I intend (read only or read
write). The ldb gets created and deleted as the last user logs off.
This seems like a fairly robust setup, as far as the back end data file is
concerned. So what huge hole have I missed?
Yours, Mike MacSween
if I do file/folder rights still need to be managed.
I've searched the archives and read the many postings. The basic problem
seems to be this:
Access is a 'file server' based system. So if you want your users to use the
db they've got to have access to the file. And can do stuff to it you might
not want.
David Fenton had a good idea, ShareName$ hides the Share. But you need admin
privileges to name shares, and in this case I won't ever have them.
So this is what I came up with. The app is FE/BE split. FE on whichever
workstations, BE on a network share. MIS have set the share up for me, and I
have
full control permissions over that. I just tried this on my network, which
is the same config as the one at work (roughly speaking!) - XP clients,
Win2K
Server.
On the folder containing the backend I give users write privileges, but
nothing else, specifically denying them List Folder/Read Data. But letting
them delete subfolders/files (to get rid of the ldb.)
On the backend mdb (which is in that folder) I give them Read, Read &
Execute
rights, and don't allow inherited rights. This is for a user I intend to
only be read only. This seemed to work. Logging on as my 'ReadOnly' user I
could read the data, but couldn't update it, insert or whatever. The ldb
file was created and deleted fine, but I couldn't examine the contents of
the folder. Am I missing something?
Often I've heard it said that you can't stop people simply copying the file,
whatever you do with NT permissions. That doesn't seem to be the case here.
Or am I right in thinking that they could just copy the whole folder?
I'll try it now, and see what happens with my read/write user too......
Nope, neither user could copy the whole folder (to get at the file). Both
users could connect to the data in the way I intend (read only or read
write). The ldb gets created and deleted as the last user logs off.
This seems like a fairly robust setup, as far as the back end data file is
concerned. So what huge hole have I missed?
Yours, Mike MacSween
Comment