urco
urco

Reputation: 189

Rails - Run system command in production

I'm trying to run a C++ executable in my Rails app that is place in a folder called "algo", like this:

result = `cd algo && ./my_main #{str} -1 -1 #{id}`

In development works flawlessly but in production in the cloud does not run

Consider that:

1) In the cloud, that is a virtual machine, i run the same executable without problems in the console terminal navigate through the Rails application folders, it only fails when i try to run it from the Rails application

2)

 Rails.logger.info result

Returns nothing

3)

 Rails.logger.info `pwd`

Does return the current folder of the proyect

4)

Rails.logger.info $?

Only returns: pid 35314 exit 127

5)

  Rails.logger.info File.exist?("algo/my_main")

Returns true

6) In the config/environments/production.rb the log level is config.log_level = :info

7) In the log/production.log does not appear any error like you will see in development in the terminal

8) I also try to use other commands like: system(), exec(), %x() with the same result

9) Finally, i run sudo chmod -R 777 in the virtual machine, in the main folder before the Rails folder app, i think that is implicit in the point 1, but for clarify

Upvotes: 1

Views: 1479

Answers (1)

eirikir
eirikir

Reputation: 3842

You should always use absolute paths for any code that will be executed by a script. The PATH variable may be different for the user executing the script than it is for the user that you use, and its much better to be 100% precise about the file path you want than to rely on PATH.

Along the same lines, make sure the user that runs the Rails server have execute permissions on the script. If in doubt, login as that user and attempt to execute the script.

You also need to escape both str and id for security reasons. Even if these variables are not currently derived in any way from submitted parameters, there's always a possibility that whatever function contains this code might be executed with user-submitted variables at some point. Basically, its better to be safe than sorry, because this is the kind of security hole that could allow anyone on the Internet to execute arbitrary code on your server.

Upvotes: 2

Related Questions