RE: What authorities needed for FTP access?

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
then
>GRTOBJAUT *ALL/QSYS *LIB with *EXCLUDE so this group has no access to any
>library.

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
determine
- what library they need for creating objects.  After I get the libraries
down
- I'll be fine tuning it to the specific objects.

>which is to be expected.  I then removed the *EXCLUDE for the libraries
QSYS
>and QGPL, but when I try to log in I get the same error, although this
group
>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
drift.

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

Regards,

Jim Langston