Exactly. It's not a security hole. It's just the architecture of the program.
It seems like many people have a hard time understanding this, including developers.
Any attempt to add any kind of permissions, security, etc, without addressing the nature of the architecture (that the database engine runs in the same address space / security context as the UI) misses the point.
Further along those lines, it was a different world when the code was created.
Trust was a thing back then. Spam was something that came out of a tin and was made of dead animal. And passwords were limited to eight ASCII characters.
And as such, bolting security onto something that was designed inherently to be security agnostic is going to be a recipe for failure.
It had absolutely nothing to do with trust. People still worried about the security of their databases. Businesses understood perfectly well that their electronic records were just as sensitive as their paper ones. But the server closet had a lock on the door, and no wire connecting it to a global network of mostly scammers. It was just as secure as the paper records.
With a permissions system that’s meant to enforce security? I hope not.
I’m not a FoxPro user and so maybe these are single-user/single-host installs, where the user can only destroy their own data, and permissions are a pretend feature. In which case, carry on.
Well, on a different note, if you have a scripted language application, you typically can edit files and bypass whatever you want on the application. In fact, I'd bet most modern software isn't signed; and even if it is, sometimes the libraries that get compiled in into that signed binary... aren't.
I can change the behaviour of many/most applications by just having read/write access to files; Can you give me examples of mainstream applications that are resistant to filesystem tampering when eg.you have install access? Maybe I'm missing something.
Well, I had to call it something. File system DBs were a problem long before FoxPro’s DBCs, yes. Yes, it’s an architectural decision. Sharp cookies would just modify the files directly. But that would just trash data (or bump my hourly rate in the HR DB). Most of the time, “full access to data” doesn’t necessarily mean “run arbitrary code”. In this case, it does, which I don’t think folks expect, hence “hole”.
If you already have full access by design, then there's no "huge security hole" either.