Access Privileges Gap?

[DrRoebuck]

I may be brain-dead, and I hope I am, but there seems to be a major, major hole in FM7 security.

I have database.fp7, with the non-full-access account user_1, who has access only to several fields in table_1, as well as execute-only access to several scripts.

If I'm the end-user who normally logs in to database.fp7 as user_1, and if I create a new, empty database and add a file reference to database.fp7, I can do the following:

1) add an occurrence of table_1 in the Relationships window of my new database. If the password for user_1 is stored, the occurrence will show up automatically. If not, I can enter it in. And I would know the password because that's how I would normally access database.fp7. At this point, I can already see the entire list of fields in table_1 to which I have access (though I can only see the labels);

2) create a new layout and have it set to show records from table_1; and

3) add to this layout every field from table_1 to which I have access. Once in Browse mode, I can obviously edit all the fields. This includes globals. This includes users/groups fields. This includes copy-protection fields. This includes structural-type fields that are used for relationships.

Also, in my new database's ScriptMaker, I can do the following:

1) create a new script and add a Perform Script step;

2) click Specify and choose to perform a script from database.fp7; and

3) execute any script from database.fp7 to which I have access.

At the very least, this is horrific. The amount of time I can foresee wasting on workarounds for this sloppy architecture makes my knees buckle. I have a users/groups routine that is worthless, if someeone can see the data in all the records and tables that are part of that routine (e.g. all the groups to which each user belongs). Same goes for a Demo routine. Same goes for a Copy Protection routine.

This means that every field I create will have to contain explicit access definitions, where it can only be visible by user_1 if get(layoutname) = a layout where that field actually appears. I'd have to at least do that for every sensitive field.

This also means that every script I create will have to start by checking that it's being executed from the proper location.

Am I missing something? Please, someone, tell me I'm missing something.

FileMaker Version: 7

Platform: Windows XP

[Reed]

I think you must be missing something because I just tried this and it didn't work. I only had the same level of access as if I had opened the file itself.

[DrRoebuck]

So you have ultra-secure SecureDB.fp7, with knowledge, let's say, of only a user-level account/password. And you created a new database, let's say, called NewDB.fp7.

And you did the following:

1) In NewDB.fp7, you added a file reference to SecureDB.fp7;

2) You then went to ScriptMaker in NewDB.fp7 and created a new script;

3) In that new script in NewDB.fp7, you added a Perform Script step;

4) You clicked Specify and opened the pop-up menu under "Select a script to perform either in this file or in another specified file."

And at that point, you didn't see SecureDB in the list of referenced files?

And you couldn't see a list of every single script in SecureDB to which you had execute-only access?

And you couldn't tell your script in NewDB.fp7 to execute any of those scripts in SecureDB?

[Reed]

Why wouldn't you be able to execute those scripts from a related file if you have permission to execute them from the SecureDB.fp7 file? It's not letting you execute scripts or edit fields for which you don't have access... is it?

[DrRoebuck]

Let's say I have a script that's part of a copy-protection routine, that authorizes the user to continue using the software. They can execute that script from their own database and then authorize the database.

Or on less paranoid terms, would you want somebody changing data in your database without actually being in your database?

[cjaeger]

Don't think it works after you restart FileMaker.

Remember, FileMaker does not have to show a window for an open file. Nor an entry in the Windows menu. If you accessed the file previously with extended priviledges, it stays open until you explicitely close it.

[murtje]

You don't miss anything.

It has also a great advantages:

- separation of data and interface.

- separation of data and data

- separation of modules (e.g. a file with thye data, a file with the reports and a file with the interface).

But it's true, we have to think more if we setup security. Just like we have to do if we make an application with other SQL-databases like MySQL, MS SQL server, ... were we have the same problems and difficulties.

With FileMaker Pro 7, we have to unlearn en relearn new techniques.

Koen

[DrRoebuck]

Yeah. I guess I was just stunned by how much overhead this seemed to add, and also uncomfortable with ordinary users or nefarious competitors being able to see feild and script labels, etc.

One thing I noticed is that using certain parameters such as DatabaseNames in record-level privileges can prevent someone from accessing your fields via their own database. I'll also have to add similar steps to any scripts that should not be executable from other files.

I still think FMI dropped the ball a little on this one. You should be able to easily restrict people from seeing any of these things.