Проверка sudoers [РЕШЕНО]

[ALiEN]

почему этот глюк с правами доступа происходит? Хотя система продолжает отлично работать и ошибка, по сути, видна только при проверке синтаксиса.

Файлы создаются с правами 644.
sudoers нужны 440.

Это не глюк. И даже не ошибка, а скорее предупреждение.

Создал файл, права не менял:

$: sudo visudo --check                          
[sudo] пароль для alien: 
/etc/sudoers: успешно обработан
/etc/sudoers.d/alien: некорректные права доступа, должны быть 0440

# поменял права
$: sudo chmod ug=r,o= /etc/sudoers.d/alien
$: sudo visudo --check                    
/etc/sudoers: успешно обработан
/etc/sudoers.d/alien: успешно обработан

-----

2 BendalfRU

Cкрытый текст

Для типовых ситуаций

Ну не на две команды же? Которые вспомнить быстрее, чем название скрипта.

Или вот ситуация: допустим, надо это сделать три раза для разных файлов - мне что, каждый раз лезть открывать скрипт и выставлять нужные переменные?
Скрипты нужны для автоматизации рутинных действий, а не затем, чтобы запихать туда две простейших команды, еще и обвесив абсолютно бесполезными действиями.

[vall]

Помоему все сильно отошли от темы.

ТС очень прав.

Дебаты (при желании) -- во Флудильню. Здесь только по теме. Всё что мимо, с этого момента в топку.

[rutgerg]

Это не глюк. И даже не ошибка, а скорее предупреждение.

Абсолютно не спорю. Но не может это возникать в следствии использования разных групп пользователей для выполнения sudo?
Поясню - в arch группа wheel, а, например, в deb sudo.
Или:
%wheel ALL=(ALL:ALL) ALL в отличии от %sudo ALL=(ALL:ALL) ALL.
Это к тому, что в debian такой же файл уже с правами 0440 и исправлять ничего не надо. Хотя пояснения ALIEN считаю вполне достаточным, что бы не забивать голову.
Спасибо всем кто откликнулся и считаю. что можно ставить: решено.

[ALiEN]

Но не может это возникать в следствии использования разных групп пользователей для выполнения sudo?

Нет. Это только права на файл.

debian такой же файл уже с правами 0440 и исправлять ничего не надо

Дебиан - это, так скажем, уже настроенный дистрибутив. В арче же всё делается самостоятельно.
Файла /etc/sudoers.d/05_proxy в арче нет. Либо вы его сами создали, не поправив права, либо применили какой-то скрипт, в котором автор тоже забыл поправить права на файл.

[rutgerg]

Файла /etc/sudoers.d/05_proxy в арче нет

Да, согласен. Видимо остаток от прежних действий. Ну он и не нужен теперь. Всё равно ещё раз спасибо. Проблемы как таковой нет. В /etc/sudoers.d/ создал необходимый файл с командами, сменил его права на 0440 (чтоб не думалось) и всё прекрасно работает.

[Arhei]

Файла /etc/sudoers.d/05_proxy в арче нет

да, но есть упоминание
Keep_proxy_through_sudo
хотя правда никто и не мешает использовать файл с данным названием какой-нибудь программе из того же аура

Проблемы как таковой нет. В /etc/sudoers.d/ создал необходимый файл с командами, сменил его права на 0440 (чтоб не думалось) и всё прекрасно работает.

а проблемы в действительности и так не было )

в том какие будут права 440(-r--r-----) или 644(-rw-r--r--) (что устанавливаются по умолчанию) на файл в папке /etc/sudoers.d/ 750(drwxr-x--- ) по сути не имеет значения.
во первых, производить запись в данный файл рут может в любом случае, хоть там стоит только чтение "r--" хоть чтение/запись "rw-"
во вторых, параметр чтение для всех остальных (-rw-r--r--) нивелируется правами вышестоящей директории /etc/sudoers.d/ (drwxr-x--- )

в общем, проблема высосана из пальца, и можно тупо не заморачиваться что-то меняя там в правах

[rutgerg]

проблема высосана из пальца, и можно тупо не заморачиваться

Полностью согласен. Ещё раз пардон за ложную тревогу, на кой ляд дёрнуло выполнить sudo visudo -c? Но сами поймите - Arch очень своеобразный дистрибутив и любое отклонение от "номинала" вызывает настороженность. Ну да ладно - в данном случае "ПРОЕХАЛИ".