Deploy and run as different user. #2232

Closed
mozeryansky opened this Issue Jun 19, 2016 · 11 comments

Comments

7 participants
@mozeryansky

I have figured out how to run PM2 as another user, but it's not so simple. Basically I just created another user, su into that user, and run PM2 from there. I'm trying to accomplish what nginx and apache do when they run as root, but fork the processes as www-data. I don't see a way to change the user after forking.

I can do this automatically with a startup script. Since init.d is run with root privileges, it can easily change the user.

My problem comes when I also want to use deploy from the local machine. Deploy requires that the same user which ssh's is the one who runs PM2. I (like most) do not allow SSH from root. I was able to to configure my machine to allow my user to su into my "www-data" using /etc/PAM.d/su, but I have hit a road block with the way deploy was written: #2231.

Has another accomplished deploy and a startup script?
Should the related issue be fixed and my workarounds be how it's done?
Can I request that PM2 forks as another user with lower permissions?

@soyuka

This comment has been minimized.

Show comment
Hide comment
@soyuka

soyuka Jun 20, 2016

Collaborator

We removed --run-as-user because it was causing more problems then resolving this particular issue. Starting pm2 from the user that should run the script seems to me to be the best solution.

Collaborator

soyuka commented Jun 20, 2016

We removed --run-as-user because it was causing more problems then resolving this particular issue. Starting pm2 from the user that should run the script seems to me to be the best solution.

@mozeryansky

This comment has been minimized.

Show comment
Hide comment
@mozeryansky

mozeryansky Jun 20, 2016

I did eventually find the issues that talked about that. I did come up with my own method, but I need #2231 to be fixed. Do you have any thoughts on that?

I did eventually find the issues that talked about that. I did come up with my own method, but I need #2231 to be fixed. Do you have any thoughts on that?

@vmarchaud

This comment has been minimized.

Show comment
Hide comment
@vmarchaud

vmarchaud Dec 6, 2016

Collaborator

You can just execute PM2 with PM2_HOME env variable and pm2 will connect to the daemon at the path defined (you need to allow any another user to read the socket file to allow to communicate with the daemon)

Collaborator

vmarchaud commented Dec 6, 2016

You can just execute PM2 with PM2_HOME env variable and pm2 will connect to the daemon at the path defined (you need to allow any another user to read the socket file to allow to communicate with the daemon)

@vmarchaud vmarchaud closed this Dec 6, 2016

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Feb 13, 2017

Contributor

Has the --user option replaced --run-as-user (for example in pm2 start --user someone /path/to/my/app)?
It doesn't seem to have any effect. --user seems to be ignored 😞

Contributor

gkalpak commented Feb 13, 2017

Has the --user option replaced --run-as-user (for example in pm2 start --user someone /path/to/my/app)?
It doesn't seem to have any effect. --user seems to be ignored 😞

@soyuka

This comment has been minimized.

Show comment
Hide comment
@soyuka

soyuka Feb 13, 2017

Collaborator

@gkalpak No you need to start the pm2 binary from that specific user. You could also play with process.setuid but I can not guarantee the outcome.

Collaborator

soyuka commented Feb 13, 2017

@gkalpak No you need to start the pm2 binary from that specific user. You could also play with process.setuid but I can not guarantee the outcome.

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Feb 13, 2017

Contributor

OK, thx for the quick reply. Should the --user option be removed then (from the code and the docs)?

Contributor

gkalpak commented Feb 13, 2017

OK, thx for the quick reply. Should the --user option be removed then (from the code and the docs)?

@soyuka

This comment has been minimized.

Show comment
Hide comment
@soyuka

soyuka Feb 13, 2017

Collaborator

The --user option is only used by the startup command as far as I recall.

Collaborator

soyuka commented Feb 13, 2017

The --user option is only used by the startup command as far as I recall.

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Feb 13, 2017

Contributor

Sorry. You are right!

Contributor

gkalpak commented Feb 13, 2017

Sorry. You are right!

@gkalpak gkalpak referenced this issue in angular/angular Mar 6, 2017

Merged

ci(aio): add initial implementation for aio-builds setup #14330

16 of 17 tasks complete
@jmeit

This comment has been minimized.

Show comment
Hide comment
@jmeit

jmeit Jun 25, 2017

Contributor

Is there any plan to reinstate the --run-as-user option?

Contributor

jmeit commented Jun 25, 2017

Is there any plan to reinstate the --run-as-user option?

@architech99

This comment has been minimized.

Show comment
Hide comment
@architech99

architech99 Sep 22, 2017

@jmeit I was playing around with this because I needed a specific user to execute a process. They don't have the --run-as-user option, but there is the --uid option, which takes the same argument and works just fine.

@jmeit I was playing around with this because I needed a specific user to execute a process. They don't have the --run-as-user option, but there is the --uid option, which takes the same argument and works just fine.

@davidjb

This comment has been minimized.

Show comment
Hide comment
@davidjb

davidjb Mar 20, 2018

Following @architech99's suggestion worked for exec_mode: 'fork' processes, but fell apart for an app using exec_mode: 'cluster'; pm2 was being run as root, and using pm2 start ... --uid foobar to run the processes as the limited-access user foobar. The clustered processes would start but fail immediately, with no error logs seen in pm2 logs, just listed as errored in pm2 status. Removing my error_file option in ecosystem.config.js indicated that pm2 was attempting to write to /root/.pm2/logs/... and getting an access denied message, seemingly indicating the logs were attempting to be written by the limited-access user. That's as far as I went into that problem, but it seems that there's a degree of conflict with where logs are being written to and by whom.

Giving up on using --uid and switching to pm2 startup --user foobar --hp /home/foobar made my config work so that'll do for now. Ideally, a solution to the original problem @mozeryansky raised would be good so one root-level instance of pm2 can run with multiple sub-processes beneath it.

davidjb commented Mar 20, 2018

Following @architech99's suggestion worked for exec_mode: 'fork' processes, but fell apart for an app using exec_mode: 'cluster'; pm2 was being run as root, and using pm2 start ... --uid foobar to run the processes as the limited-access user foobar. The clustered processes would start but fail immediately, with no error logs seen in pm2 logs, just listed as errored in pm2 status. Removing my error_file option in ecosystem.config.js indicated that pm2 was attempting to write to /root/.pm2/logs/... and getting an access denied message, seemingly indicating the logs were attempting to be written by the limited-access user. That's as far as I went into that problem, but it seems that there's a degree of conflict with where logs are being written to and by whom.

Giving up on using --uid and switching to pm2 startup --user foobar --hp /home/foobar made my config work so that'll do for now. Ideally, a solution to the original problem @mozeryansky raised would be good so one root-level instance of pm2 can run with multiple sub-processes beneath it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment