I will share with you "Lessons I have learned about doing business using Open Source: Lesson #31":

There are three ways to view this:

o System-centric o Service-centric o User-centric

Right now, things are (mostly) system-centric. In your example of adding a user and establishing permissions, you have a problem which is user-centric. Then you propose a solution which is service-centric. This doesn't make a lot of sense.

When you are trying to create a user-centric model (e.g. the InterJet was such a model), then the best possible world is to implement a user-centric parameter store.

When you have to live in the world of attempting to leverage existing source code, then you have to accept some limitations that come with that existing source code.

This was a lesson that some of our UI people never learned, and so they tried to change some basic underlying paradigms. Yes, it's possible to do what they wanted (though, probably not wise, if you get right down to it), but the cost would be to not be able to use the exisiting code out there for leverage: the job would have to be done "from scratch"... and there are litterally hundreds of thousands of man years of effort in software like DNS and sendmail, etc., that it would be a shame to have to duplicate.

Most companies that try to base products on Open Source really fail to learn this lesson: sometimes you have to bend to the software, rather than attempt to bend the software to your will. Then, of course, the companies themselves fail.

The best compromise for a user-centric administrative view is to leave the configuration file layouts and formats alone, and put your own database out there. Then derive the configuration data for the software -- in its native format -- from the contents of your magic user-centric database.

There are a couple of interesting problems you end up needing to solve when you take this approach, but they are ultimatrely soluable.

I think you are much better off trying to build something like this (if you are smart, it will probably be based on LDAP), than you are in trying to change every piece of software out there to fit a paradigm that is specific to FreeBSD, and will lose you the third party maintenance that makes the current model valuable: it offloads maintenance onto third parties.