<p>I maintain an ms-access application splitted to frontend and backend files. 
The frontend file is in the users conputers.
The backend file is in a shared folder in the server.</p>

<p>What is the lowest permissions required? 
can I give some of the users only read-only permissions in that folder? (or hide it from them in some other way) but still enable them to view the data?</p>

<p>How should I give the best security to the data file and to the folder containing it?</p>

[{'answer_id': 69929, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 0, 'selected': False, 'text': '<p>Yes - it resolves down to file access permissions as well as read/write. You can\'t execute any type of data update stuff (you\'ll get "operation requires an updateable query") unless the user supplies credentials that allow them to write, or you allow write on the file.</p>\n\n<p>Running a query requires only read access.</p>\n'}, {'answer_id': 70268, 'author': 'Fionnuala', 'author_id': 2548, 'author_profile': 'https://Stackoverflow.com/users/2548', 'pm_score': 2, 'selected': False, 'text': '<p>Unfortunately, the lock file (ldb) must be created, updated and deleted. If a user with insufficient permissions opens the database, it will be locked for all other users, therefore all your users need Read/Write/Delete permissions on the back-end.</p>\n\n<p>EDIT #1\nThe lock file must be created every time the database is opened, this includes via linked tables, and deleted when the database is closed. If a lock file exits and the database is closed, it indicates a problem has occurred. You will also run into problems with compact and repair if it is run with insufficient permissions.</p>\n\n<p>Edit #2\nSecurity for Access is quite a large subject and depends to a great extent on your environment and requirements, for the back-end, it ranges from a database password, which is tissue thin, but quite suitable for most offices, to Access security, which can be complicated and has been dropped in 2007. Here is a link <a href="http://support.microsoft.com/kb/207793" rel="nofollow noreferrer">http://support.microsoft.com/kb/207793</a> for a download for the Microsoft Access Security FAQ for versions &lt; 2007.\nInformation on security for 2007 can be found here <a href="http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx" rel="nofollow noreferrer">http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx</a>.</p>\n'}, {'answer_id': 74813, 'author': 'David-W-Fenton', 'author_id': 9787, 'author_profile': 'https://Stackoverflow.com/users/9787', 'pm_score': 2, 'selected': False, 'text': '<p>Many have suggested that you must give FULL permissions to users, but this is not true. You need only give them MODIFY permissions -- you can deny them DELETE permission, which is a good idea, as it prohibits the users from "accidentally" deleting your data file.</p>\n\n<p>It is true that for a user with DELETE permissions, the LDB file will be deleted on exit when that user is the last user exiting the database. But it is not <em>required</em> that the LDB file be deleted -- indeed, in Access 2 and before, the LDB files were <em>not</em> deleted on exit, but just left there hanging around. This generally has no downside, but occasionally the LDB file gets corrupted and causes problems and really does need to be deleted and recreated afresh.</p>\n\n<p>What I do is have two classes of database users (as defined in custom NT security groups specific to my Access application(s)) -- DBAdmins and everyone else. The DBAdmins have FULL permissions, everybody else only CHANGE. The result is that any time a DBAdmin exits as the final user, the LDB is deleted. This setup works really well, and I\'ve been using it for well over a decade.</p>\n'}, {'answer_id': 74858, 'author': 'David-W-Fenton', 'author_id': 9787, 'author_profile': 'https://Stackoverflow.com/users/9787', 'pm_score': 1, 'selected': False, 'text': '<p>Using a hidden share for your back end is really only "security by obscurity," and not really worth the effort. Sophisticated users can figure it out through any number of methods (depending on how you\'ve locked down your front end):</p>\n\n<ul>\n<li>view the MSysObjects table and find\nthe CONNECT string for the tables,\nwhich will identify the hidden\nshare.</li>\n<li>examine the results of\nCurrentDB.TableDefs("name of linked\ntable").Connect in the immediate window in\nthe VBE</li>\n</ul>\n\n<p>Now, if you\'ve properly secured your app using Jet user-level security (and it\'s <em>very</em> easy to think you\'ve secured your database and find out that there are holes, simply because it\'s really easy to forget some of the crucial steps in the process), they won\'t be able to do this, but even if you have, Jet ULS security is crackable (it\'s pretty easy to Google it and find cracking software), so is not really something you should depend on 100%.</p>\n'}]
['https://Stackoverflow.com/questions/69918', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/11170/']