× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: security AGGRAVATION: renaming *devd
  • From: "John Earl" <johnearl@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 8 Aug 2001 20:57:42 -0700
  • Organization: The PowerTech Group

Title: RE: security AGGRAVATION: renaming *devd
Dan,
 
Yes it's possible to have all devices owned by DEVMGT, but you'll likely have to roll it yourself.  I suggest that you build a little CL program that assigns the proper ownership to these devices right after they are built.  Sure the default CRTAUT value on your system is *CHANGE,but there is no reason you have to live with the default.   Manage the device object as soon as it is built.
 
You could also put all of your devices in an authorization list, and then give DEVMGT *ALL authority to items secured by the list.  This has the value of not requiring that you acquire an exclusive lock on the device (as changing the ownership would).  This way you are better assured that your automated process will actually run to completion.
 
As for the *IOSYSCFG special authority, it's purpose is to identify the list of users that are authorized to modify device descriptions (in a generic sort of way), but the user still needs specific authority to the device in question.  *IOSYSCFG doesn't work like *ALLOBJ and *SPLCTL - it doesn't bypass object level authority rules - it just says that a user is eligible to work with communication descriptions.
 
HTH,
 
jte
 
----- Original Message -----
From: Bale, Dan
Sent: Tuesday, August 07, 2001 1:11 PM
Subject: RE: security AGGRAVATION: renaming *devd

Thanks Joe.

The problem with this approach is that devices are added periodically, and moved around from one port to another, and these *devd objects are created with the *PUBLIC = *CHANGE authority.  Unless I am missing something, we are really no better off with this than what we have now.

Got me thinking, though.  Is there a way to always have device descriptions, no matter how they are created, manually or via autoconfig, to always have as its owner the DEVMGT profile?

And, getting back to my original question...  What does *IOSYSCFG do if it doesn't give a user with this special authority the power to manage device descriptions?  We tried changing *PUBLIC to use *ALL, thinking that *IOSYSCFG would be the other "key" that keep non-*IOSYSCFG users from being able to rename a device description.  (It didn't.)  It seems silly that we would have to create a new profile for this. 

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

    -----Original Message-----
    From:   Joe Pluta [SMTP:joepluta@PlutaBrothers.com]
    Sent:   Tuesday, August 07, 2001 2:09 PM
    To:     MIDRANGE-L@midrange.com
    Subject:        RE: security AGGRAVATION: renaming *devd

    Dan, how about this:

    1. Set up a user profile called DEVMGT (Device Management) with no signon
    2. Grant *ALL authority for the device descriptions to this profile
    3. Add this profile as a supplemental group profile for all your operators

    Joe


    > -----Original Message-----
    > From: Bale, Dan
    >
    > So, what's the magic combination needed to give our system operators the
    > ability to work with device configuration and keep end-users from doing
    > so?  Note that we do not give anyone *ALLOBJ authority.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.