From time to time people ask me why the Privilege Set bits in FileMaker Pro are all turned OFF by default. Would it not be easier and better for security purposes, the questions go, if all these were turned ON instead?

The answer is No; here is why. First, some history. Prior to the introduction of FileMaker® Pro 7 in March 2004, all of the privileges–as they then existed–were turned on by default. Developers then had to wade through a veritable sea of settings and options to limit access to their files. In the older versions of the products, a table and a file were more or less equivalent. A file could contain only one table. The modern versions of the products changed that. Files could contain multiple tables, and business rule mandates could require different privileges for each table.

As part of the products’ modernization, FileMaker, Inc. adopted a Role-Based Security model for all its privileges. The Privilege Set is where developers assign the rules a Role must follow. The Accounts then serve to identify the user and to authenticate and validate the user’s assertion of his or her identity. With two or three exceptions, some of which FileMaker, Inc. has subsequently modified to fit the original framework for the modern version, all Privileges were set to be OFF by default. Developers must explicitly authorize a specific Privilege for each Role.

A core principle of Information Security is the Rule of Least Privileges. That concept states that a user should have all the privileges necessary to fulfill his or her respective Role, but no additional privileges beyond those needed. A key effort FileMaker developers must make is to prevent escalation of privileges, a situation that results when a user assigned to a specific role can gain privileges to which he or she is not entitled. If a user can accomplish this, it can have unexpected and usually detrimental effect on the Confidentiality, Integrity, or Availability (CIA) of the data in the file. The preservation of CIA is the core reason underlying why we implement information security.

In older versions of FileMaker Pro, for example, when Record Level Access for viewing of data was put into effect, FileMaker Pro nevertheless downloaded all the records, whether a user was entitled to see them or not. The client-side application was left the task of sorting out which records to display. By employing a simple packet-sniffing tool, all the data could be viewed, irrespective of the user’s privileges. In the modern versions, however, such row level access (as it is formally known) occurs at the Server. Only the authorized records are returned to the client side.

Everything was turned ON is older versions of FileMaker. And turning them all OFF didn’t necessarily have the result a developer might expect. When it comes to being an “old-timer” in FileMaker, I am primus inter pares. Others of you who have been around for ten or more years may also remember that older process for Privileges. For the rest of you, accustomed only to the modern era security schema UI, here is what it used to look like in older versions.

The pop-up lists had two options: All or Limited. Now, contrast that with a newly created Privilege Set in FileMaker® Pro 12:

As you see, for the most part, every Privilege Bit is disabled, or it is set to its most restrictive option. The re-authentication for FileMaker GO is an exception, and that needs correcting in my view so that its default value is 0.

Requiring the developer explicitly to grant privileges for each Role in the database system is consistent with Information Security Best Practices. It provides for a high lever of granularity of control in granting privileges. It supports and enforces Role- Based Security. These are the reasons why the system works as it does. It was to further these goals and objectives that the system was changed almost ten years ago. The FileMaker Security Schema has evolved in the intervening time, including the addition of File Access Protection several years ago. It continues to evolve, and in the future we will hopefully see that process continue.

Steven H. Blackwell

Platinum Member Emeritus

FileMaker Business Alliance