Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

OpenVMS Captive FTP account directory

SOLVED
Go to solution

OpenVMS Captive FTP account directory

Has anyone ever created a captive FTP account in such a way that when a user ftps in, it keeps them restricted to their home directory? Not allowing them to cd/set def up a level or to another disk? Similar to the way the anonymous ftp account works. I'm running tcp/ip services 5.3.

Thanks
13 REPLIES
John Gillings
Honored Contributor
Solution

Re: OpenVMS Captive FTP account directory

Kyle,

"not allowing" CD is tricky, but denying access to any files once they're there is easier.

You could create an identifier (say) "FTP_RESTRICTED" which can be GRANTED to any users you want to limit. Access to anything you don't want accessed can be restricted via an ACE:

(IDENTIFIER=FTP_RESTRICTED,ACCESS=NONE)

This can be placed high up in directory trees to prevent access to any files below. (but make sure they have read access to the system disk or else nothing will work).

You can even restrict access when connected via FTP, but not when logged in. For example
(IDENTIFIER=FTP_RESTRICTED+NETWORK,ACCESS=NONE)

There is a logical name TCPIP$FTP_ANONYMOUS_ALIAS which allows you to define multiple anonymous usernames, but I doubt this does what you want.
A crucible of informative mistakes
Karl Rohwedder
Honored Contributor

Re: OpenVMS Captive FTP account directory

We use Hunter Goatlys HGFTP for this, you can set up many different anonymous accounts, for each of them you specify the allowed directories and the allowed commands, e.g. you can disable CD completely. You can run HGFTP in parallel to UCX, just use a different port.

One source e.g. is :
ftp://ftp.tmk.com/vms-freeware/fileserv/
Robert Atkinson
Respected Contributor

Re: OpenVMS Captive FTP account directory

Kyle, we also use HGFTP. The directories are controlled by defining a logical (in LOGIN.COM for us) like this :-

$ DEFINE /PROC MADGOAT_FTP_DIRS FTP$USER_ROOT:[PENGSING...]
$ SET DEF FTP$USER_ROOT:[PENGSING]

HGFTP is far superior the HP's in-built anyway.

Rob.

Re: OpenVMS Captive FTP account directory

Thanks for the replies. I'll evaluate both ideas and see which one works better for us.

Thanks!

Re: OpenVMS Captive FTP account directory

Ran into a little trouble with HGFTP. Does anyone have any trouble with HGFTP bypassing object security? HGFTP, in my case, gives users access to objects that they normally wouldn't have access to under HP TCP/IP services FTP server (ver 5.3).

Swapped back and forth between both ftp servers and get the same result each time.
Martin P.J. Zinser
Honored Contributor

Re: OpenVMS Captive FTP account directory

Hello Kyle,

which version of HGFTP do you have installed?
3.1-1 I think is the current one. If you are at the current one I think some more detailed information on the protection problem you are seeing would be nice. I could get in contact with Hunter to discuss this with him.

Greetings, Martin

Re: OpenVMS Captive FTP account directory

I've been emailing back and forth with Hunter. I was just wondering if anyone else had experienced the same problem.

I'm on the latest version of HGFTP. The account I'm using is a copy of the default account and it's able to view/grab files that it doesn't have permission to while under HGFTP. While FTPing to the same system with the same account when the TCP/IP services FTP server is running instead of HGFTP, the file permissions work as advertised. A sho proc/all on the ftp process ID while I'm logged in with ftp shows no elevated privileges. I don't understand how the user can bypass security when the process doesn't have access to do so.
Martin P.J. Zinser
Honored Contributor

Re: OpenVMS Captive FTP account directory

Hello Kyle,

as I understand it not the "user" is actually accessing the files, but the FTP server process ,and this does have appropriate rights to do so. It is a function of the FTP server to check that the user would have appropriate rights. Since you were already in contact with Hunter, what was his response?

Greetings, Martin

Re: OpenVMS Captive FTP account directory

He's checking code. What version of VMS are you running HGFTP on?
Martin P.J. Zinser
Honored Contributor

Re: OpenVMS Captive FTP account directory

Hi Kyle,

I (as in me) am at 7.3-2. No implications about the company I do work for ;-)

Greetings, Martin
Martin P.J. Zinser
Honored Contributor

Re: OpenVMS Captive FTP account directory

Hello,

Hunter just released a new security update to HGFTP (3.1-2). You might want to check if this does fix your problem (just in case you were not the one causing the update ;-)

Greetings, Martin
Jan van den Ende
Honored Contributor

Re: OpenVMS Captive FTP account directory

Kyle,

we battled with a similar problem, but with a lot of flanking requirements, and confirming system setup.

We got many different applications running on the cluster, and no-one is allowed any access unless specifically authorized.

Every user (UIC-) group has its own top-directory.
Every top-directory for user-environments is ONLY accessible for members of that group.
Every application (and every non-default version of an application, eg. the new-version evaluation, or the training environment) has its OWN rights-identifier _ACCESS WITH THE /DYNAMIC ATTRIBUTE.
For users from different groups that need to exchange files outside of an application a simple "pseudo-applic" is created.
Each application has topdirectory(s) protected by ACL's for the relevant identifier.

And now we are set for the big trick: in SYS$SYLOGIN, if the process mode is "NETWORK", we get the process rightslist ( F$GETJPI("","rightslist") and do a SET RIGHTS/DISABLE for every xxx_ACCESS identifier.
Now any NETWORK process (ie., ftp) can only reach the user-group top-dir (the group itself decides the allowed access WITHIN their group), and potentially any directory(-tree) that is protected by an ACL with any name that does NOT end with _ACCESS and has been granted to the user.

We do have an application in which A LOT of small and big 'projects', running days or years, which are to be accessed by few or many people from different UIC-groups. Quite regularly data has to be exchanged between the app and some external systems using ftp.
Every project creation also creates its own identifier and its own 'exchange'-directory protected by the ID.
(and yes, we really need to, and do, have mechanisms in place to delegate maintaince for this structure in a controlled way).

What this all boils down to: we restrict ANY network access except what is specifically allowed.

Come to think of it:
A rather simple implementation of this would be to create ACL's for every top-dir you got that deny access for the "NETWORK" identifier ( ACCESS=NONE). Should specific access (say, a UIC-group or some individuals, need access over the network, then you enter them before the network identifier.

You want to restrict access to subdirectories?
Simple place the restricting ACL on those subdirectories.

hth,

Jan

Don't rust yours pelled jacker to fine doll missed aches.

Re: OpenVMS Captive FTP account directory

Martin,

Yeah, the 3.1-2 was released last week after he reviewed the code for my problem. He was able to reproduce the problem on Itanium.

3.1-2 did fix my problem.

Thanks for letting me know,

Kyle