Re: [PLUG] Group permissions for tech-adverse personnel

["Arthur S. Alexion" <arthur@alexion.com>]

William,

You seem to understand the problem.  The problem with the consultant or
tech-savvy in-house maintainer is this.

The question on the Time Matters group that inspired my question to this
group involved a "partially tech-savvy maintainer" who says he fixes the
permissions, but then they get "reset".  Upon further inquiry, I learned
that what was happening was that nothing was getting reset.  Rather the
default permissions for newly created files were causing the problems.

Unless this "partially tech-savvy maintainer" spends his entire day
monitoring the system for new files that need their permissions
adjusted, you are going to have problems.  (How many times have you seen
a windows computer with hundreds of files named Doc#.doc in the root or
windows directories?)

What is needed is a way to tune their default permissions.

I think a graphical app that allows a tech adverse user to highlight a
document from a list, and then check off permissions from a list of
groups might be a way to go.  The morphing group membership problem is
probably dealt with practically by the tech savvy maintainer.

Ideally, the access control system should be built into the document
management system.  Problem is most document management systems are
windows based and can't deal with Unix permissions.

On Wed, 2003-05-14 at 02:37, William H. Magill wrote:

> 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.

-- 
Arthur S. Alexion <arthur@alexion.com>
Arthur S. Alexion LLC

_________________________________________________________________________
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