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

["William H. Magill" <magill@mcgillsociety.org>]

On Wednesday, May 14, 2003, at 05:06  AM, Arthur S. Alexion wrote:
> 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.
> What is needed is a way to tune their default permissions.

That is the problem with BSD style permissions. They ALWAYS create 
things in whatever the "default" group happens to be. With System V, 
you could change-group for your login process and create files under 
the new default group. ... not that anybody ever did, but that's beside 
the point.

> 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?)

This is correct. Despite what the marketing folks claim, computers are 
NOT for the tech-clueless. "Computer literacy" was the big "buzzword" a 
few years back. Today, it is possible that most folks are "reading" 
their computers at a grade level equivalence of about kindergarten -- 
maybe. Even driving an automobile requires one to prove one's 
proficiency. There are things that end users must know and perform for 
themselves about any environment. When they don't know those things, 
they become unsupportable.

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

This is correct. However, somebody has to write it within the 
constructs of whatever application is involved. It doesn't work in a 
Unix environment. ... at least not a "real" unix environment, where you 
have more than 2 or 3 users. The menus simply get too long and annoying 
to use. Tru64 Unix has had such a GUI for many years now... and 
everybody hates it with a passion. Yes idiots can use it, but unless 
you have the patients of an idiot, or a very small collection of users 
and groups it is incredibly painful to use. [... assume that the 
standard screen display has 20 lines... you get the idea.]

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

No, CHEAP document management systems are Windows based. Real Document 
management systems run on Unix. And besides, the permissions on Windows 
(at least through NT) and Unix are basically identical.

Yes, this is not a new problem. It is actually quite well known in the 
industry. Where industry = enterprise computing.

The normal solution -- adopted by Oracle, SAS, Ingres and everybody 
else... THEY (the data-base engine) control the access to the 
documents, as well as access to the DB engine. But those are NOT cheap 
solutions. (They also have/require a DBA - Data Base Administrator - 
someone whose job it is to deal with all these kinds of problems.)

Your situation is neither atypical nor easily solved. If you didn't 
have to worry about people managing to connect a computer connected to 
the Document management system to the Internet, you could just open up 
the permissions to the world. (Of course assuming that your internal 
auditors won't get upset that Joe can read Sam's documents.) But as 
soon as you have one desktop machine talk to both the Document 
management system AND the Internet, you are guaranteed to have security 
problems.

One "obvious" solution is to have as few users and groups as possible, 
thereby keeping the number of permutations low to begin with. Then 
write the couple of scripts that do all of the chmods -- label them 
"share-with-Ralph, allow-Molly-to-change," etc. If you had a 
drag-and-drop desktop setup, they would be easy to use... which is 
pretty easy to do with OS X... don't know about in other desktops...   
definitely not in Motif.

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