Hello.
I am having problems with the CZCHKCMD exit. In its original version it checked the userid and the command the user entered and determined if the user was permitted to use the command. While debugging it I noticed some odd behavior. I added some WTOs to the program that would display the userid and the command entered. This is when I noticed the problem. If I enter the ls command the WTO displays this on the console. If I enter it a second time, and every time thereafter, nothing displays on the console. If I enter a different command, say cd, the cd command displays fine and then a subsequent ls command will display. However again ls will only display once no matter how many times I enter it.
Also one other odd thing I noticed. The pwd command never displays on the console.
I was convinced I had a bug in my code so I stripped the exit down such that all it did was display the userid and command via a WTO to the console. No other processing was performed. This version of the code exhibited the same behavior.
Next I renamed the CZCHKCMD exit to FTCHKCMD and reassembled/linked it. When I drive the exit via FTP all commands display on the console with no issue.
I setup a trace by adding the following statements to sftp-server.rc:
export SFTP_SERVER_OPTIONS=”-e –l debug3”
export COZ_LOG=T
When I looked in /tmp/sftp-server.isopn.076.123752.67109456.log I noticed this:
ZosSettings[E]: Unknown option: 'reqexits CZCHKCMD'
I don’t understand what I did wrong. I have the following in /etc/ssh/cozsftp_server_config
fixed:
# Specify fixed settings following this line
reqexits CZCHKCMD
Nevertheless the exit is being driven.
Below is the series of commands I entered:
(ISTST@SYSC): /u/istst-> sftp isopn@sysd.companya.com
Connecting to sysd.companya.com...
*******************************************************
* This computer system is for authorized use only. *
* All activity is logged and regularly checked by *
* system administrators. Individuals attempting to *
* connect to, port-scan, deface, hack, or otherwise *
* interfere with any services on this system will be *
* reported. *
*******************************************************
isopn@sysd.companya.com's password:
sftp> ls
file CEEDUMP.20160315.191453.33554831 CEEDUMP.20160316.103249.33554983
sftp> ls
file CEEDUMP.20160315.191453.33554831 CEEDUMP.20160316.103249.33554983
sftp> ls
file CEEDUMP.20160315.191453.33554831 CEEDUMP.20160316.103249.33554983
sftp> cd ..
sftp> ls
isopn
sftp> pwd
Remote working directory: /u/connect/u
sftp> quit
Here is what displayed on the console:
CZCHKCMD->User(ISOPN ) Command(LIST )
CZCHKCMD->User(ISOPN ) Command(CWD )
CZCHKCMD->User(ISOPN ) Command(LIST )
I’m sure you would like to see the trace. If so please provide instructions for doing so.
CZCHKCMD exit
Re: CZCHKCMD exit
What we do in CZCHKCMD is to simulate, as closely as possible, what would happen in the matching IBM FTP exit.
One issue is that there is actually no such think as a CWD command in SFTP. In SFTP, the client just keeps track of what directory he has navigated to. SFTP (the underlying wire protocol) has a "stat" command, which is like a "LIST" of a file or a directory (but not its contents).
What we do is this when we get an SFTP "stat" -
- if it is for a directory, then we call CZCHKCMD with "CWD"
- if it is for a non-directory, then we call CZCHKCMD with "LIST"
- If we get a LIST or CWD for the same file/directory twice in a row, then we don't bother to call CZCHKCMD multiple times.
This is because many SFTP clients will send duplicate "stat" cmds for the same path for some operations.
When you write a CZCHKCMD exit and trace it (see below), you can see this happening.
To get the best tracing for exits, you need "Fine" level:
You can then look specifically for messages from the "ZosExitInterface" component.
Another thing: (UNIX) filename paths in the Co:Z SFTP are normally fully-qualified into exits, where as in FTP they sometimes are/sometimes are not. You need to consider that you can't use CZCHKCMD("CWD") to prevent access to a directory (completely), since directories can just be part of a file path being opened without a prior CWD. If you are sharing the same code with FTP for "security" purposes, you need to handle both cases/conventions.
The problem with this:
You don't mention why you need an exit, but CZCHKCMD is normally for pre-command authorization.
If you are looking for something that runs after a file operation has been done, then look at CZPOSTPR.
Also note: in Co:Z 3.6.0 and later, there is a "console notification" facility that allows you to, without exits, to customize WTO messages for file transfer operations.
One issue is that there is actually no such think as a CWD command in SFTP. In SFTP, the client just keeps track of what directory he has navigated to. SFTP (the underlying wire protocol) has a "stat" command, which is like a "LIST" of a file or a directory (but not its contents).
What we do is this when we get an SFTP "stat" -
- if it is for a directory, then we call CZCHKCMD with "CWD"
- if it is for a non-directory, then we call CZCHKCMD with "LIST"
- If we get a LIST or CWD for the same file/directory twice in a row, then we don't bother to call CZCHKCMD multiple times.
This is because many SFTP clients will send duplicate "stat" cmds for the same path for some operations.
When you write a CZCHKCMD exit and trace it (see below), you can see this happening.
To get the best tracing for exits, you need "Fine" level:
Code: Select all
export COZ_LOG=FAnother thing: (UNIX) filename paths in the Co:Z SFTP are normally fully-qualified into exits, where as in FTP they sometimes are/sometimes are not. You need to consider that you can't use CZCHKCMD("CWD") to prevent access to a directory (completely), since directories can just be part of a file path being opened without a prior CWD. If you are sharing the same code with FTP for "security" purposes, you need to handle both cases/conventions.
The problem with this:
is that you need and equals sign:fixed:
# Specify fixed settings following this line
reqexits CZCHKCMD
Code: Select all
fixed:
# Specify fixed settings following this line
reqexits=CZCHKCMD
If you are looking for something that runs after a file operation has been done, then look at CZPOSTPR.
Also note: in Co:Z 3.6.0 and later, there is a "console notification" facility that allows you to, without exits, to customize WTO messages for file transfer operations.
Re: CZCHKCMD exit
This is good to know. At least now I understand what is going on and it appears everything is working. It's also nice to know that I am not losing my mind 
. I was really scratching my head on this one.
The reason I am using the CZCHKCMD exit is to prevent the usage of certain commands. Specifically I want to prevent the use of the "cd" command. However your statement that "You need to consider that you can't use CZCHKCMD("CWD") to prevent access to a directory (completely)..." has me concerned. I had originally intended to use a chroot jail but based on what I've found so far that does not work too well. Is there a better way to prevent users from escaping from their home directory?
. I was really scratching my head on this one. The reason I am using the CZCHKCMD exit is to prevent the usage of certain commands. Specifically I want to prevent the use of the "cd" command. However your statement that "You need to consider that you can't use CZCHKCMD("CWD") to prevent access to a directory (completely)..." has me concerned. I had originally intended to use a chroot jail but based on what I've found so far that does not work too well. Is there a better way to prevent users from escaping from their home directory?
Re: CZCHKCMD exit
You can certainly check "CD", but you also need to check all fully constructed file paths to prevent someone from using a directory without "CD"ing to it.
So - if you get a UNIX path name -
- if it is absolute (starts with "/") then validate it
- otherwise if relative, then append it to the absolute directory name and then check that.
For checking, you might consider that you should be calling something like "realpath" to resolve the fully qualified path name.
Otherwise, someone could set up a symbolic link to your forbidding directory and then used that as an anchor for the path name.
So - if you get a UNIX path name -
- if it is absolute (starts with "/") then validate it
- otherwise if relative, then append it to the absolute directory name and then check that.
For checking, you might consider that you should be calling something like "realpath" to resolve the fully qualified path name.
Otherwise, someone could set up a symbolic link to your forbidding directory and then used that as an anchor for the path name.