| William H. Magill on Tue, 13 May 2003 22:39:19 -0400 |
|
On Tuesday, May 13, 2003, at 04:17 PM, MITCHELL MALTENPORT wrote: Try identifying three or four categories with simple labels such as "expert," "trusted," "guest," "probationary." etc. Something with a clear, common meaning to you and the tech-adverse personnel. The problem is that the "groups" are not static. Unix permissions (and those used by virtually every body else) are not particularly flexible. You can set up the "ideal" configuration, but as soon as new work-groups are created, some one who was in work group A is now in work group B. The problem with your categories, is that they apply to users. If a user in group A creates a document, that document belongs to group A. If that user moves to group B, they can still read it if they own it, but their co-workers in group B can not. If you change their group to B, then they can no-longer read documents from group A. Maybe that is what is wanted, usually it is not, as it makes it difficult for the "work-groups" to collaborate. "Groups" and Unix permissions in general apply to the Users and things the Users do. In reality the Documents need to be able to define who can read them and who can modify them. Can you say Access Control Lists. However, since very few systems provide for access control lists, people constantly try to force User, Group and World to do things they simply were not meant to do... hence you need a tech savvy person to constantly ride heard on who can do what and see what. Compare the "idea" behind user centric groups "expert," "trusted," "guest," "probationary," with document centric functions like "read allowed by user Y," "write allowed by user X" for a document created by user Z. Things mapped along unix permissions pretty well until I threw in user Z -- the document is created by somebody other than the persons allowed to read and modify the document! (And remember, the "world" permissions are always turned off because if "everybody" and read or write a document, then you don't need any group permissions.) Think of it this way -- you have a generic pool of data entry people who create and own the documents. Their work is prepared for a couple of mid-level managers who ask their secretaries to modify them. Now kick it up a level... those modified documents are then reviewed by another group of folks who are different from the original readers. You can funnel the changes back to the secretary but they might have their own. Now, you might be able to "pre-define" all of this. As long as you could predict who would be in each group in the future. But suppose the group is "ad-hoc" or composed of whoever is in the office today... You begin to see the way in which work-flows in any business really do not map to the "unix way." Especially in today's businesses where "work-groups" are formed and destroyed on a regular basis for the "project of the moment." And where it is normal for a single user to be a member of multiple work-groups. System V tried to address this issue by requiring a user to actually change groups to work in a different group. BSD leaves everybody in their default group all the time... oops. Someone has to know how to change the group file permissions. T.T.F.N. William H. Magill # Beige G3 - Rev A motherboard - 768 Meg # Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg # PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg]- Tru64 5.1a magill@mcgillsociety.org magill@acm.org magill@mac.com _________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce General Discussion -- http://lists.netisland.net/mailman/listinfo/plug
|
|