LINUX.ORG.RU

sudo вроде
sudo installpkg
...
anonymous
()

man sudo

man visudo

можно прописать или всё для использования или отдельные команды.

Ygor ★★★★★
()

Настроил sudo чтобы не сидеть под рутом

Настроил

Тогда в чём проблема?

anonymous
()
Ответ на: комментарий от lukman

использовать su

да, правильнее будет сделать

sudo passwd -l root
после чего забыть про su, в этом сакральный смысл sudo)

anonymous
()
Ответ на: комментарий от anonymous

Это только один из подходов, так делают в Ubuntu, например. В OpenBSD, где sudo вроде и изобрели, никто не предлагает блокировать root.

anonymous
()

Для этого sudo не нужно.
Нужен root:
$ su -
#
Выполнить необходимое, Ctrl+D.

sudo нужно, когда надо отдать выполнение отдельных команд другому человеку, не передавая ему пароль рута.

bormant ★★★★★
()
Ответ на: комментарий от bormant

Возможно я не так понял ТС, если речь про другого пользователя, то да, нужно настраивать sudo.

$ su -
#
Выполнить необходимое, Ctrl+D.

Именно так работаю на локалхосте.

lukman
()

Про PATH уже сказали выше. В Slackware утилиты администратора лежат в /sbin, /usr/sbin, но у обычного пользователя эти каталоги в PATH не включены. Поэтому их можно позвать либо по полному пути, либо добавить пользователю в PATH эти каталоги.

Куда добавлять? Читаем man bash, смотрим, что исполняется в каком случае, добавляем
PATH=«/usr/sbin:/sbin:$PATH»

bormant ★★★★★
()
Ответ на: комментарий от bormant

Через bashrc? Я его вообще не нахожу в системе.

sholmes
() автор топика
Ответ на: комментарий от bormant

$ su -

это сильно лучше, чем «sudo bash»?

sudo нужно, когда

а кто определяет «нужность», где стандарт? разве что «sudo в _этом_ случае не обязательно»

да и вообще нафига еще одна команда с suid-битом, если можно обойтись sudo?

anonymous
()

Ты не можешь найти через path sbin проги?


PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH

coyotl
()
Ответ на: комментарий от sholmes

можно

Кто ж вам запретит?

не нахожу

Если файл будет, bash будет читать его в соответствующем варианте запуска. Не бойтесь создавать файлы.

sudo bash

Нафейхоа? man sudo на предмет "-i":
$ sudo -i

Не забывайте про отличия регистрационной оболочки (login шелла).

Нужность определяет системный администратор, организуя те или иные варианты разделения доступа. Но также есть и устоявшиеся варианты применения ПО, учитывающие его возможности.

bormant ★★★★★
()
Ответ на: комментарий от bormant

$ su -

это сильно лучше, чем «sudo bash»?

$ sudo -i

у вас пейс отклеился

Нужность определяет системный администратор

тогда зачем говорить с позиции абсолютной истины

anonymous
()
Ответ на: комментарий от anonymous

абсолютной

Окститесь.
Slackware по умолчанию использует модель с su. Для выполнения административных задач этого достаточно. Необходимость в sudo возникает при желании реализовать варианты, которые шире умолчального. При желании можно настроить sudo и без необходимости, просто из любви к. Кто ж запретит?

пейс

Зачем избыточные «sudo bash» или «sudo bash -l», когда в «man sudo» описано, как именно получать аналог одного и другого? Речь была про ненужность лишнего «bash».

bormant ★★★★★
()

тобы пользователь мог вводить через sudo команды вроде installpkg, upgradepkg, fdisk и тд?

А смысл? Почему пользователь должен иметь права модифицировать систему? И если он имеет такие права, то какой смысл в руте?

Настроил sudo чтобы не сидеть под рутом,

Чтобы сказать пасанам что ты ровный, под рутом не сидишь? При том что у тебя пользователь вместо рута? Бессмыслица. Я к примеру вообще судо не пользуюсь. Просто обычно где-то под рукой мотыляется su терминал.

чтобы не сидеть под рутом

Вообще на сколько я понимаю, эта сакральная догма «не сидеть под рутом» подразумевает «не логиниться в иксы как рут», либо в tty не запускать от рута пользовательские приложения. Но в среде пользователей убунту, на сколько я понял, почему-то стало бытовать представление, что «не сидеть под рутом» означает долбить как дятел sudo перед каждой командой требующей верхних прав. Почему? Стадный инстинкт, и только.

