Authorization is the job of the ACL engine. Putting ad-hoc rules into
user entries is, in a word, stupid. It's also unscaleable and will
become an administration nightmare.
Well OK then. Using a configuration mechanism
like ACL's that cannot be
distributed to multiple users (like editing a directory can) is, in a word,
stupid. It is also unscaleable and will become an administration nightmare.
And authorisation is not (or SHOULD not be) the job of ACL's its the job of
authorisation modules, which nssov is.
Being forced to give admins who simply want to be able to change access to
a random host in a centralised server root access to what may be a critical
server with other sensitive data on it is simply wrong.
The user host attribute functionality is deprecated. I have no desire
make it even vaguely appear to be useful.
Then don't sell it as one. You claim
pam_ldap compatibility but that is
false. The user docs also aren't nearly as strongly worded, saying that the
hostserver and ACL's is preferable, not that userhost is deprecated.
A flexible solution gives administrators the opportunity to use the tool in
ways you haven't conceived of because it works for them and their
environment. A ridgid and dictatorial tool forces people to do things one
way and one way only. I have worked for one of the larger software
companies and can tell you that the ACL mechanism would scale orders of
magnitude worse, and they did, in fact have authorisation info stored in
user and host attributes because that was the only way to delegate
responsibility to multiple groups.
PS, you may wanna consider dropping the Ulrich Drepper attitude. When a
contributor, especially a first time one, who has gone to considerable
lengths to follow all the guidelines and do things just your way has, as
his first experience someone calling things "stupid" ... well, that will
thin the development herd considerably.