[ Content | View menu ]

su vs sudo

Опубликовано 10.11.2008

С давних времен многих смущает разнообразие вариантов обеспечения безопасности при выполнении операций с максимальными привилегиями. Например, в официальной документации ubuntu в качестве команды редактирования рекомендуется использовать что-то вроде sudo nano, а в многочисленных любительских мануалах (в стиле «5 фокусов в командной строке, которые удивят вашу бабушку») для получения root’ового шелла предлагается писать «sudo su -». Попробую объяснить, почему такое положение вещей кажется мне неправильным.

Исторически единственным универсальным способом выполнить команду от имени другого пользователя в Unix была программа su. Запущенная без параметров, она запрашивала пароль суперпользователя и в случае успеха просто подменяла текущее имя пользователя на root, оставляя почти все переменные окружения от старого пользователя (кроме PATH, USER и еще пары-тройки, см. man su от своего дистрибутива). Более правильно было запускать ее как su - — в таком случае оболочка получала также и правильный environment. С параметром -c можно было выполнить команду: su -c "vim /etc/fstab".

При этом пользователям приходилось помнить пароль root’а и у всех пользователей, перечисленных в группе «0″ (т.е. в группе, члены которой могли выполнить команды su и стать суперпользователем), был одинаковый неограниченный доступ ко всей системе, что являлось серьёзной проблемой безопасности.

Затем появилась команда sudo, и это был прорыв. Теперь администратор мог указывать список разрешенных команд для каждого пользователя (или группы пользователей), файлы, доступные для редактирования, специальные переменные окружения и многое другое (все это великолепие управляется из /etc/sudoers, см. man sudoers от своего дистрибутива). При запуске sudo спрашивает у пользователя его собственный пароль, а не пароль root. Полноценный шелл можно получить с помощью «sudo -i»

Стоит особо упомянуть о специальной команде sudoedit, безопасно запускающей редактор, указанный в переменной окружения $EDITOR. При более традиционной схеме редактирование файлов производилось примерно так:

sudo vim /etc/fstab

Запускаемый таким образом vim наследовал оболочку с неограниченными правами и через :! пользователь мог запускать любую команду (если, конечно, админ не позаботился об этом заранее) и открыть любой файл.

sudoedit проверяет, можно ли этому пользователю изменять данный файл, затем копирует указанный файл во временный каталог, открывает его в редакторе, после редактирования, если файл был изменён, с особыми предосторожностями копирует его обратно.

В Debian-based дистрибутивах пользователь root не имеет пароля, вместо этого все административные действия должны производиться через sudo или его графический аналог gksudo. Являясь полной заменой su, sudo должна бы быть единственной командой переключения между пользователями, однако, как было сказано вначале, в настоящий момент это не так и все зачем-то изобретают дикие последовательности из sudo, su, vi и черточек.

Поэтому предлагаю всем раз и навсегда запомнить:

выполнить команду от имени root: sudo command
редактирование файлов от имени root: sudoedit file
оболочка root: sudo -i

Upd. Тут коллеги в комментариях жалуются на то, что sudo echo 1 >> /etc/apt/sources.list не работает. Это происходит потому, что права повышаются только для команды echo, а результат уже перенаправляется в файл с правами обычного пользователя. Чтобы добавить что-нибудь в privileged_file, нужно выполнить такую команду:

echo 1| sudo tee -a privileged_file >/dev/null
«
»

10 комментариев

Write a comment - TrackBack - RSS Comments

  1. Comment by Flycat:

    Я привык вместо

    sudo -i

    говорить

    sudo su -

    10.11.2008 @ 11:43
  2. Comment by Alexandr Y T:

    Только как объяснить такое в Ubuntu?
    ~$: udo echo «1″ >> /etc/apt/sources.list
    bash: /etc/apt/sources.list: Permission denied

    И такая команда срабатывает только под root.

    10.11.2008 @ 12:01
  3. Comment by EugeneVC:

    команда в ее написании вообще не сработает ))
    нада так
    sudo echo “1″ >> /etc/apt/sources.list

    еще пару копеек
    su – postgres – работаем под юзером postgres

    10.11.2008 @ 13:37
  4. Comment by bappoy:

    Flycat, зачем запускать две команды, когда можно обойтись одной? все равно, что писать «echo `echo 123`»

    EugeneVC, Alexandr Y T:
    в случае «sudo echo 1 >> privileged_file» повышение прав происходит только для команды echo, результат уже перенаправляется в файл с правами обычного пользователя. Чтобы добавить что-нибудь в privileged_file, нужно выполнить такую команду:

    echo 1| sudo tee -a /etc/apt/sources.list >/dev/null
    
    10.11.2008 @ 14:49
  5. Comment by stanislav:

    > В Debian-based дистрибутивах пользователь root не имеет пароля [...]

    Так бы и написали – в Ubuntu :)

    10.11.2008 @ 16:17
  6. Comment by vti:

    Для перенаправления можно использовать sudo так:

    sudo sh -c ‘echo 1 > /proc/sys/net/ipv4/ip_forward’

    10.11.2008 @ 16:32
  7. Comment by Alexandr Y T:

    Пасибо!

    12.11.2008 @ 12:28
  8. Comment by Df_Yz:

    Оба варианта имеют право на существование, ибо, согласно философии Unix, должно быть несколько средств достижения одной и той же цели.

    И никто не вправе решать, что из этого «правильнее».

    17.11.2008 @ 16:21
  9. Comment by alex4:

    >И никто не вправе решать, что из этого “правильнее”.

    Каждый решает сам и использует то, что ему больше нравится.
    И от чего интересно люди такой бред пишут. Видимо C++ вконец проел мозги

    14.05.2009 @ 07:39
  10. Comment by Chel:

    автор какойто долбоеб…»Поэтому предлагаю всем раз и навсегда запомнить:»…И как это называется? Кто ты такой чтобы всем указывать?

    10.11.2009 @ 22:52
Write comment

Я не робот.