I cannot replicate this on my XP systems.
What I did:
1) created a new test file with one table and one field.
2) created a user account, accountname: limited; password: limited.
3) Selected the pre-defined "read only" privilege set for it.
4) enabled "all users" in sharing so that it would be visible over the network.
5) went to a second machine and created a new file.
6) gave it accountname:limited; password: limited
7) Selected "full access" as it's privilege set
8) Went to manage | Database | Relationships and added a table occurrence of the table from the hosted file.
9 ) created a layout based on this table occurrence
10 ) when I tried to modify the data using this layout, I got error messages telling me that I my access privileges did not permit it.
Thus, I could access the data, but encountered the same security account controlled limitations as was set on the original file. I could, however, have exported the data into a new file and modified that copy of the data, but the data in the original file would have remained unchanged.
Sorry, I should have been clearer.
The user is assigned to a "User" profile which does allow the modification of field values. "All of the other r/w permissions are pretty open."
This is necessary for their use in and functoin of the sytsem. My probelm is they've been able to bypass the business rules built into the layouts and scripts by directly accessing the data via a local linked database.
They can not delete or add new records via the relationship, so the User profile is being honored. Can I keep them from linking to the database and working around the scripts?
This is expected behavior. Such protections should be built into the privilege set options specified in the user's account. Otherwise, as you have found, people can hack their way around your system. Layout based limitations are useful to prevent accidents and to make your interface more user friendly, but true security requires setting up the needed limitations in Manage | Security and in (sometimes) in field validation rules defined in Field options.
This is necessary for their use in and functoin of the sytsem.
I seriously doubt that. It may take some thought and creativity, but it's possible to set up some really specific limitations on what a user can and cannot do with record level access controls in Manage | Security. On cases where the user needs to accomplish tasks otherwise prohibited by the security settings, you can provide a script with "run with full access permissions" specified to provide limited access to a feature otherwise prohibited by their privilege set.
That makes sense. I guess I'm starting down that path by restricting add/delete records & running the script to do either with full access. I had never considered this same approach at the field level. I was hoping there was just a check box that would prevent a relationship from being established with an external database.
Looks like I get to learn something new again today! Thanks for your help. This forum is fantastic.
I have found an even better answer, assuming my server & clients are v11 or above.
Pages 11-16 in techbrief_fm11_security.pdf describe my condition exactly.
Manage Security : File Access : Turn on the "Prevent opening with earlier versions (pre FMP 11)" option. This allows the next, and most valuable option to light up...."Require full acess privileges to create references to this file".
This will prevent external files from linking with my hosted file unless they have full access privileges. BUT......this requires ver 11 or > for all clients and servers.