Provide virtual FTP directory

I can only say that I'm deeply disappointed that such an important feature which exists in ALL FTP servers still doesn't exist on IBM i.

It remains an essential feature to provide a secure environment to FTP.

After careful consideration, we know that we cannot deliver your requested enhancement soon due to other higher priority work, so it is being declined. However, your request does align with the future strategy of our product and we believe it may have future value, so we have added it to an internal list for us to keep in mind for the future.

IBM will use this request as input to planning but no commitment is made or implied. This request will be updated in the future if IBM implements it. IBM will use votes and comments from others in the community to help prioritize this request.

With hiding the physical path I mean that the end-user doesn't/shouldn't know what the exact location is on disk. If the virtual directory would point to /home/myapp/upload which contains a file myfile.ext, the end-user should only see it as myfile.ext in the directory / without knowing in which directory it is physically stored (from auditors point of view this is information that shouldn't leak to the end-user).

This is how the dataarea QFTPUSERIS works as well, and which can't be replicated with the current exit programs.

The exit point QIBM_QTMF_SERVER_REQ can be used to check whether the file is valid for get/mget/put/mput/delete/mdelete/rename. It can also be used to check whether a directory can be created/deleted (mkdir/rmdir). Of course, you might have to use POSIX APIs to get the name format without characters(../) and (./). If FTP client is IBM I, "Execute CL command" is also required to be checked.

I am not sure about the meaning of "hide" the physical file. Do you mean to show the file name based on the root directory? Such as, if the root path is /home/abc, and file '/home/abc/def' would be displayed to ftp client side as '/def'? Do you mean to show the file path name which eliminate the characters (../) and (./) ? Such as, /home/abc/d1/d2/../../def would be displayed as /home/abc/def ?

The current exit programs do not allow you to "hide" the physical path (which is a security exposure), and offer several ways in specify target locations (ie. not only via CD, but as well via constructions like ../../../otherdir/file.ext)

Can current 2 exit points supported by FTP server satisfy your requirements?

Now FTP server supports 2 exit points:
1. QIBM_QTMF_SVR_LOGON (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiq/rzaiqlepi.htm)
This exit point takes effect when FTP user is trying to login to the IBM i FTP server.
With format TCPL0200, you can specify the initial current library or initial home directory for each user.

2. QIBM_QTMF_SERVER_REQ (https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaiq/rzaiqsvreqep.htm)
This exit point takes effect when doing FTP commands, such as CD, CDUP etc.
With format VLRQ0100, you can reject or allow an operation for many FTP commands, such as CD, CDUP. If you do not want one FTP user changing directory to outside it's "virtual directory", you can specify one of it's output fields (Allow operation) as 0 reject this operation, for administrator users, setting it as 1 to allow the change directory operation. "Operation identifier" 3 "Set current directory/library" can tell you ftp user is trying to changing directory and the target directory can be found in "Operation-specific information".

You can find further help information in knowledge center.
If you have further questions, please let me know.

The majority of FTP accounts need to be locked into their "virtual" directory, however we also have several other FTP accounts (like for administrators and other configuration tasks) that need to be able to freely navigate in the IFS without the restriction (this would require us to set their default at root).

In addition the global switch is "dangerous" to implement as it might break things, hence the exit program is a method that allows gradual implementation of this feature. In addition it should be applicable to any initial directory provided (like you can in the exit), not specifically a /home/user directory.

Could you describe your business scenario more detailedly ?
Do you mean in the global level to limit all users only access to one directory ?
Why do you think the exit program is better for your business scenario ?

The behavior is what I was looking at but not at a global level (shame this can't be determined in the FTP exit program.

Can this feature meet customer's requirement? http://www-01.ibm.com/support/docview.wss?uid=nas8N1014295
Data area . . . . . . . . . . . > QFTPUSERIS Name
Library . . . . . . . . . . . > QUSRSYS Name, *CURLIB
Type . . . . . . . . . . . . . . > *CHAR *DEC, *CHAR, *LGL, *DDM
Length:
Length . . . . . . . . . . . . > 1 1-2000
Decimal positions . . . . . . > 0 0-9
Initial value . . . . . . . . . > '1'

Setting the Initial value to '0' means that no FTP limitations occur.

Setting the Initial value to '1' means that FTP users who have the Home Directory parameter on their user profile set to /home/username are limited to that directory. Users whose profiles have the Home Directory set to another directory, such as QDLS, will be allowed to connect, but no other limitation occurs.

Setting the Value to '2' means that FTP users who have the Home Directory parameter on their user profile set to /home/username are limited to that directory. However, users whose profiles are set to something other than /home/username will not be allowed to log on the FTP server.

This is a valid requirement and the development is ongoing.

The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed. This is important because this is a security-related issue.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Dawn May - CAAC Program Manager

The Application Administration doesn't allow to do this selectively, users should still be able to navigate within their predefined tree (which we can set via the FTP exit program), however not outside of this tree. Another important aspect is that we can't hide the physical structure on the server, the client just sees the full path instead of the virtual one in which he should be isolated.

.Please provide answer to question posted today by CAAC in the Comment section of this RFE.

The CAAC has reviewed this requirement and would like some additional clarification on this request.

It is assumed this feature exists with Navigator Application Administration; FTP Server and you can control what functions and specifically, changing directories by user or by groups of users.

If this does not meet your needs, please clarify why.

Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

For more information about CAAC, see www.common.org/caac

For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

Dawn May - CAAC Program Manager

Virtual FTP directory.
Function is available.
http://youribmi:2001
Security, Application Administration.
Host Applications, TCP/IP Utilities for iSeries, File Transfer Protocol, FTP Server, Specific Operations, Change Directory, Customized Access
Been there like numerous releases.

IBM will use this request as input to planning but no commitment is made or implied.?? This request will be updated in the future if IBM implements it.

http://www-01.ibm.com/support/docview.wss?uid=nas8N1018589&context=SGYQGH

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Networking
Operating system - IBM i
Source - Other

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - IFS (Integrated File System) and Servers
Operating system - IBM i
Source - Other