RE: Supplemental Groups

Good point Rob, this is another way to simplify the setting of authority
on an object.  It doesn't address how to set object owners, but it can
simplify object authority when all the objects in a library have the
same authority requirements.

And that happens a lot.  When it doesn't, IT folks like us have to have
the discipline to sometimes do a GRTOBJOWN along with our CHGOBJOWN (or
CHGOWN) and set the authority correctly.

Again, that's just MHO.

jte


--
John Earl | Chief Technology Officer
The PowerTech Group
19426 68th Ave. S
Seattle, WA 98032
(253) 872-7788 ext. 302
john.earl@xxxxxxxxxxxxx
www.powertech.com 
 

 
This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.
--

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
> bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Thursday, February 16, 2006 10:36 AM
> To: Midrange Systems Technical Discussion
> Subject: RE: Supplemental Groups
> 
> It can be a little easier.  The adopting authority could
> be put into an
> authorization list.  Then if you do a CHGLIB LIB(MYLIB)
> CRTAUT(MYAUTL)
> then any new object created in that library automatically
> gets that
> authorization list assigned.
> 
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "John Earl" <john.earl@xxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 02/16/2006 12:59 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-
> l@xxxxxxxxxxxx>
> 
> 
> To
> "Midrange Systems Technical Discussion" <midrange-
> l@xxxxxxxxxxxx>
> cc
> 
> Fax to
> 
> Subject
> RE: Supplemental Groups
> 
> 
> 
> 
> 
> 
> Steve,
> 
> > Snip
> >
> >   "That is why many admin's suggest you have individual
> > profiles own their own objects when they are created."
> >
> >   End Snip
> >
> >   I respectfully and whole-heartedly disagree with this
> > statement.
> 
> <Snip>
> 
> >   The owner of newly created objects should be set to
> the
> > user's primary group profile and this should be coupled
> > with group profile entries within authorization lists to
> > facilitate access to the application programs and files.
> 
> <Snip>
> 
> And I must respectfully disagree with your proposed
> solution. - Group
> profile ownership is the lazy route to object ownership
> assignment that
> ultimately puts entire applications at risk.  If BOB
> creates a file, and
> then ownership is assigned to BOB's group (Let's say
> "SALES"), then
> everyone in Sales now has full read, update, and delete
> rights to the
> file - this is how many systems got into the security
> pickle they find
> themselves in today - There are 917 users in a group that
> owns a some
> files, so now all 917 users exercise "ownership" rights to
> those files.
> 
> IMHO, the proper way to handle object ownership is to
> have, for each
> application, an owner profile that has no password and is
> not a group
> profile for anyone.  Then when new objects are created the
> ownership,
> *PUBLIC, and Group authorities should be set in a distinct
> step that
> immediately follows object creation.
> 
> If the object is created as a part of an application, then
> the
> application is responsible for setting the proper
> ownership and
> authorities.  If the object is created by an IT person,
> hen that person
> is responsible for setting the proper ownership and
> authorities (granted
> a little automation would help here because humans are, by
> definition,
> are fallible).
> 
> Ever watch a good UNIX admin at work?  Every time they
> create some new
> file, they immediately do a 'chmod' command.  It's part of
> their DNA.
> It needs to become a part of ours.
> 
> jte
> 
> --
> John Earl | Chief Technology Officer
> The PowerTech Group
> 19426 68th Ave. S
> Seattle, WA 98032
> (253) 872-7788 ext. 302
> john.earl@xxxxxxxxxxxxx
> www.powertech.com
> 
> 
> 
> This email message and any attachments are intended only
> for the use of
> the intended recipients and may contain information that
> is privileged
> and confidential. If you are not the intended recipient,
> any
> dissemination, distribution, or copying is strictly
> prohibited. If you
> received this email message in error, please immediately
> notify the
> sender by replying to this email message, or by telephone,
> and delete
> the message from your email system.
> --
> 
> > -----Original Message-----
> > From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-
> l-
> > bounces@xxxxxxxxxxxx] On Behalf Of Steve Martinson
> > Sent: Thursday, February 16, 2006 9:11 AM
> > To: midrange forum
> > Subject: RE: Supplemental Groups
> >
> > Snip
> >
> >   "That is why many admin's suggest you have individual
> > profiles own their own objects when they are created."
> >
> >   End Snip
> >
> >   I respectfully and whole-heartedly disagree with this
> > statement.  The fact that individual user profiles own
> > objects quite often caused MUCH grief to administrators,
> > most notably when BOB leaves the company (or gets hit by
> > the beer truck).  I see this all the time (and I'm at a
> > different client site practically every week).  They try
> > to delete his profile, but it owns bunches of objects,
> > including device descriptions and who knows what else.
> > So... they leave it there (hopefully *DISABLED with
> > password of *NONE) because they can't get rid of it.
> >
> >   The owner of newly created objects should be set to
> the
> > user's primary group profile and this should be coupled
> > with group profile entries within authorization lists to
> > facilitate access to the application programs and files.
> > Of course, if you can avoid getting too deep into
> > supplemental groups, that's always better (as someone
> > already mentioned).
> >
> >
> >
> > Best regards,
> >
> > Steven W. Martinson, CISSP, CISM
> > Consultant - Servique, LLC
> >
> > Cell 281.546.9836
> > www.servique.com
> > 4801 Woodway Drive, Suite 300E
> > Houston, TX 77056
> >
> > "Uniquely Qualified"
> >
> > ---------------------------------
> >  Yahoo! Autos. Looking for a sweet ride? Get pricing,
> > reviews, & more on new and used cars.
> > --
> > This is the Midrange Systems Technical Discussion
> > (MIDRANGE-L) mailing list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> > http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/midrange-l.
> >
> 
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
>