sudo e sudo -i caratteristiche di accesso

Quali sono le differenze di privilegio tra sudo e sudo -i?

Con sudo è

  • Rappresentazione ottale delle autorizzazioni di file / cartelle usando awk?
  • SSH: su root o sudo?
  • il sudo non funziona anche se la properties; ei modi impostati correttamente
  • chmod -R 777 / su ubuntu - numerosi problemi
  • sudo non funziona su alcuni comandi
  • Perché il command sudo richiede molto tempo per eseguire?
  •   $sudo echo "search foo.bar.baz" >> /etc/resolv.conf bash: /etc/resolv.conf: Permission denied 

    … e con sudo -i

      $sudo -i #echo "search foo.bar.baz" >> /etc/resolv.conf 

    …Funziona. I privilegi sono:

      drwxr-xr-x 166 root root 12288 2009-10-17 21:02 . -rw-r--r-- 1 root root 42 2009-10-17 20:55 /etc/resolv.conf 

    Sono stata una sorpresa che questi comandi abbiano un comportmento diverso, cosa fa sbagliare la versione del sudo giusto?

  • Errore di authorization timestamp linux con winscp
  • Copiare le autorizzazioni di file, ma non file in Unix
  • etckeeper, checkout Git e le autorizzazioni di file interrotte in / etc
  • Come impostare le autorizzazioni per utilizzare 'ls'
  • Samba / Cifs: Trasferimento di bit di authorization eseguibili al client linux
  • push impegna a git (gitolite) repository messes up permessi di file (nessun accesso trac più)
  • 3 Solutions collect form web for “sudo e sudo -i caratteristiche di accesso”

    Nel primo esempio, il reindirizzamento sta accadendo nella shell corrente e non nella suole subdola. Così sudo esegue echo "search foo.bar.baz" e restituisce il risultato alla shell corrente, che poi cerca di scrivere in /etc/resolv.conf .

    Potresti fare il primo esempio di lavoro richiamando bash direttamente come il tuo command sudo:

     sudo bash -c "echo 'search foo.bar.baz' >> /etc/resolv.conf" 

    Con sudo è ansible utilizzare un command con privilegi di amministratore.
    Con sudo -i si accede all'account root, con le proprie variables di shell e ambiente.
    Altrimenti è ansible utilizzare sudo -s , con cui si accede all'account root ma rimane con il tuo shell e le variables.

    La cosa è che con sudo -i si può get un'altra shell e un altro $ PATH che può risolvere il problema.

    Dalla manpage sudo:

     -i The -i (simulate initial login) option runs the shell specified in the passwd(5) entry of the user that the command is being run as. The command name argument given to the shell begins with a '-' to tell the shell to run as a login shell. sudo attempts to change to that user's home directory before running the shell. It also ini‐ tializes the environment, leaving TERM unchanged, setting HOME, SHELL, USER, LOGNAME, and PATH, and unsetting all other environment variables. Note that because the shell to use is determined before the sudoers file is parsed, a runas_default setting in sudoers will specify the user to run the shell as but will not affect which shell is actually run. 

    Il problema che si sta facendo è che la shell applichi solo la sudo alla prima parte della pipeline che hai costruito. Il >> etc funziona come autorizzazioni piuttosto che root.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.