Problem

What are the pros and cons for a non-root installation of SecureTransport on Linux?

Resolution

Cons when using non-root installation

User home folders

On non-root installation all users home folders are using the same ownership and permissions of the non-root account running the SecureTransport services, UID:GID included.

Port numbers

On non-root installations you cannot use the default ports like 21 for FTP, 80 and 443 for HTTP, 22 for SSH, 444 for Admin, but rather 8021, 8080, 8443, 8022, 8444 etc.

NFS

Mount options for NFS storage must use the non-root privileges, so that the ST non-root account can write and read from the shared storage.

Folder Monitor

Files in the upload folder are owned by the user running the SecureTransport Server.
The user running the SecureTransport Server must have the necessary permissions to overwrite files.
The user running the SecureTransport Server must have the necessary permissions to write to the upload folder.

Use of Real Users

OS Real Users cannot be granted access to SecureTransport application when it is running as non-root account.

Crontab

If SecureTransport is installed to run with a non-root user, the crontab file is named after the non-root user. In some environments crontab permissions are not granted to non-root users, therefore additional configuration from SecureTransport (upon install and upgrade) is used to skip the step of trying to access the crontab (upon install ST will try to create entries in crontab for the rotate and monitor scripts, refer to the SecureTransport Installation Guide).

ST started with wrong user

The most common issue we have met in our experience is when a non-root installation is started (or stopped) with the root user due to administrator error. The issue can cause services to fail to start or operate correctly, but it is easily reversible by stopping all services (forcing stop in some cases, kill -9) and changing recursively the ownership of SecureTransport installation folder and Axway installer folder.

Pros when using non-root installations

Security

Security wise non-root cannot be used to elevate system privileges and access OS wide configuration or damage critical system elements.

Lower risk

Lower risk of destroying/damaging installations due to user/admin error.

Permissions tightening

The SharedFolder.Application.Default.Directory.Permissionsconfiguration option in SecureTransport is only available for non-root installations, while in root deployments the permissions of a Shared Folder are always wide open (777).