Malicious deletion of mdw and/or mdb..

[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

 

[Rick Brandt]

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?

You're not confused (at least not about this

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

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.

 

[Fred Boer]

Dear Rick:

You're not confused (at least not about this

Ah, been talking to my students have you? <g>

Thanks!

Fred

 

[Rick B]

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

 

[Fred Boer]

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

 

[Tom van Stiphout]

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.

 

[david epsom dot com dot au]

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)

 

[Fred Boer]

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

 

[Fred Boer]

Yes... and once I find the culprit.....boom!

Thanks, Tom!

Fred