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

Replies:

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

This mailing list archive is Copyright 1997-2021 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.