Starting Rails Console: permission errors


(Andrew Kraut) #1

I’m trying to open the rails console, but it’s failing with Permission denied - /root/.pryrc (Errno::EACCES).

Longer snippet:

root@uhacc:~# cd /var/discourse/
root@uhacc:/var/discourse# ./launcher ssh app
WARNING: No swap limit support
lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory
lastlog_openseek: Couldn't stat /var/log/lastlog: No such file or directory

Welcome to Discourse Docker


Use: rails, rake or discourse to execute commands in production

root@uhacc:~# rails c
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:81:in `realpath': Permission denied - /root/.pryrc (Errno::EACCES)
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:81:in `realpath'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:81:in `real_path_to'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:76:in `block in rc_files_to_load'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:76:in `map'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:76:in `rc_files_to_load'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:64:in `load_rc_files'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/pry_class.rb:126:in `initial_session_setup'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/cli.rb:206:in `block in <top (required)>'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/cli.rb:83:in `call'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/cli.rb:83:in `block in parse_options'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/cli.rb:83:in `each'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/lib/pry/cli.rb:83:in `parse_options'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/pry-0.10.1/bin/pry:16:in `<top (required)>'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/bin/pry:23:in `load'
        from /var/www/discourse/vendor/bundle/ruby/2.0.0/bin/pry:23:in `<main>'

(Jens Maier) #2

Try this:

cd /var/discourse
./launcher ssh app
sudo -iu discourse
rails c

(Andrew Kraut) #3

It seems like the container is messed up?

root@uhacc:~# sudo -iu discourse
discourse@uhacc:~$ rails c
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
discourse@uhacc:~$ ls -l /usr/bin/sudo
-rwxr-xr-x 1 root root 155008 Feb 10  2014 /usr/bin/sudo
root@uhacc:~# chmod u+s /usr/bin/sudo
root@uhacc:~# sudo -iu discourse
discourse@uhacc:~$ rails c
discourse is not in the sudoers file.  This incident will be reported.

I built this instance using the Install Discourse on DigitalOcean docs, so it seems like something went awry and the containers didn’t get build properly.


(Jens Maier) #4

The shims for rake and rails are getting in the way. On the one hand, they don’t properly switch to the discourse user, which is why pry is trying to read its configuration from root's home directory, while on the other hand not checking who’s invoking them.

Try su - discourse instead of the sudo line. This should reset the environment to a state as if the discourse user had logged in, so do check your environment variables; you may need to export RAILS_ENV=production.


(Andrew Kraut) #5

So, su - discourse gives me the same “not in sudoers” error. If I add discourse to sudoers it works. It seems like this is stuff that should be properly setup within the container. Right?


(Jens Maier) #6

What? Are you sure you’re running the su line as root?


(Andrew Kraut) #7

Sorry, that was unclear. After I’ve become the discourse user (either via su - or sudo -iu) the rails command gives the

error (or if I’ve set /usr/bin/sudo suid, the

error).


(Jens Maier) #8

Hm… well, too bad, I give up. My Discourse is set up manually, so I can’t repro this, and it seems the Docker base image and template scripts implement quite a few customizations. Sorry.


(Sam Saffron) #9

Have you tried?

cd /var/discourse
git pull
./launcher rebuild app

(Andrew Kraut) #10

I rebuilt the app about an hour ago, git pull tells me I’m up to date on master.


(lid) #11

it is not clear from your last response if the rebuild helped or not, but for what it is worth try

launcher enter app


(Andrew Kraut) #12

Rebuilding the app was not successful. ./launcher enter app gives me an environment that seems to be identical to ssh. /usr/bin/sudo is still not set suid, the discourse user is still not in /etc/sudoers and it drops me into the environment as root.


(lid) #13

I have suggested the enter option because that is what working for me.
$>launcher enter app

You should be able to run even as root without any changes.
$> rails console

Are you getting it on a fresh build?

Did you at any point run
$> bundle update
Which will update all the projects gems. and may mess up your environment.
(don’t ask how I know :wink: )

But technically a successful launcher rebuild app should fix it.


what do you mean here?



(Andrew Kraut) #14

Rebuilding the app doesn’t change anything. I have all the same sudoers issues, rails crashing, etc problems I did before. ./launcher enter app drops me in as root just the same as ./launcher ssh app does.

In either case (enter or ssh) in order to get rails console to work after a rebuild I have to (inside the container) chmod u+s /usr/bin/sudo and add the discourse user to /etc/sudoers. Additionally, after enter or ssh into the container, I have to either sudo -iu discourse or su - discourse


(Jeff Atwood) #15

How did you install this instance of Discourse? Did you follow our official install guide? What is the OS it is running on?


(Andrew Kraut) #16

This is a stock Ubuntu 14.04 1GB droplet on DigitalOcean that I installed using this guide: INSTALL-digital-ocean.md. After I installed it, I restored a backup.


(Luke Chamberlain) #17

I’ve just run into this.
This is a Discourse instance on Ubuntu 14.04 installed via the official guide.

I’ve worked around it by adding -H to the rails wrapper:

#!/bin/bash
# If they requested a console, load pry instead
if [ "$@" == "c" -o "$@" == "console" ]
then
 (cd /var/www/discourse && RAILS_ENV=production sudo -H -E -u discourse bundle exec pry -r ./config/environment)
else
 (cd /var/www/discourse && RAILS_ENV=production sudo -H -E -u discourse bundle exec script/rails "$@")
fi

From the sudo man page:

The -H (HOME) option requests that the security policy set the HOME environment variable to the home directory of the target user (root by default) as specified by the password database. Depending on the policy, this may be the default behavior.

Perhaps the default policy changed in the image at some point?
I’ll have to look further.


(Sam Saffron) #18

Thanks for that, just pushed a fix

@akraut try a rebuild.


(Andrew Kraut) #19

Works for me!


(Jeff Atwood) #20