|
David, The point I was trying to make is that your characterization of adoption being "old" and has limitations is really not correct. The fact that IFS does not honor adopted authority is a limitation of IFS -- not of adopted authority. The concept of "swapping userIDs" in a job is much older than the concept of adopting authority (yes it predates the big bang of System 3, etc...). The POSIX architecture -- which is one of the types of file systems supported by the IFS -- has no concept of, or provision for, adopted authority. While technically, the architecture could have been extended, we chose not to for several reasons (note: I was not involved in the decision either way). One was that the original goal of IFS was to make it easier to support/port POSIX-based applications to OS/400. Since POSIX has no concept of adopted authority, it wasn't required to meet that goal. The high cost of re-architecting the POSIX file system to support adopted authority along with the fact that adopted authority was not required to meet the original objectives all mitigated against supporting adopted authority. In hindsight, was it the right decision? In my mind, probably not. Was it the right one at the time? Given the objectives and resources available, it was certainly a rational decision. All of this aside, even if it adopted authority was "old" and hadn't "kept up" doesn't mean that it shouldn't be used in all of the many places where it still makes sense. All of the following make a lot of sense in a lot of different scenarios: Swapping Adopting PUBLIC *EXCLUDE Groups Authorization lists etc., etc., etc., These all are just different tools in the toolbox. The right tool should be used for the right job. Swapping and adopting are tools that are neither always the correct nor always the wrong tool. IMHO, to say that one is "worse" and should be avoided because it's older or doesn't work in every possible scenario is equivalent to telling mechanics through out their wrenches and only use PCs. Patrick Botz Senior Technical Staff Member IBM Lab Services, Rochester Security Architecture & Consulting, i5/OS Security Architect (507) 253-0917, T/L 553-0917 CTC Fax # 507-253-2070 email: botz@xxxxxxxxxx For more information on CTC, visit our website at http://www.ibm.com/eserver/services http://www.ibm.com/servers/eserver/services security400-bounces@xxxxxxxxxxxx wrote on 09/11/2006 03:00:51 PM:
Pat, The point I was trying to make was that adopted authority has limitations and has not been enhanced over the years to keep up with modern applications. That means you have to start using newer techniques like swapping. I started using swapping because the IFS, triggers and exits can't propagate adopted authority. The newer APIs make swapping easier but it is still more difficult than adopting. My guess is that overall iSeries security has suffered because adoption didn't keep up and swapping is not as easy as it could be. --David Morris
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.