Урезаешь ли ты $PATH для обычного юзера, $USER?

Узнать адрес компьютера, шлюз или маршруты, состояние сети - администрирование?

А без гуя никаких делений на bin и sbin уже нет?

Что вы там курите?

Вот это как раз бред. Если есть DE -> это дестоп, и пользователь сам себе администратор, скорее всего. По-настоящему многопользовательские сейчас сервера, где poweroff, может, и не нужен, а вот ip вполне.

Каждый юзер в душе своей - маленький девопс.

Что вы там курите?

Это Вы спросите у авторов текста стандарта FHS. Это по их тексту получается, что в /sbin, /usr/sbin и /usr/local/sbin должны попадать только те бинарники, работа с которыми есть администрирование.

Даже если обычный юзер только один - он не root. Почему, например, логиниться в DE надо от обычного юзера? Потому, что от root'а это делать опасно. У него столько прав, что он может поломать систему.

Поэтому выполняемые юзером задачи разделяются: основные свои задачи он выполняет от обычного юзера, а от root'а администрирует систему.

ну так не надо бездумно повторять замшелости.

эти идеи с мейнфреймов. там все было хорошо. теперь по другому.

Это текст стандарта FHS. Исходя из которого обычным юзерам из $PATH и выпиливают /sbin, /usr/sbin и /usr/local/sbin. Потому, что работа от обычного юзера отдельно, а администрирование отдельно. Так там написано.

Можно не соглашаться с этой частью FHS, можно добавлять в $PATH обычного юзера /sbin, /usr/sbin и /usr/local/sbin, но есть люди, для которых буква стандарта важнее. И они предпочтут при необходимости вбивать от обычного юзера полные пути на root'овые бинарники, зато у них, как в стандарте, будут разделены разные виды деятельности.

Например вы залогинились под user1 и вам нужно выполнить команду из под user2

О, у меня тоже так юзеры называются. Но кросс-запуск бинарников между ними что-то ни разу не требовался.

Это для кого?
/usr/sbin/ip
/usr/sbin/poweroff

user1@host3:~$ /sbin/poweroff
poweroff: must be superuser.

Второе, очевидно, для рута.

А вот первое можно было и в bin положить. А лучше - сделать отдельную чисто информационную утилиту для юзера в bin (хотя я не знаю что там кроме показывания айпи-адреса интерфейсов в ней останется, всё остальное юзера не касается).

Полностью поддерживаю заявления о том, что в sbin должно лежать то, что без рут-прав тупо не будет работать, и никакого эффекта, кроме засорения автодополнения и поиска, его наличие в $PATH таким образом не даст.

А вот первое можно было и в bin положить

В ALT Linux'е, кстати, так:

$ ls -l /usr/bin/ip
lrwxrwxrwx 1 root root 13 июн 29  2021 /usr/bin/ip -> ../../sbin/ip
$

Есть мнение, что в $PATH у юзера в любом случае не должно быть директорий /sbin, /usr/sbin и /usr/local/sbin

$ ls -ld /sbin /usr/sbin                
lrwxrwxrwx 1 root root 7 окт 19 01:01 /sbin -> usr/bin
lrwxrwxrwx 1 root root 3 окт 19 01:01 /usr/sbin -> bin

/thread

В FSH нигде не сказано, что /sbin и /usr/sbin не должно быть в $PATH, только то, что там должны быть бинарники, требующие рута для работы. А бинарники эти могут вызываться и юзером через sudo, например.

Жаль, что до удаления /bin,/sbin,/usr/sbin придется ждать еще лет двадцать.

В FSH нигде не сказано, что /sbin и /usr/sbin не должно быть в $PATH

Ordinary users should not have to place any of the sbin directories in their path.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html

Ну т.е. ip a может поломать систему, я правильно все понял?

Ну /bin чуть ли не в какие-то основополагающие ABI попал, с ним всё сложнее, а {,/usr}/sbin ага, совсем не жалко.

А у тех, у кого пока всё OK, дескать, эти ужасы просто ещё впереди.

Чет за 20 лет ужасов не наблюдаю.

Удали французскую локаль

Имея права root'а этим самым ip можно поломать настройки сети.

Там речь шла о том, что администрирование системы юзер выполняет от root'а. И стандарт FHS подчёркивает это разделением бинарников. В sbin'ы по стандарту попадают только те бинарники, которые должен выполнять только root. Если бинарник должен выполнять не только root, то он либо сам перемещается в /usr/bin, либо туда помещается симлинк на него:

$ ls -l /usr/bin/ip
lrwxrwxrwx 1 root root 13 июн 29  2021 /usr/bin/ip -> ../../sbin/ip
$

Pardon?

Имея права рута можно выстрелить себе в ногу очень много и разнообразно, но исключения чего-то из $PATH не защитит систему от всего того, что может сделать пользователь с такими правами. Не смотря на аргументы, считаю, что подобное исключение не делает систему более безопасной, но делает ее менее удобной. Сценарий, когда исключение /sbin и /usr/sbin из $PATH от чего-то спасут, считаю маловероятным.

Маэстро, урежьте $PATH!

