Wow. All this feedback is tremendously useful. I really can't thank enough.

Thank you for the arguments on centralizing data, and the questions I need to ask myself/etc on this project.

I am in charge of the project, I am an employee, and the project is made first for my company (and implemented for our use)- and then to be offered to other companies of similar needs with their clients.. (Sound familiar?)

I have full control with security in the first implementation of this project/system. But from there on out.. It's going to be a little bit out of my hands, and I am near vomiting that levels of security (on/off) will be at the mercy of salesmen. It makes me seriously ill thinking about it.

Yes, my ass *is* on fire if things go wrong.
It's hard because the company is very white collar clean cut .. just plain white here and there. So .. I have to be very dipplomatic about what we should and should not be doing, and what we can and can not be doing.

Honestly I want this to work well and reliably for all involved, I'm not simply making sure to stay out of the firing range.

It makes sense to make the authority be the DB. I was seriously considering using the structure of the filesystem to populate the database, and then later on the database would be always just a quick way to see filesystem data.
That is, if empty flat file "joe" were in directory "my stuff" it would make the right entry in the projects/users table.
I was scared about the prospect of the dabatase being corrupted. I still kind of am. It seems like an awful lot of stuff on one file (the db(s)).
The info is sensitive. Most of it is financial/classified data for insitutions.

I will build/offer the full security platoon for my company, and then make sure paperwork needs to be signed before the little soldiers are put to sleep one by one- for other companies.

It's hard because the company is very white collar clean cut .. just plain white here and there. So .. I have to be very dipplomatic about what we should and should not be doing, and what we can and can not be doing.

No, you don't. You can and should speak plainly. You just have to communicate in terms that businessmen can understand. Speak in terms of risk, liability, and accountability. Those are things that are important in business. Computers, networks, and security typical aren't; unless they impact the bottom line on the company balance sheet.

Specifics to address should include:

1) You're not willing to be held accountable for failure of this system unless you have authority over how it will be implemented. Pointed refuse to take the blame for someone else's business decisions.

2) You're concerned about the risks and the associated costs the company is exposing itself to by it's poor security. Ask for a written explanation as to why they're not adopting a more secure risks-management policy, and point out, in writing, exactly how much money they stand to lose if something goes wrong. If it's a trivial amount, then perhaps they don't care. If it's not (and it's probably not), point it out to them. Remember, businessmen don't care about computers; but they care a lot about money.

3) If you're worried about costs of errors (security settings being set wrong), point that out, as well. Develop best case, worst case, and realistic probable case scenarios, with numbers. Prove your points to the senior management.

4) If they still won't listen to you, object formally. Get requests you disagree with put in writing, then implement them as written. Get clarifications in writing if anything is unclear. Once they formally order you to do something, it's not your decision anymore, and neither is the blame for that decision. That "pulls your ass back out of the fire", so to speak. By getting your orders in writing, you're making the point that you disagree strongly, but will comply so long as your boss takes the blame for his own decisions. If he won't do that, one or both of you should leave the company. ;-)

Don't be afraid to speak up if you think there's a significant problem. On the other hand, be prepared to back up your fears with a proper risk analysis: what you think can go wrong, why it might go wrong, and how those risks would be mitigated if they did things "your way". Learn to make the business case for what you want; it's a skill that will serve you well throughout the rest of your life, even if management rejects it for this project.

I suggest you think about auditing as well - if management has any competence at all in the business processes, they should find the need for an audit trail readily apparent. You need to have the programme write an audit log as it goes along.

You could use this as an 'in' to get security onto the agenda - e.g. what's the possibility that a change can be made without any record of who made it? and (even if there's no fraud) what would the company's auditors think of that?

HTH!