Good Evening everyone,
Does anyone a hint or solution to following problem/request:
Our Department wants to provide an FTP Agent as service to other departments.
The FTP Agent should run on our (Dept-) Server.
The other Departments get access via CONN Object.
AE Version 11.2
RA FTP Solution 4.0.0
Security Issue: the - Local File system tab within RA FTP Jobs offers access to the (whole) OS where the Agent is runnin g on. So one Department is able to see (and copy) files of another department what is forbidden.
If we limit the user (who starts the RA FTP Agent) to one directory only the security issue keeps the same - one dept could see/copy/use/delete files of another department.
I did not find any possibility (on Automic or RA FTP side) to limit LOCAL credentials of the RA FTP Agent.
Currently I see following - unsatisfying - possibilities:
* use one FTP Agent per department
* start FTP Agent on demand with different OS users (and different folder credentials)
Any other good ideas that could help in this case?
many thanks in advance!
I think the security system could be used to restrict which CONN objects a user may access?
But the CONN object does not allow any way to restrict access to the local file system the agent is running on, it only deals with the remote end?
No, i think this is a shortcoming of product design and hence, an "idea" would need to be filed.
You can limit the entire agent to a single directory or subdirectory (chroot) or do stuff with Kernel frameworks such as selinux. But whatever you do there, the agent runs as one user, and has read local file system access as that user, and as such there likely won't be any way to allow or disallow one agent access to local directory based on the Automic user - since afaik Automic simply didn't build that into the agent.
I'm afraid you'll end up running several agents, each under a different OS user, and then use OS permissions to structure the local file system access of these agents. Which may also inflate your license usage
Carsten Schmitz wrote:I'm afraid you'll end up running several agents, each under a different OS user, and then use OS permissions
Carsten Schmitz wrote:
I'm afraid you'll end up running several agents, each under a different OS user, and then use OS permissions
Yeah I am afraid too that this is the only feasible solution.
Seems to be a classical %%%&&&%%% Solution :-)
Isn't that their slogan?
Automic - We %%%&&&%%% Business.
*) it's "automate", of course