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

Hi Evan,

Comments Inline.

-----Original Message-----
From: Evan Harris [mailto:spanner@ihug.co.nz]

Hi Jim

>I need to allow a couple of customers FTP access to our AS/400, which we
>will be opening a port through the firewall for.
>I have created an account, and had it use a group profile, FTPGROUP.  I
>GRTOBJAUT *ALL/QSYS *LIB with *EXCLUDE so this group has no access to any

This may not be a good idea from a performance perspective. It is best to
try and have the lowest access level as *PUBLIC as there is an authority
flag set to indicate that there are authorities with less than *PUBLIC.
Every access is then checked to see if it is in the list before any other
authority is checked.

- I agree, and I think that public should have *EXCLUDE on all libraries,
- Objects, etc... but this system was set up before I got here, and we
- are running a package program.  It would take quite a bit of work to
- get all the authorities straight, and it turns out that we may only
- be using this package for a year or so more anyway.  I'll try my dardest
- to have them let me set up the security on the next package so we actually
- have some security.  But for this instance, it's really not an option at
- this time.

Given what you are doing however, I would be looking to get *PUBLIC set to
exclude on all libraries if I could, and to also make it the default for
new libraries. The new profiles could then be explicitly authorised to just
the libraries they need. I don't know whether I would try and do this with
a group profile - it seems to me that different customers should not be
part of the same group unless they are the same customer with multiple
accounts as this could allow one account to see another accounts data. I
woudl prefer to make this impossible through authorities rather than
segregation by library or directory.

- The customers that will only be allowed FTP access will be a part of the
- FTP group for simplicity in setting up the authorities.  For their own
- libraries and such I am giving each customer explicit access to that
- library.

>I then tried to FTP log this user in to see what error would occur, and I'm
>getting the error:
>530 Not able to set library QGPL for user SHOESPOT; logon rejected.

Is it possible to use the IFS and the user profile HOMEDIR parameter ? I
haven't tried this myself but it might actually be easier; its worth a shot
at least.

- Not sure, haven't tried this yet.  I did find that I also had to give them
- access to the QTCP library and then they could log in.  They still can't
- create a file in their own directory with *ALL access however, and I'm
- trying to determine where that problem lies.  The way I found out they
- needed access to QTCP was to give them all access to all libraries again,
- and then granting them *EXCLUDE to A* libraries, then B* libraries, etc..
- until it failed.  I think I'm going to have to do the same thing to
- what library they need for creating objects.  After I get the libraries
- I'll be fine tuning it to the specific objects.

>which is to be expected.  I then removed the *EXCLUDE for the libraries
>and QGPL, but when I try to log in I get the same error, although this
>should have the default *CHANGE authority to these libraries (hey, I didn't
>set up the security in the first place, I'm not the one who gave everyone
>*change authority to all libraries).

You might find they just used the defaults.....

- Yeah, I think so.  Lazy system setup.

>So, what other libraries/objects/programs do I need to give this group
>profile specific access to?  They will have their own library where they
>will have full access.

As to what else they need, I would have thought what you have done is
enough. What is the  *PUBLIC authority to library QGPL ?

- Answered above.

I presume the account has limited LMTCPB(*YES). I would strongly recommend
you either obtain or write an exit program to prevent - among other things
- cd and ls commands. Your libraries right now all have *EXCLUDE set, but
can you guarantee that any new libraries will have this ? Now and in the
future ? Better that you set up something that requires something be
specifically allowed rather than specifically prevented, if you get my

- Yes, LMTCPB(*YES) and signon program is SIGNOFF.  I plan on isolating them
- eventually to the specific commands they need to FTP files to their
- With access to nothing else.

I would also recommend that you consider a unique profile for each customer
with access to only its own directory, and that the directory be used as a
staging area only (although it sounds like you are doing this) If you use
the same library for all customers as a staging area then there is some
potential for the GETing of data unless you disallow this by the use of an
exit program as well. The FTP exits are in my opinion the easiest of the
three I have had a stab at.

- Doing that.

I would strongly urge you not to allow execution of commands under any
circumstances. Use the presence of a file to trigger an action if you must
have things processed immediately upon upload. It is a small thing to
request a second 1 byte file to be uploaded as a flag to indicate
processing should take place in my opinion. The program that does the
processing should get the data from the staging area as previously
described rather than having data placed in the area it is going to be
placed in.

- I have written procedures in the past to check periodically for files
- and if they are ready for processing without having to do the second
- file flag.  A CL that keeps trying to allocate the object exclusively
- to find out when the transfer is done works.

Hope this assists somewhat

- I also plan on writing an FTP exit program in addition to this security.
- I'm extremely leery about letting outsiders into the computer.


Jim Langston

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