Csandriel_forever
()
Ответ на: комментарий от anonymous

да и вообще нафига еще одна команда с suid-битом, если можно обойтись sudo?

Команда с suid битом не делегирует прав порождаемым процессам. Она запускается типа от имени владельца (кем бы он ни был), но не может порождать процессы с теми же правами. На сколько я помню. В то время как программы запущенные от суперпользователя передают те же права всем своим наследникам, в случае если порождают новые процессы.

Csandriel_forever
()
Ответ на: комментарий от bormant

Slackware по умолчанию использует модель с su.

идеально для отсылки к администрированию

Речь была про ненужность лишнего «bash».

Нет. Речь была о «su -» vs sudo ... , bash или без не принципиально. Специально же процитировано три уровня. Давай ты будешь интерпретировать за меня

anonymous
()
Ответ на: комментарий от anonymous

давай

Давай буду интерпретировать за тебя. Мне-то уж точно виднее, на что я отвечал про «sudo -i» (на «sudo bash»).

Теперь про su vs. sudo. Про ТС ясно, он пока не знает, зачем ему sudo, но так или иначе нужен. Ок. Основное отличие - для sudo пользователь вводит свой пароль (не знает пароля рута), для su вводит пароль рута (хотя и тут можно поменять на свой, да).

Когда для административных задач нужна рутовая оболочка, оба средства могут ее предоставлять:
$ sudo -i
$ su -
Оба варианта дают рутовый логин-шелл с отработавшим /etc/profile.

Когда достаточно одной команды:
$ sudo команда параметры
$ su -c 'команда параметры'
Вот тут видно, что вариант с su менее удобен — из-за открытой строки не работает автодополнение — основная сила комстроки.

Кроме того, легко накосячить в таком варианте:
$ su
без "-" или "-l" позволит насоздавать в домашнем каталоге пользователя и иных (например, в /tmp) доступных только руту и недоступных этому пользователю файлов и каталогов, чему потом будет много удивления и рассказов про кривой софт (а не кривые руки).
Объем наследуемого окружения, безусловно, настраивается у обоих, но по умолчанию будет вот так.
Ограничить, кому можно сказать su или sudo можно у обоих.

Да, sudo гибче, можно группе/пользователю прописать разрешения только на конкретные команды.

Нужна эта гибкость админу локалхоста? Ему виднее. Вплоть до того, что не нужна, но хочется. Кто ж запретит?

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 2)
Ответ на: комментарий от bormant

Обращаю внимание, в Slackware для административных команд часто может ожидаться именно рутовый логин-шелл:
$ su -
или
$ sudo -i
Настраивая sudo, не упускайте этот момент из виду.

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)

как теперь сделать чтобы пользователь мог вводить через sudo команды вроде installpkg

И выполнять их не вводя пароль? У меня в Debian сделано так

# /etc/sudoers
#
# Host alias specification

# User alias specification
User_Alias      STANDART_USERS = wind
# Cmnd alias specification
Cmnd_Alias      MUSTBE = /usr/bin/apt-get update, /usr/bin/apt update, /usr/bin/aptitude update, /usr/sbin/rtcwake

# Пользователи включённые в STANDART_USERS могут выполнять команды из MUSTBE не вводя пароль
STANDART_USERS  ALL = NOPASSWD: MUSTBE

Wind ★★★
()
Ответ на: комментарий от bormant

Спасибо, толково. Но я вот до сих пор не понял конкретно что дает полная отработка профиля. Всегда без нее кастал su. Полный список необходимых переменных?

Хотя... Хм. Вот недавно решали мы с человеком проблему установки драйвера принтера. Там было множество косяков с правами в системных ветках, помимо прочего. Исправляли вручную. Вот мне и кажется сейчас что наверное тот install.sh как раз и был тем самым редким случаем который требует реальной рут-среды, а не обрезков типа su или sudo. Какой-то из пакетменеджеров слаквари предупреждал что такое бывает. Приму к сведению.

Csandriel_forever
()
Ответ на: комментарий от anonymous

да и вообще нафига еще одна команда с suid-битом, если можно обойтись sudo?

И кстати su не имеет отношения к suid. На сколько я в курсе. Она делегиурет права. А команды имеющие в списке прав этот suid-бит не делегируют. Я как-то сразу не вник в суть твоего поста, на автомате справочку сбросил.

Csandriel_forever
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.