× 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: FTP server authority issue & adoption
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: Wed, 21 Oct 1998 19:54:16 -0400


Date:   10/21/98  5:38 PM

RE:     FTP server authority issue & adoption

Bruce

Thanks for the reply,  I kinda know the who's anyway.  It's still 
unfortunate that the AS/400 implementation of Unix/Posix was that 
pure.  Meaning once again, we have to live with the lowest common 
denominator.   I truly understand the why's from a business sense(cents)
that it would be easier to port an Unix app and have authority behave 
the same.  

Still, Having to have QGOD run your job accessing the IFS  F@#$%ng S#@$ks.
(I am from NY).   It eliminates using a Job Scheduler to do it, etc. etc.

The swapping of user profiles, from an AS/400 concentric perspective,
is perverse to say the least.  

Thanks again for your response, and say Hi to Ray for me.

John Carr
EdgeTech  -  Have Classes,  Will Travel 

------------------------------------
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
+---
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.