Run TRSS server as non-root

[sxa]

At the moment (discovered while looking at request #1326) the TRSS server is running as root through forever and started by the TRSS* scripts in /etc/init.d. Running such services as root unnecessarily is undesirable from a security standpoint so we should look at reworking this to run as a non-root user and manage access accordingly.

[Haroon-Khel]

Did this get solved during the recent restart of TRSS?

[sxa]

Did this get solved during the recent restart of TRSS?

Unlikely IMHO

[smlambert]

What alternatives are you aware of, can systemd or something else replace this functionality (that forever service provides)?

[sxa]

Perhaps, although systemd also runs as root. I really need someone to convince me of why forever isn't an option - I've only heard anecdotal reasons so far :-)

I've just tested a basic forever test with a simple app and it works fine as non-root, so I feel there's another underlying reason why we're running as root at the moment which I'd like to understand.

[smlambert]

@llxia - were there other reasons that you are aware of (re: https://github.com/adoptium/infrastructure/issues/1327#issuecomment-1041569904)?

[llxia]

forever cmd does not need root access. However, forever-service uses forever cmd and runs as a service. afaik, we need root access to restart a service.

[sxa]

Even if that requires to be run as root, can the process it maintains be run without it? Presumably if that was the case the TRSS process could be terminated as the non-root user and the forever service would restart it. We are inviting security vulnerabilities if we are running the services as root.

[sxa]

If the reason for forever-service is purely to run at startup, presumably a normal OS startup script on boot could be used that initiated forever running as a non-root user to keep the server running - would that work?

[llxia]

I am not sure if it will work.

[sxa]

We need to find out :-) Can you bring up a new trss on a VM or docker image to verify? Otherwise we'll need some scheduled downtime to experiment with it on the real server. I'm worried that becuase it's been running as root it might have createfd a lot of files that won't be accessible to a non-root user on the production server now, which will require a lot of remediation.

[llxia]

We were hoping infrastructure folks would help with this. I am not an infra expert. And you clearly have the plan in mind. :) There is a playbook for setup TRSS https://github.com/adoptium/infrastructure/blob/911395ff967bfaba397b4ea3ce9bfebfd12d01f5/ansible/playbooks/AdoptOpenJDK_Unix_Playbook/trss.yml

[sxa]

@Haroon-Khel Can you test in a VM whether a TRSS server can be run as a non-root in order to allow non-root users to be able to upgrade and restart the service please?

[Haroon-Khel]

I'll try it on a virtualbox vm

[Haroon-Khel]

When running the forever-service commands as a non root user, I get an error asking for them to be run as root

[Haroon-Khel]

To summarise a lengthy slack thread, I found that the TestResultSummaryService can be started and stopped with the forever tool by a non root user.

forever start backend.js
forever start frontend.js

Both are commands to start up the service, and not the client. Concerning the react client, I am not sure where on the server it is running, so I do not yet know if that can be stopped and started by a non root user

[aixtools]

No idea how forever works, but could the forever service, running as root, start the trss "application" as it does now, except prefix it with su -c username

[llxia]

I am not sure what was changed in your experiment. From TRSS perspective, we do not need to "start" the client. It is a static pre-compiled web client.

IMO, the key problem here is that we need root permission to start a service (i.e., forever-service in this case). And we need the ability to restart the service to pick up new code changes. Note: the forever command or node server does not need root permission.

I think we can use --watch forever option to watch file changes. If it can auto-restart based on the TRSS file changes, then we do not need the ability to restart the service. Therefore, TRSS can be added as a regular Jenkins node. No special permission is needed.

[Haroon-Khel]

From TRSS perspective, we do not need to "start" the client. It is a static pre-compiled web client.

That clears things up. Thanks

[zdtsw]

according to usage: https://github.com/zapty/forever-service/blame/master/README.md#L117 we can use --runAsUser to set run from Jenkins user if we are on a different OS, but *Experimental* Run service as a specific user, defaults to root (No ubuntu support yet)

I think there are some misunderstanding in the above comments:

• to start "forever-service" which need a root user see code: https://github.com/zapty/forever-service/blob/5be2f60015592b2f120049c483551a3f50229222/bin/forever-service#L178
• to run TRSS does not need to be root user, if supply --runAsUser flag when start forever see log from a RHEL OS [root@wenzhou aqa-test-tools]# adduser jenkins [root@wenzhou aqa-test-tools]# /usr/local/bin/forever-service install mockservice --runAsUser jenkins forever-service version 0.5.11 Platform - Red Hat Enterprise Linux release 8.6 (Ootpa)

[llxia]

Thanks @zdtsw for investigating this. To clarify, there are 3 levels here - forever service, forever cmd, and TRSS server. Both forever cmd and TRSS server do NOT need root permission. Permission is needed for restarting the service in general. Also, currently, the TRSS server is on an Ubuntu machine, so the --runAsUser flag does not apply atm.

Anyway, we already have a solution and it is up and running internally. We are using the --watch forever option to watch file changes. And TRSS runs as a regular Jenkins user. Related: https://github.com/adoptium/aqa-test-tools/issues/654

[sxa]

And TRSS runs as a regular Jenkins user.

I believe this is complete. If anyone disagrees or believes additional work is required then it can be reopened.