FTP server authority issue & adoption -- MIDRANGE-L

John,

I'm not sure where to start (other than I am not the wise one), but
this is certainly not an oversight.  For better or worse, from day one
the Integrated File System Introduction has stated, in the Security
section, that adopting authorities is not supported.  And that the APIs
use the authority of the user profile under which the job is running.
This is why you may see references to using APIs such as Set Profile
(QWTSETP), Get Profile (QSYGETPH), and Release Profile (QSYRLSPH) in
various articles.

Now as to why "adopt" was not implemented within the Integrated File
System --   well it was, but the implementation follows the UNIX/POSIX
definition and not the historical AS/400 implementation.  Within the
Integrated File System mode bits are assigned for S_ISUID and S_ISGID
which provides for an executable (when loaded) to assume effective user
and group ids of the file/program owner.  These bits are used, for
example, when the AS/400 is a NFS server to a UNIX NFS client.  If AS/400
in the future allows native loads from the Integrated File System I
would hope that the UNIX/POSIX view of adoption is also implemented.
In the mean time, swapping to a given profile is the closest match we
have available.  Please note that due to the accumulative nature of
current AS/400 adoption (that is, the call stack can be providing lots
of different user profile authorities), the 400 approach cannot be easily
supported/expanded into a distributed UNIX/POSIX environment.

Now unfortunately the net of all this is that historic AS/400 program
adoption does not apply to the Integrated File System.  But as the same
also applies to historic AS/400 database access, communications
programming, and everything else found in the "Unix-type APIs" section
of the System API Reference I don't find it too surprising (which is not
to say I find it pleasing).  I do believe that AS/400 should have
improved support for UNIX/POSIX adopted authorities; I'm not sure that
expanding AS/400 adoption techniques into the UNIX/POSIX environment
would be a wise use of resources though (as if I had in say in the matter
anyway...).

Bruce Vining

>
>Bruce,
>I am glad you brought up the "Adopt" issue.   Who was the "Wise" person who
>designed the IFS in such a way that it did not allow the programs accessing
>it to adopt authority to access it????   If you run a program that access
>a directory on the IFS the Program adoption does not work.  I asked
>Paul Remtema about this at COMMON and he was surprised/shocked to hear that
>adoption didn't work.   Does Rochester realize how stupid and troublesome
>this is???   I have read articles that say I should call an API to,  and
>listen to this,   Change the Running user profile on the fly in the program
>to a user profile that has rights to the IFS directory !!!  I under stand
>that this is not an architectural change but a minor change under the
>covers.   Talk to Ray Bills, Dave Boutcher or whoever and say "Let's fix this
>stupid oversight!!!!!"
>
>I have a program that builds an History capture of the entire IFS
>(Like a big DIR/WRKLNK to a file + more) and in order to run the capture
>it has to be submitted personally by QSECOFR or QGOD.
>
>Is this dumb or what.  Does this same thing effect FTP in the same way??
>
>John Carr
>EdgeTech -  Have Classes, Will Travel
>804-739-7689
>

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---