Malicious deletion of mdw and/or mdb..

  • Thread starter Thread starter Fred Boer
  • Start date Start date
F

Fred Boer

Hello:

I understand that in a split shared database, the back end .mdb must reside
in a shared folder, with all users given complete read/write/delete
permissions. And this is also true of the workgroup file, correct? So, there
is nothing to prevent a malicious user from simply deleting both the back
end .mdb and/or the workgroup files? Is that correct? Or am I confused?

If not, I suppose daily backups would be essential...

Thanks!
Fred Boer
 
Fred Boer said:
Hello:

I understand that in a split shared database, the back end .mdb must reside
in a shared folder, with all users given complete read/write/delete
permissions. And this is also true of the workgroup file, correct? So, there
is nothing to prevent a malicious user from simply deleting both the back
end .mdb and/or the workgroup files? Is that correct? Or am I confused?
Click to expand...

You're not confused (at least not about this :-)
If not, I suppose daily backups would be essential...
Click to expand...

At a minimum. Actually if you only give out permissions based on group
membership and not to individual accounts (highly recommended) then the MDW
will not change very often (only when you create or delete groups) making a
daily backup of that file unnecessary. Certainly the mdb should be backed
up as often as your tolerance for data-loss dictates.
 
That is all true.

You could put the stuff in a hidden folder and stop a few more users. If
these are employees I can think of a sure fire way to stop "malicious
deletions of data".

Good Luck.

Rick
 
Dear Rick:

Thanks, I *do* use a hidden share. These aren't employees, but high school
students; firing them isn't an option! However, there are other pressures
that can be brought to bear if necessary. ;)

To be fair to the students, however, I've *never* had a problem. I'm
instituting security partly to secure my installation, but mostly just to
learn how it's done!

Cheers!
Fred
 
On Mon, 8 Nov 2004 14:11:52 -0500, "Fred Boer"

Some things to consider:
* On the server you can have a process that copies another copy into
the share if it was not found.
* Using NTFS security you can find out which user deleted the file.

-Tom.
 
You /can/ remove delete privileges from the files.
Without delete privileges, it not possible to do
a compact (or a version conversion), but you may
not want your users to do that anyway.

It is /normal/ to permit deletion in the folder,
to allow deletion of the LDB files. If you allow
deletion in the folder permissions, then normally
if you compact or convert (logged in as a higher
privileged user) then the data file picks up the
folder permission and now the ordinary users have
delete permission again.

You /can/ remove delete privileges from the folder,
but then your LDB files don't get deleted. This
prevents compact/repair/convert/exclusive on the data
files. Also, you need to go in as a higher privilege
user and delete the Lab's if they become corrupted.
Also you /may/ see slower starting and closing (you
would have to test that on your system).

Removing Delete permission is possible, but requires
more intensive administration.

(david)
 
Dear David:

Thanks for the information! I don't really think I need to implement this
setup for my particular needs. However, I'm glad you explained the
possibility of this arrangement. Who knows when it might come in handy?

Much appreciated!
Fred
 
Back
Top