I read about GT.M security docs and see that GT.M do not include a specific security solution ,it depend on OS system user roles
Now I want that each user have specific roles on databases ,how can I do that
Example :
user 'manager' can act SET ,KILL command on global "Account","Salary"
user 'employee' just only can act ZWRITE command on global "Salary"
Assume that "Account" and "Salary" global variables are mapping in the same database file
Thanks,
GT.M does not implement a security layer itself, and instead uses on access control as implemented by the operating system (user/group/world permissions and layered security such as SELinux). I know that some applications have accomplished what you want using the traditional user/group/world controls, but it does require the application schema to be amenable. Other applications implement access controls at the application layer.
The quote above by #DAiMor is dated. The current quote from the manual is:
Ensure that database file ownership (user and group), UNIX user and group ids, and permissions at the UNIX level match the intended access. If finer grained access controls than those provided by user and group ids and permissions are needed, consider using, where appropriate and available, security products layered on top of the operating system.
In general, we no longer recommend Access Control Lists. I notice that there is a later mention of it in the manual, which we should remove. ACLs work for files, but not for resources like shared memory.
Here I see, that you are talking about read and write access, so, you have to change access to DB file, you can add your users who should have an access to write to UNIX group with such access.
Quote from GT.M Security Philosophy
Ensure that database file ownership (user and group), UNIX user and group ids, and permissions at the UNIX level match the intended access. If finer grained access controls than those provided by user and group ids and permissions are needed, consider using Access Control Lists (ACLs) where they are available.
Related
I have a Microsoft Access Database with an interface for usability ... But now, all users have access to the tables of the database directly. I want to deny this except for those who are authorized i.e.: Password Protect the access to the tables not the GUI.
Unfortunately, there is no "simple" solution for this.
Access has a security-mechanism built in. Note though, that this only works for the "old" mdb format, not for the new accdb format supported by Access 2007/2010. Thus, if you are going this way, you are using a deprecated technology which will might not be supported in future versions.
That said, here is a tutorial found on the Internet. The process is a bit complex; it definitely exceeds the space of a StackOverflow answer:
The Microsoft Access Security Apparatus
If you need a more future-proof solution, I'm afraid your only choice it to move the back-end (= the tables) into another database system, such as SQL Server Express. There, you can restrict access to the tables and grant access to your application by using Application Roles.
If you only want to prevent your users from accidentally messing up your data, it might suffice to install only the Access Runtime instead of the full product. Note, however, that this does not provide security, since a malicious user could simply install the full version of Access!
It's advisable to assign permissions to groups, not to users, because each user inherits the permissions assigned to the group. this might help you
I'm thinking of writing a CouchDB-backed application that will store sensitive data. Is it possible to set things up so that I can get something like MySQL's and PostgreSQL's access control, where particular users on the system (users in the sense of Unix system users) can be denied or granted access to a particular CouchDB database?
Absolutely, you can set up users in the _users database. You can assign roles, groups, as well as any other custom fields for each user. In the validate_doc_update function in your design document(s), you can check user roles and approve or deny access based on that. You can also globally assign users as "readers" and "writers". You can authenticate users via Basic HTTP Authentication, OAuth and a variety of other methods.
Refer to the Security Features Overview and Document Update Validation pages on the wiki to get started.
Is it possible to set Access persmissions using Active Directory users?
Edit: The overall objective is to allow some users to see certain tables and deny this permission for other users. I'm wondering if it can be done using active directory users.
Depends on what you mean by Access permissions. Access user level security do not interact with Active Directory in any way. ACC: Microsoft Access Security FAQ Available in Download Center It is suggested you reread this FAQ several times. I must admit I never quite understood it. Also see ACC2000: Overview of How to Secure a Microsoft Access Database
Now what you could do is read the Active Directory data for the logged in user and groups and such. Then with some local tables mapping the various AD groups along with the login userid to the various objects and menu items in Access you could control access in this fashion. Note however that local tables can possibly be mucked with by a savvy user, etc, etc.
The most useful URL I found was the following newsgroup posting need help on get list of W2K ad Domain (fqdn) by using VB Options I kept a page of notes when I was working on this topic but they may or may not be useful. I can post them if desired.
I agree with the things that both Tony and Philippe has posted. I just want to add a bit:
If you really need security, then a Jet/ACE back end is not going to do the job for any significant definition of the word "security". Jet ULS is crackable and fairly easily so for anyone with even basic programming chops. Thus, if it's DATA SECURITY that you're looking form, Philippe is right that you should choose a different database engine.
But if you are only looking to control ACCESS in your front-end application, you have three choices:
maintain a couple of tables in your database of your users and the permissions on each of the objects.
implement Jet user-level security.
use AD users/groups in place of Jet ULS.
None of these choices is seamless.
And all of them mean that your front-end has to be programmed to deal with the issues.
If you're restricting access for security reasons, then it makes sense to use a database engine that integrates with Windows security (i.e., SQL Server).
If you're doing it just to streamline program flow, and to adapt the app at runtime to the needs of particular users, then you don't necessarily need security on the data store so much as you need a way to keep track of who is using the database and what groups they belong to, and then what parts of the app they should have access to (and, secondarily, what level of access, read/write, read-only, etc.).
I have used Jet ULS for this last purpose for years, but have never been entirely happy with it because it's not that easy to make it user-manageable. Integration with AD would be a good choice, but that means that whoever administers your app needs to have the permission to manage AD users. This may not be something your friendly neighborhood sysadmin is willing to agree to.
On the other hand, if you end up needing both back-end security and front-end access control, you can't beat a SQL Server back end using Windows security for one-stop shopping via AD.
According to the few questions you posted these last days on Access, it seems obvious to me that you should consider switching your tables (not your forms) from an Access/mdb file to a SQLExpress server, where all these security issues can be easily managed. Upsize your database, add your connection string as a public variable in your client app (or in an xml file, local table, or anything else that can hold the string, even an extra property of your access file can do the trick through the currentDb.createProperty method), and go for a real client-server configuration.
What is the simplest way to allow one user write access and everyone else read-only access to a MS Access database on a local network?
I trust my users, but unfortunately Access saves changes to data as soon as the row of a table is deselected. Accidental keystrokes are saved without the user asking for the changes to be saved.
Some thoughts on controlling user rights to a Jet data store:
if you really want to lock things down, you'll never manage it with Jet, as it's inherently vulnerable because the user has to have WRITE access to the MDB file.
if you are content with controlling rights to the data in your front-end application, you could provide different front ends (one for WRITE users and one for READ-ONLY).
if you're not using ACCDB format, you can use Jet user-level security. It's a surprisingly complicated technology if you really want to lock down access to the data -- you have to follow all the instructions in the Jet Security White Paper to the letter, or your data will be open to anyone with the standard Jet workgroup file. And even once you're done, it is crackable (though not without spending $$$ to buy cracking software). BTW, database passwords before Access 2007 were completely useless and easily cracked. Access 2007 enhances the security by raising the level of data encryption, but a database password causes lots of issues and doesn't allow you to have more than one level of access (unless you provide two different front ends with different passwords -- cf. #2).
if you just want to use Jet ULS to control access in your front end, you can add your users to groups and then check the group membership in your front-end UI objects (i.e., forms), and give WRITE permission to the users who are in the user group that provides that level of access. The easiest way to do this, assuming you have more READ-ONLY users than those with WRITE permission is to have the READ-ONLY users log on as the default admin user (i.e., you do nothing for their setup), and have the WRITE users log on as a user in the group with WRITE permission. In other words, if they aren't logged on as user "admin", they have full WRITE access.
another alternative is to use NTFS security groups. API code for that is found on the Access Web, but it does require a Windows administrator to implement for you. Again, you would be limiting access in your front end application, rather than actually restricting user rights in the back-end MDB.
Only Jet ULS actually allows you to prevent a READ-ONLY user (who hasn't cracked your workgroup file) from editing your data. All users have to have network access to your back-end MDB, but you can make it hard for them to get to the data even without jumping through the hoops in implementing Jet ULS. Here are some steps to do that (and yes, all of these are a form of "security by obscurity" and will only slow down a READ-ONLY user determined to hack your back end):
Right click each table in your back end and turn on the HIDDEN attribute. This can also be done in code (see SetHiddenAttribute in Help). Naturally, if the end user sets their Access options to display hidden tables, this won't do anything. But most end users don't know about that, and if your users are running your app in the runtime, they won't have the option.
Change the back-end database's Startup Properties to not display the database window and to not use special keys. You can find code for setting the startup properties in the Help topic for "AllowBypassKey".
In your back-end, create a macro named AutoExec with one command, Quit. With special keys disabled, there is no way to prevent the execution of this macro, and as soon as the user attempts to open the back end (even if they hold down the SHIFT key, i.e., the standard keystroke for bypassing all startup routines), the database (and the instance of Access) will close.
Now, all of these things can be undone by someone who knows what they are doing. If you gave me a back end with these things implemented, I'd be in it in about 5 minutes, simply by running code in another Access database to change all these startup properties to give me access.
But your end users likely don't have that level of expertise. Any such user who does probably ought to be a WRITE user, no? :)
Yes, of course -- all of these things are easily hackable by anyone who knows how. But it's also easy to break into your house in seconds for the person with the right tools. That doesn't mean you don't lock the doors, even though it's not bulletproof protection from burglary.
Another consideration is that if you provide your users only the Access runtime instead of full Access, they won't be able to undo any of these settings in your back-end MDB.
Last of all:
Security is not solely a technical issue -- most of it is, in fact, a people problem. In order for people to do their work, you have to trust them to a certain extent in giving them access to your data. There is no technical solution to the problem of the untrustworthy system administrator, for instance, and the only way to fully protect your data is to not give them any access to it at all.
The easiest way would be to use share permissions. Grant write access to a group and put the users who must write to the database in that group. Put everyone else in a read group. This assumes you have a Windows domain, of course.
Here is a site that has some information on securing Access databases. It deals with Access 2000, there may be more options for newer versions.
This is the cheeky answer, but if you need better security, seriously consider upgrading to a more robust RDBMS.
I think it is possible using an ODBC connection to use Access as an interface to almost any database. For example, I have successfully configured a SQL Server 2008 Express Edition database with 2 users, one read/write and one read-only. I have been able to connect to the database from Access by opening an ODBC data source. So a user can have the Office-based report-generating and mail-merging functionality they are familiar with. But with any database server you wish.
This conversation may be a little old, but for some reasons I got the same problem recently. It will not suit to everyone, cause it relies not on M$ SQL Server but on MySQL. Use the MySQL ODBC connector (available here: http://dev.mysql.com/downloads/connector/odbc/), and store your tables on a MySQL server. The Access user's rights on tables will inherit from the MySQL user's rights. Pretty easy to customize...
Fact is, there is NO functional security for an access database.
The link below sells software that will 'recover' your access database Even if it has a a password.
It is a good thing they exist. Their program saved one of my customer's butts once when their previous programmer died and no one else had the password. Thanks to this program we could not get in and no data was lost.
http://www.stellarinfo.com/access-recovery.htm
And before you even think it, No, I do not work for them.
Can user level security enable someone to access a form, but not access a table? I have a form that is connected to a table using a"SELECT" command. It does not "UPDATE" or "DELETE". I'd like for the user to access my form, but I don't want them to be able to view the details in the underlying table. I've tried all sorts of combinations in the user level security wizard, but for some reason, my form comes up blank, unless I give complete access to the user to do anything. Any ideas? By the way, I'm on Access 2003.
You could make an MDE and give it to your users. If you do this, the users won't be able to see anything but the user interface you have provided.
If your tables are in the same Access database as the forms and queries, you first need to "split the database" into a frontend and backend. See:
http://databases.about.com/od/tutorials/ss/splitaccessdb.htm
for information on how to do this. The frontend contains everything but the tables. The backend contains the tables. The frontend is linked to the backend tables using "linked table" objects in the frontend.
Once the database is split, open the frontend in Access, and create an MDE by selecting Tools/Database Utilities/Make MDE File from the menu bar. The MDE is what you provide to the users. They open it the same way they would any other database, except that they can't design any of the objects.
Make sure that you have an AUTOEXEC macro defined in the frontend, so that when the MDE is opened by the user, it has an entry point. The user cannot see any of the objects in the MDE, so if you don't have an AUTOEXEC macro to open the first form, nothing will happen when they try to open the MDE.
If you need the ability to manage the linked tables in the MDE by allowing the user to connect to the backend database with a File/Open dialog, see the following article:
http://www.mvps.org/access/tables/tbl0009.htm
OF course, none of this precludes your users from opening the backend database. If you need stronger security, you can upsize the backend database to SQL Server Express. More info here:
http://office.microsoft.com/en-us/access/HA102755371033.aspx
What you're looking for is a RWOP query. That means "run with owner permission."
To make it work, assuming you've already run the security wizard on your front-end and back-end databases and have removed permissions for the users to even read the tables, you then create a saved query as the recordsource of your form. In the properties of the query, it is set by default to RUN PERMISSIONS as "user's." Change that to "owner's" and save the query. The query will run with whatever permissions on the base table the owner of the query has. If you are running as an administrator with full permissions, you'll want to set the permissions of the saved query to read-only (or create the query under a user logon that has read-only access to the tables -- it's much easier to do the former).
Some caveats:
user-level security is tricky. If you miss even one step outlined in the ULS security white paper, your app won't be secured. The way to test this is to open Access with a default workgroup file and then see if you can access the objects in your database logged on as the default admin user. If you can, then you made a mistake somewhere along the line.
user-level security is crackable by anyone who wants to. This doesn't mean it's not useful, it just means that it's not bullet-proof. I don't worry about that so much, as I consider security as much a people problem as a technical problem -- you have to give employees sufficient privileges to do their work, and you have trust them that they won't abuse the privileges you've given them.
if you're running Access 2007 and using the ACCDB format, RWOP queries are not available to you, as Jet user-level security is not supported for the ACCDB format. If you're using MDB format, though, it will work just fine in A2007.