Re: What authorities needed for FTP access?

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.

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.

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

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

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

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.

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.

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.

Hope this assists somewhat

>Regards,
>
>Jim Langston
>_______________________________________________
>This is the Security Administration on the AS400 / iSeries (Security400)
>mailing list
>To post a message email: Security400@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/security400
>or email: Security400-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/security400.