---------------------------<snip>---------------------
In my opinion, a properly impelemented security structure would have no
user-id's named in security rules, instead all rules would have group
(or role) names in them, so a connect/disconnect of a user to a group is
all that is needed to grant access. If done that way, the only time the
ID is referenced is in the connect command. I do agree that from the
standpoint of management, allowing users to select ID's is problematic,
and could cause collision issues. However, I also feel that embedding
the departmental function in a userid is a bad idea, because then the ID
has to change if the user gets transferred from one department to another.
-----------------------<unsnip>------------------------
To a point, I'll agree with that. But management doesn't always see it
that way, especially in a small shop. Some functions are relegated to a
single person, with no regard to transfers, vacations, terminations or
new hires. Agreed, it's a short-sighted view, but it's a lot closer to
reality than we'd like to admit. And if management doesn't get involved,
seriously, then the proliferation of GROUPs can be as bad, or worse,
than dealing with individual ID's. All too often, management looks upon
security as an unpleasant side issue, with unfortunate results.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
