The first incoming network connection via vsftpd cannot be controlled.

Products

• CA Virtual Privilege Manager
• CA Privileged Identity Management Endpoint (PIM)
• CA Privileged Access Manager (PAM)

Issue/Introduction

Symptoms:

The first incoming network connection from vsftpd after loading kernel module cannot be controlled even though ftp is defined as TCP or HOST rule.

Cause:

vsftpd is listening for incoming ftp connections via the accept system call. This is a blocking operation until a client is attempting to connect. If vsftpd is blocking in the accept system call before CA Privileged Identity Manager (PIM) startup, then it does not get to PIM syscall interception. Therefore, an incoming ftp connection will not be caught or processed by PIM. After vsftpd processes the first ftp connection, it calls accept system call again to wait for more ftp connections. This time, PIM will intercept the accept system call and all subsequent ftp connections will be processed by PIM. This occurs on the platform where streams is not used (Linux and AIX).

Resolution:

Here are three workarounds for this:

1. Restart vsftpd
   
   When restarting PIM including the kernel unloading, restart vsftpd after PIM restart.
   
   When rebooting system, start PIM before vsftpd.
   
   
2. Start vsftpd via super daemon (inetd/xinetd)
   
   Please ask OS/Application vender for detailed configuration.
   
   
3. Run tripAccept after starting AC
   
   tripAccept is a utility we provide which purpose is to wake up all processes that are blocked in the accept system call so the application will recall the accept. You may want to define specialpgm for it not to be denied the connection from it.
   
   
   1. Define specialpgm for tripAccept and set network bypass
      
      eTrustAC> er specialpgm <SEOSDIR>/bin/tripAccept pgmtype(pbn) own(nobody)
      
      
   2. Run tripAccept just after starting AC
      
      # <SEOSDIR>/bin/tripAccept 1 -ports 21

The workaround #3 of tripAccept execution can be controlled by SEOS_syscall.call_tripAccept_from_seload token in seos.ini and also specialpgm for tripAccept is configured by default now.

 

Environment

Release:
Component: SEOSU