Help:Sudo Policies

From Wikitech
Jump to: navigation, search

When you attempt to run a sudo command, e.g. sudo su, you may get the response username is not allowed to run sudo on instance-name. This incident will be reported. If you don't require restricting access on the project and you're a projectadmin, then you can add yourself as a sudoer via Special:NovaSudoer.

  1. Click on “Create Sudo Policy” for a given project
    • Name - enter whatever you’d like, e.g., “default”
    • Users - check specific user(s) or ALL
    • Hosts - check ALL
    • Commands - enter ALL into the textfield
    • Options - leave it blank

Note: changes take effect immediately

After logging in to your instance, test sudo by typing sudo echo 'it works'. You will be prompted for your password: enter the same password you use to access Labsconsole and Gerrit.1. If "it works" is echoed back to you then you will retain sudo access for the remainder of your session. Note that passwordless sudo access is now enabled.

1. Note that this password should be at least as secure if not more secure than your SSH identity password.

Workaround for sudo -u

Some installation guides (notably for the OSM tile server) ask you to run "sudo -u someuser" commands.

These commands will fail on EQIAD instances with "Sorry, user X is not allowed to execute 'Y' as someuser on Z.eqiad.wmflabs"

The workaround is to first run: sudo su && su someuser && bash

Then run the next command normally.

An alternate solution is to run the sudo under sudo!

$ sudo -u www-data whoami
[sudo] password for bd808: ^C
$ sudo -- sudo -u www-data whoami

Why does this work? The first sudo changes your effective user id to 0 (root). Then the second sudo is executed which changes the effective user id again and then executes the desired command.