linux - Understanding implications of sudo -u -H

07
2014-07
  • James C

    I'm trying to install gitlab from this guide on Ubuntu 14.04 Server. It is also worth mentioning that I'm behind a http proxy. I'm having problems with this line in particular:

    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-9-stable gitlab

    I have hhtp_proxy environmental variable set but according to some reading about that I've done you need to set proxy details for git independently by issuing the following command:

    git config --global http.proxy http://some.proxy.com:8080
    

    So with that set I wanted to try and understand the sudo -u <user> -H <command> syntax.

    From reading the sudo man page for the -u -H flags, -u will mean the command will be executed as the git user. -H sets the HOME environment variable to the homedir of the target user. That all makes sense since the git user is supposed to own the gitlab service.

    git clone <url to repo> -b 6-9-stable gitlab will pull down the repository at the specified url, assign it to a new branch called 6-9-stable and place all the contents of the repo in the gitlab directory.

    The problem is when I run:

    `sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-9-stable gitlab
    

    The connection fails with the following output:

    Cloning into 'gitlab'...
    fatal: unable to access 'https://gitlab.com/gitlab-org/gitlab-ce.git/': Failed to connect to gitlab.com port 443: Connection timed out
    

    I've also tried dropping the s in https since I know port 443 is synonymous with SSL/TLS but I still get the same output ... which I don't really understand.

    However If I just run:

    git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-9-stable gitlab
    

    The repo downloads fine. Now I know I could just move it to ~/git and perform the appropriate chmod / chown but I'd really like to understand why I am seeing this behaviour and how to get the desired outcome using sudo -u <user> -H <command> syntax.

    Many Thanks In Advance :)

  • Answers
  • private_meta

    Apparently the command git config --global http.proxy http://some.proxy.com:8080 only works on a per-user base.

    If you use your git clone call with user git, you have to use your git config call with the user git as well.


  • Related Question

    linux - Passing PATH through sudo
  • whitequark

    In short: how to make sudo not to flush PATH everytime?

    I have some websites deployed on my server (Debian testing) written with Ruby on Rails. I use Mongrel+Nginx to host them, but there is one problem that comes when I need to restart Mongrel (e.g. after making some changes).

    All sites are checked in VCS (git, but it is not important) and have owner and group set to my user, whereas Mongrel runs under the, huh, mongrel user that is severely restricted in it's rights. So Mongrel must be started under root (it can automatically change UID) or mongrel.

    To manage mongrel I use mongrel_cluster gem because it allows starting or stopping any amount of Mongrel servers with just one command. But it needs the directory /var/lib/gems/1.8/bin to be in PATH: this is not enough to start it with absolute path.

    Modifying PATH in root .bashrc changed nothing, tweaking sudo's env_reset and env_keep didn't either.

    So the question: how to add a directory to PATH or keep user's PATH in sudo?

    Update: some examples

    $ env | grep PATH
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/var/lib/gems/1.8/bin
    $ sudo cat /etc/sudoers | egrep -v '^$|^#'
    Defaults    env_keep = "PATH"
    root    ALL=(ALL) ALL
    %sudo ALL=NOPASSWD: ALL
    $ sudo env | grep PATH
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
    

    Also I can say that it works exactly this way in Debian stable (lenny) too.


  • Related Answers
  • jonnybot

    Struggled with the same problem for a few hours. In debian lenny, you can fix it by adding

    Defaults        exempt_group=<your group> 
    

    to the sudoers file.

    This is the only way to go around the compiled --secure-path option, (as far as I know).

    Notably, this will also exempt users from needing to enter their password when they sudo.

  • Draemon

    If you have secure_path set in /etc/sudoers, you can play with env_reset / env_keep all you like and it won't make any difference to the path. If you see something like this, comment it out.

    Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin
    
  • dubiousjim

    I'd say look into the env_reset and env_keep options in man sudo. But it sounds like you've already done that (you just mistakenly call env_keep "keepenv"). If you disable the env_reset option (default is enabled), I think it's not supposed to erase any env variables. But this is less secure.

    There's also a secure_path option to sudo; I think this is enabled by default. You could try disabling it.

    The preceding options are set in your /etc/sudoers file. There's also the -i command-line option to sudo. That will cause sudo to run /root/.profile or /root/.login. You could set your desired path there.

  • Emmel

    Well, you're doing something wrong. Also, you didn't specify what you did with your /etc/sudoers file. Here's what you should've done -- this is a CentOS system, BTW:

    First, this is with the right env_keep setting (notice PATH is in there):

    sudo grep -5 PATH /etc/sudoers Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR \ LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \ LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \ LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \ LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \ _XKB_CHARSET XAUTHORITY PATH"

    Defaults   timestamp_timeout = 15 
    
    ## Next comes the main part: which users can run what software on 
    ## which machines (the sudoers file can be shared between multiple
    
    -> export PATH=$PATH:hithere
    -> sudo sh -c 'echo $PATH'
    /sbin:/bin:/usr/sbin:/usr/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/bin:hithere
    

    Looks good. Now let's remove the env_keep setting and try again:

    -> sudo visudo
    -> sudo grep -5 PATH /etc/sudoers
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME \
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION \
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC \
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS \
                        _XKB_CHARSET XAUTHORITY"
     #_XKB_CHARSET XAUTHORITY PATH"
    

    What a sad PATH:

     -> sudo sh -c 'echo $PATH'
     /usr/bin:/bin