|
(Sorry for the cross post for those of you who lurk in the MIDRANGE-L) In an effort to promote growth and new development within the RPG community I am offering an open source menu system for download. http://www.springfieldtn.net/users/leslier/ All source is freely available for download, modification and inclusion in for pay software according to the following license. Copyright (c) <2000> <L. S. Russell Open Source/400 Project> This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. This software is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative. MacWheel99@aol.com wrote: > > > Subj: Clarification of Security type S > > From: Robert.M.Mack@sgcna.com (Mack, Robert M.) > > > > I want to make sure I understand this correctly. > > The following is the way I > > understand how security access works from the greatest to the most > > restrictive based on Marc's and everyone else's information. > > You might also look at the IBM statistics on how recently passwords have been > changed for such all important "sign-ons" as the SSA owner of all of BPCS > files, and anyone who is an AS/400 security administrator, has command line > access, or is a BPCS security officer. We have users whose passwords have > not been changed in DECADES. > > > Security Type "S" means the all powerful category. Any user with this > > can get to all menus/products/programs. In effect, they can do it all. > > Yes AND they can also change anyone else's BPCS security & their own to > include COMMAND LINE ACCCESS, which will only work right for them if IBM > security has been setup to authorize this, and if they are on client access > there are other considerations. > > And there is no audit trail on stuff changed, then changed back, other than > easily deleted print-out, so for instance someone could change how > transaction effects work, enter some improper activity, then change the > transaction effects back again to how they were originally, but you do not > need Security "S" to do this, just who can do which transactions. > > > A user with Sec Type "U" and PROD ALL "1" can get to all Products/Programs > > with the exception of a few SYS programs. > > > > A user with Sec Type "U" and Prod All "0" can only get to applications if > > they are "1" for that application or to specific programs if they are "1". > > I know that you can give a user access to a product/application and then > > explicitly exclude a program by making the users authority to that program > a > > "0". And vice versa. > > Yes > > > So.... When I find a user with Sec type "S" and Prod All "1" that would be > > redundant. > > > > Why would someone set up a user with Sec Type "S", Prod ALL "0", Exclude > > them from an application ACP "0" and explicitly exclude them from 4 > programs > > ACP9xx "0" and then give them INV "1" and INV300 "1". Looks to me like > > someone wasn't paying attention or doesn't understand how the security > > works. > > Yes, this is a key area in which people who manage security need to be given > a clear explanation of how it works, with periodic review for those who do > not work with it very often. > > We have had some fluctuation in individuals who are / are not / BPCS security > officers - we want to keep the REST of their authorities pretty close to what > they are allowed to do if we should take them off of "S" status. > > We have also conducted some security tests ... the documentation says that if > you setup security a certain way, then the security will work a certain way > ... let's deliberately setup some "test people sign-ons" with screwed up > security & run some tests to verify that the documentation is correct. > > > How does Transaction Effect figure into all this? > > Ask your BPCS Security officer to get you a screen print of ALL the security > settings, which includes Transaction Effects that people are authorized to do > & Facility & other filters. We have most of our users setup with asterisk > which means "wild card" they can do any type of transaction. > > You might also like to create a Query of what is in the ITE file, which > stores Transaction Effects ... e.g. all what transaction types impact what > areas, such as General Ledger codes. We have an end-month query that totals > numbers of transactions by user by transaction type from ITH history, so we > can review whether some transaction types are being used inappropriately. > > You might also find rules in SYS800 to be of interest. > > > I apologize for the trouble, but I haven't gotten a straight answer from my > > programming department and my RPG skills are non-existent. > > Your programming department might not even know ... what you need to be doing > is looking at the documentation, which we have talked about in another > thread, and you can also ask me about off-line from BPCS_L. I am an RPG/400 > programmer & when I have had occasion to look at SSA Security, CL skills were > more important than RPG. > > There are several on-line documents that address aspects of security ...ask > your programming department to show you how to SCAN them (using the FIND > command) to locate words of interest to you like "security" then how to print > out just the section (using LP) with the text that interests you, instead of > the whole door stop document. > > Al Macintyre ©¿© > > Y2K is not the end of my universe, but a re-boot of that old Chinese curse. > The road to success is always under construction. > Stiff in opinions, always in the wrong. > When you want it cheap - you get what you paid for. > When in doubt, read the manual, assuming you can find the right one. > +--- > | This is the BPCS Users Mailing List! > | To submit a new message, send your mail to BPCS-L@midrange.com. > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: dasmussen@aol.com > +--- -- L. S. Russell Programmer/Analyst Datrek Professional Bags, Inc. 2413 Industrial Drive Springfield, TN. 37172 mailto:leslier@datrek.com http://www.datrek.com -- +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
As an Amazon Associate we earn from qualifying purchases.
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.