|
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