ну как же, rm -fr /*

Ordinary users should not have to place any of the sbin directories in their path.

should not have to place

а не should not place.

Разницу понимаешь? Смысл в том, чтобы размещать свои бинарники так, чтобы юзерам не приходилось добавлять /sbin себе в $PATH. А вовсе не в том, что юзерам нельзя или не рекомендуется это делать, если хочется.

Вы не поняли. У таких людей как авторы FHS не одно является следствием другого, а наоборот.

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

А уже из факта наличия двух разных юзеров (обычный юзер и root) вытекает то, что могут быть бинарники, которые обычному юзеру для его сидения в интернете, офисе и текстовом редакторе совершенно не нужны.

По задумке авторов FHS такие бинарники перемещаются в sbin'ы. А дальше они просто «наводят красоту». Типа, если такие бинарники всё равно выполняет только root, то зачем директории с ними в $PATH у юзера? Если это лишнее, то надо это отпилить, чтобы не торчало это лишнее. Когда не торчит лишнее и бесполезное, то это красивее.

Но конкретный юзер может решить, что реальность сложнее стандарта и для удобства впилить sbin'ы в свой $PATH.

Но серьёзные дяди, которым важны стандарты, считают, что так в любом случае делать не стоит потому, что можно просто открыть два разных эмулятора терминала. В одном сидеть из под обычного юзера, а в другом из под root'а. И если у тебя и так root'овый терминал открыт, то зачем тебе более полный $PATH у обычного юзера? Но, конечно, и в этом случае юзер может решить, что расширение $PATH поможет ему меньше переключаться между окнами.

Но серьёзные дяди в этом случае говорят, что, дескать, юзер просто смешивает разные типы задач: обычные и админские. Типа, лучше их разделять и таки переключаться. Чтобы более вдумчиво вводить команды из под root'а.

Это текст стандарта FHS. Исходя из которого обычным юзерам из $PATH и выпиливают /sbin, /usr/sbin и /usr/local/sbin.

Потому, что работа от обычного юзера отдельно, а администрирование отдельно. Так там написано

Первое никак не связано со вторым. Вообще никак. FHS писали тогда, когда разделить программы администратора и пользователя было вполне возможно. Не администрирование, а сами программы, исполняемые файлы.

На текущий момент есть огромный серый слой программ, которые нужны и там и там. Есть sudo, полкит и прочее, что позволяет пользователю выборочно выполнять задачи администратора. Эти механизмы совершенно несовместимы с этой архаикой FHS. Вот поэтому эту архаику с раздельными /sbin и /usr/sbin, /bin и /usr/bin или раздельным PATH либо уже выкинули или в процессе…

На текущий момент есть огромный серый слой программ, которые нужны и там и там.

И вот на такие бинарники делают симлинки в /usr/bin.

Но потому и симлинки, что юзеров, как минимум, два (обычный юзер и root). И пока их больше одного есть и разделение задач между ними.

Обычный юзер не будет устанавливать пакеты и править конфиги в /etc, а root не будет сидеть в Одноклассниках.

И вот на такие бинарники делают симлинки в /usr/bin.

Чего FHS также не предусматривает. Да и не было такого никогда.

Раньше клали разные версии программ, например, poweroff в /sbin требовыал рута, а скрипт в /usr/bin оборачивал его вызов через su или sudo. Но и это давно прошло.

Обычный юзер не будет устанавливать пакеты и править конфиги в /etc, а root не будет сидеть в Одноклассниках.

И тот и другой живут исключительно в палате мер и весов в Париже.

Раздельные пути, это не вопрос безопасности, разделения прав или что то такое. Это вопрос исключительно удобства автодополнения. И только. Поэтому прерогатива включать в path эти каталоги или нет, принадлежит конкретному админу или пользователю. Там даже спрашивать никого не надо.

echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/var/lib/snapd/snap/bin:/home/avl/.local/bin:/home/avl/bin
[avl@hp ~]$ cat ~/.bash_profile 
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
	. ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH

нашли вообще, чего обсуждать…

Чего FHS также не предусматривает.

Я об этом и говорю. И вот тут вот юзер и выбирает соблюдать ли ему букву FHS объясняя себе это тем, что разделяет задачи, либо дополнять свой $PATH.

нашли вообще, чего обсуждать…

Дык вот, это один из тех вопросов, по поводу которых ходят разные легенды. А когда юзер приходит на форум спросить почему так, то ему кидают ссылку на статью в wiki, где просто и коротко написано

при переходе в режим суперпользователя командой su происходит просто вызов командного интерпретатора с правами root. При этом значения переменных окружения, в частности $PATH, остается таким же, как у пользователя. То есть в переменной $PATH не окажется каталогов /sbin, /usr/sbin, и без указания полного имени будут недоступны команды route, lilo, mkswap и другие. Более того, переменная $HOME будет указывать на каталог пользователя и все программы, запущенные в режиме суперпользователя, сохранят свои настройки с правами рута в каталоге пользователя, что в дальнейшем может вызвать проблемы.

Чтобы избежать этого, следует использовать su -. В этом режиме su запустит командный интерпретатор в качестве login shell (подробнее см. man bash /INVOCATION), и он будет вести себя в точности так, как если бы в систему залогинился root.

, а тема закрывается во избежание холиваров.

А комп обычный юзер выключает

В лучшем случае кнопкой на системнике.