Protecting Runtime Table Data

[mporter]

If I open a new database in FileMaker Pro and create a table, I seem to be able to reach into a Runtime's .USR file and import data from that Runtime's tables. How does one prevent this?

[Vaughan]

Interesting question. Are you the developer? Do you know the account and password that the runtime file is being opened with?

[Vaughan]

OK been thinking about this rom a security perspective.

The end user can open the file and use the data -- it's their data. What shouldn't they be able to do stuff with it?

Or is the issue the ability to directly select it to import from FMP client?

[comment]

I am only guessing here, but this could be about:

http://www.filemaker.com/11help/html/passwords.13.32.html#1043154

[Vaughan]

Yes I as thinking about that... but that's more about setting up a file as an external data source for relationships, rather than simple old-school importing.

Solution might be as simple as flicking the export bit in the privilege set, but my guess is the runtime is opening with the default admin account and password.

[comment]

Solution might be as simple as flicking the export bit in the privilege set

Alas, that won't work: the export limitation applies only in the local file. That is the hole (or one of them) version 11 was meant to plug.

[Vaughan]

OK I understand that.

From one perspective, if the user has the authority to see the data (ie username and password to open the database and view the data) then what's the security difference to them sucking it out in an export in one go, as opposed to seeing it one row at a time?

mporter: can you explain why you want to prevent this?

Does it then become a matter of *convenience*?

[comment]

Not speaking for the OP, but suppose you have a database of 20k subscribers. Your support staff are authorized to find a subscriber and view the details to handle a call. That's a far cry from letting them walk out with your entire customer base on a USB flash drive...

[Vaughan]

Comment... yes agreed, but it's a matter of convenience only. The user could screen-shot a list view of clients 100 at a time and do it in a couple of days. The export only saves a bit of time and effort.

It's like forbidding photography in a building, so instead somebody goes in looks around then makes an oil painting of it.

[mporter]

Yes, I am the developer. And I just want to prevent an easy mass dump of all the table data. I have invested a huge amount of time amassing and organizing the data and don't want to serve it up to a potential competitor on a platter.

Currently, in my Runtime app, although the user has access to the data, there is no view which would let one use the screen-shot method mentioned above effectively and get the same kind of data dump.

I'm not looking for perfect security. I know that's not possible. But a FileMaker Runtime does prevent administrative access and keep others from seeing your scripts and other programming structures. Like a regular commercial application does not include access to its source code.

I'm just asking if there is anyway for a FileMaker Runtime to also block a mass extraction of all the contents of its internal tables by something as simple as creating a new FileMaker database and reaching into the Runtime's USR file with an import? Seems like a pretty big security hole to me.

[comment]

Comment... yes agreed, but it's a matter of convenience only.

Eventually, all security is a matter of convenience only. It's more convenient to walk through an open door than having to pick a lock or break down the door.

I'm just asking if there is anyway for a FileMaker Runtime to also block a mass extraction of all the contents of its internal tables by something as simple as creating a new FileMaker database and reaching into the Runtime's USR file with an import?

Version 11.

[Vaughan]

...Like a regular commercial application does not include access to its source code.

Regular applications (like FMP itself) are complied. Customers never get close to the source code.

FMP databases aren't compiled. The runtime engine isn't a compiler its a cut-down version of FMP client.

[mporter]

Regular applications (like FMP itself) are complied. Customers never get close to the source code.

FMP databases aren't compiled. The runtime engine isn't a compiler its a cut-down version of FMP client.

Yes, I know. I was only making an analogy in the sense that a Runtime database has its programing (scripts, etc) somewhat protected.

Do you have an answer to the topic question about how to protect a Runtime's tables from an external import?

[Vaughan]

Yes, I know. I was only making an analogy in the sense that a Runtime database has its programing (scripts, etc) somewhat protected.

Errr, not really. The only security is to remove administrator access from the file permanently, but that's a bugger because the file cannot be modified after that and any updates will require export/import into a new solution.

Do you have an answer to the topic question about how to protect a Runtime's tables from an external import?

Comment posted the answer already: use the security file access options in FMP 11 to require full access privileges.

http://www.filemaker...32.html#1043154

[mporter]

Thanks to both comment and Vaughn for the suggestion to use FMP 11 security file access. However, so far my experiments have not found this to be a solution.

First I tried the obvious. If I uncheck the Allow exporting box in Privilege Sets, it does a great job preventing an external file from importing the protected file's table data but it also disables the Export Records script step inside the runtime. That won't work because I am distributing a full-access removed runtime. I have and need scripts that export and import data.

If, under File Access, I check the Require full access privileges to create references to this file box, AND ALSO, under File Options, disable Auto login, it will keep another file from getting in to import without entering the account name and password. However, I want the user to have the convenience of an Auto login. Besides, if there is no Auto login, I have to give the user the account name and password anyway. So that doesn't seem to work.

I have also experimented with custom privileges options but can't seem to find a way to block an external file from importing data out of the protected file's tables that doesn't also disable the user's access to the data within the runtime.

Maybe there is something simple I am overlooking here.

[comment]

Under File Access, you should check both Prevent opening with earlier versions (pre-FileMaker 11) AND Require full access privileges to create references to this file. This will prevent exporting your file's data using a reference file.

If I uncheck the Allow exporting box in Privilege Sets, it does a great job preventing an external file from importing the protected file's table data but it also disables the Export Records script step inside the runtime. That won't work because I am distributing a full-access removed runtime. I have and need scripts that export and import data.

Your exporting scripts should be set to run with full access privileges.

[mporter]

Under File Access, you should check both Prevent opening with earlier versions (pre-FileMaker 11) AND Require full access privileges to create references to this file. This will prevent exporting your file's data using a reference file.

Your exporting scripts should be set to run with full access privileges.

Thanks. Setting the export scripts to run with full access privileges does the trick. I thought there was something simple I was forgetting.