Etc sudoers ошибка синтаксиса

20 Jun 2019Заметки

10647

~ 2 мин.

Так или иначе, когда-нибудь нам сужденно столкнуться с правкой файла /etc/sudoers …и не всегда редактирование заканчивается успешно, если ты такой же «удачливый» гоу под спойлер

Обычная ситуация, вам нужно подредактировать права суперпользователя, в файле /etc/sudoers. Но никто не застрахован от ошибок, и я снова наступил на те же грабли спустя год, вместо команды sudo visudo я отредактировал файл с помощью стандартного sudo nano /etc/sudoers и после сохранения всех правок и попытке использовать права  суперпользователя, система выдала ошибку:

>>> /etc/sudoers: syntax error near line 23 <<<

sudo: parse error in /etc/sudoers near line 23

sudo: no valid sudoers sources found, quitting

sudo: unable to initialize policy plugin

Синтаксис еррор, короче повредил синтаксис файла своими кривыми ручонками.

Есть достаточно тривиальный способ решения проблемы, использовать:

pkexec visudo

Пуфффф…И вопрос с редактированием /etc/sudoers решится сам собой. А если потребуется отредактировать файлы в директории /etc/sudoers.d/ то можно ввести:

pkexec visudo -f /etc/sudoers.d/<file_name>

ПРОФИТ!

Но в этот раз что-то пошло не так, и я получил в ответ:

==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===

Authentication is needed to run `/usr/sbin/visudo' as the super user

Authenticating as: user,,, (name) Password:  polkit-agent-helper-1:

error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie

==== AUTHENTICATION FAILED === 

Error executing command as another user: Not authorized

This incident has been reported.

Интересная ситуация, чтобы редактировать sudoers мне нужны права суперпользователя, но получить я их могу, только «починив» файл sudoers — замкнутый круг. Но есть гениальный выход из этой ситуации:

Откройте два сеанса ssh к серваку (или работа в двух терминалах или две вкладки в терминале, я использую Guake Terminal ).

В первом сеансе получите PID bash:

echo $$

Во второй сессии запустите агент аутентификации с помощью:

#PID - полученный идентификатор процесса 

pkttyagent --process PID

Вернувшись в первый сеанс, запустите:

pkexec visudo

На втором сеансе вы получите приглашение пароля:

==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===

Для запуска приложения `/usr/sbin/visudo' от имени суперпользователя требуется аутентификация

Authenticating as: user,,, (name)

Password: 

==== AUTHENTICATION COMPLETE ===

visudo запуститься в первой сессии. 

Туда-сюда, туда-сюда и проблема решена! Ну и напоследок совет, при правках используйте sudo visudo, т.к. он проверяет синтаксис перед сохранением файла, и если что-то пойдет не так, то выдаст предупреждение:

>>> /etc/sudoers: syntax error near line 30 <<<

What now?                                             #Что будем делать?

Options are:

  (e)dit sudoers file again                           #снова редактировать

  e(x)it without saving changes to sudoers file       #выйти без сохранения

  (Q)uit and save changes to sudoers file (DANGER!)   #сохранить изменения (3,14здец!)

What now? x

On a modern Ubuntu system (and many other GNU/Linux distributions), fixing a corrupted sudoers file is actually quite easy, and doesn’t require rebooting, using a live CD, or physical access to the machine.

To do this via SSH, log in to the machine and run the command pkexec visudo. If you have physical access to the machine, SSH is unnecessary; just open a Terminal window and run that pkexec command.

Assuming you (or some other user) are authorized to run programs as root with PolicyKit, you can enter your password, and then it will run visudo as root, and you can fix your /etc/sudoers.

If you need to edit one of the configuration files in /etc/sudoers.d (which is uncommon in this situation, but possible), use pkexec visudo -f /etc/sudoers.d/filename.

If you have a related situation where you have to perform additional system administration commands as root to fix the problem (also uncommon in this circumstance, but common in others), you can start an interactive root shell with pkexec bash. Generally speaking, any non-graphical command you’d run with sudo can be run with pkexec instead.

(If there is more than one user account on the system authorized to run programs as root with PolicyKit, then for any of those actions, you’ll be asked to select which one you want to use, before being asked for your password.)

If that doesn’t work—for example, if there are no users authorized to run programs as root via PolicyKit—then boot from an Ubuntu live CD (like the CD you probably used to install Ubuntu) and mount the filesystem for the installed system. You can do this by running sudo parted -l to view your partitions—there is probably just one ext4 partition, and that’s the root filesystem.

Suppose the installed Ubuntu system’s root filesystem is on /dev/sda1. Then you could mount it with sudo mount /dev/sda1 /mnt. Then you can edit the installed system’s sudoers file with sudo nano -w /mnt/etc/sudoers. Or, even better, you can edit it with

sudo visudo -f /mnt/etc/sudoers

(which will prevent you from saving a sudoers file with incorrect syntax).

При попытке настроить срабатывание одного из скриптов, который обращается к системной функции от имени обычного пользователя системы, возникла необходимость внести изменения в полномочия пользователя через файл /etc/sudoers

В найденных на эту тему материалах говорится, что редактирование данного файла необходимо производить через команду visudo. Хотелось бы, конечно, чтобы авторы таких материалов уточняли, что команду следует запускать от имени суперпользователя, так как при вводе просто visudo в терминале появляется:

~ $ visudo
visudo: /etc/sudoers: Отказано в доступе

После ввода «правильной» команды открывается окно редактора nano с загруженным в него содержанием файла sudoers.

Авторы публикаций поясняют, что при таком способе будет проверяться правильность синтаксиса вносимых в него изменений.

Вследствие отсутствия необходимости использования редактора nano мне не было известно назначение клавиш, с помощью которых производится запись в файл вносимых изменений:

И только в дальнейшем после «подсказки друга» мне стало известно, что символ ^ соответствует клавише Ctrl.

Поэтому редактирование мной файла sudoers производилось более привычным способом – sudo gedit /etc/sudoers

Увы, никто не застрахован от ошибок и после очередного эксперимента с редактированием содержания этого файла система мне выдала сообщение:

>>> /etc/sudoers: ошибка синтаксиса near line 21 <<<
sudo: parse error in /etc/sudoers near line 21
sudo: no valid sudoers sources found, quitting
sudo: не удаётся инициализировать модуль политики

Следствием этого стало невозможным использование любых начинающихся с sudo команд, а также символ ошибки в значке, отображающем доступность обновлений системы

К счастью, «лечение» сломанного механизма сводится к выполнению одной команды:

    pkexec visudo

После ввода пароля суперпользователя будет открыт тот же редактор nano с загруженным в него содержанием файла sudoers.

Соотнесите содержание своего файла с содержанием по умолчанию (без строк, начинающихся с символа комментария #):

root ALL=(ALL:ALL) ALL
%admin ALL=(ALL) ALL
%sudo ALL=(ALL:ALL) ALL

Исправьте свои «неверные» записи или приведите файл к исходного значению, после чего нажмите на комбинацию клавиш Ctrl и o. На последующий запрос нажмите y:

Далее, используя клавишу Backspace, удалите в наименовании файла .tmp и на вопрос о перезаписи существующего файла снова нажмите клавишу y:

Как видите, нет необходимости в переустановке системы. К тому же Вы будете избавлены от боязни дальнейшего редактирования файла sudoers, так как всегда сможете вернуться к корректному состоянию его содержания.

I ssh’ed into my new Linux machine (no physical access) and I have root credentials. However, I cannot run sudo commands because of some error in the sudoers file made by someone else who logged in as root as well earlier.

I used visudo to add my username to the list and the file permissions are currently:

-r--r----- 1 root root 3419 May 29 11:57 /etc/sudoers

I get the following error message :

>>> /etc/sudoers: syntax error near line 82 <<<
sudo: parse error in /etc/sudoers near line 82
sudo: no valid sudoers sources found, quitting

Please have a look and let me know what you guys think is the problem.

The contents of my sudoers file are:

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
##
## This file must be edited with the 'visudo' command.

## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhap using
## wildcards for entire domains) or IP addresses instead.
# Host_Alias     FILESERVERS = fs1, fs2
# Host_Alias     MAILSERVERS = smtp, smtp2

## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem


## Command Aliases
## These are groups of related commands...

## Networking
#Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool

## Installation and management of software
#Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
#Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig

## Updating the locate database
#Cmnd_Alias LOCATE = /usr/bin/updatedb

## Storage
#Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
#Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp

## Processes
#Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
#Cmnd_Alias DRIVERS = /sbin/modprobe

# Defaults specification

#
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty

#
# Refuse to run if unable to disable echo on the tty. This setting should also be
# changed in order to be able to use sudo without a tty. See requiretty above.
#
Defaults   !visiblepw

Defaults    env_reset
Defaults    env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR 
                        LS_COLORS MAIL PS1 PS2 QTDIR USERNAME 
                        LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION 
                        LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC 
                        LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS 
                        _XKB_CHARSET XAUTHORITY"

## Next comes the main part: which users can run what software on
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##      user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL
admin   ALL-(ALL)       ALL
shami   ALL=(ALL)       ALL
## Allows members of the 'sys' group to run networking, software,
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

## Allows members of the users group to mount and unmount the
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

I manually edited the sudoers file on my Amazon Elastic Compute Cloud (Amazon EC2 instance). Now I’m receiving a syntax error similar to the following when trying to run sudo su commands or commands that require privileged user access:

«/etc/sudoers: syntax error near line xx»
«sudo: parse error in /etc/sudoers near line xx»
«sudo: no valid sudoers sources found, quitting»
«sudo: unable to initialize policy plugin»

Short description

This syntax error occurs when the /etc/sudoers file is manually edited to change the sudo user and unwanted characters are added to the file. The result can be an impaired instance that can’t run sudo su or commands that require privileged user access. To fix this syntax error, stop the instance, detach its root volume, attach it to a recovery instance, mount the root volume as a secondary volume, and then revert the changes to the sudoers file.

Warning: Before starting this procedure, be aware of the following:

• Stopping and restarting the instance erases any data on instance store volumes. Be sure that you back up any data on the instance store volume that you want to keep. For more information, see Determine the root vevice type of your instance.
• Stopping and restarting the instance changes the public IP address of your instance. It’s a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.

Resolution

Note: Don’t manually edit the sudoers file using a text editor such as vi, vim, or nano on a running instance that you can connect to. Always run visudo to edit the /etc/sudoers file on instances that you can connect to. Visudo checks for parse errors as you edit so that any issues introduced into the file are brought to your attention before you save the changes.

1.    Open the Amazon EC2 console.

2.    Choose Instances from the navigation pane, and then select the impaired instance.

3.    Choose Actions, choose Instance State, and then choose Stop.

4.    In the Description tab, select the Root device, and then select the EBS ID.

5.    Choose Actions, choose Detach Volume (/dev/sda1 or /dev/xvda), and then choose Yes, Detach.

6.    Verify that the State is Available.

7.    Launch a new EC2 instance in same Availability Zone as the original instance. The new instance becomes your rescue instance.

8.    After the rescue instance launches, choose Volumes from the navigation pane, and then select the detached root volume of the original instance.

9.    Choose Actions, and then choose Attach Volume.

10.    Select the rescue instance ID (1-xxxx) and then enter a device name (/dev/sdf, for example).

11.    Use SSH to connect into the rescue instance using your key pair.

12.    Run the lsblk command to verify the device name of the attached volume.

lsblk
The following is an example of the output.
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0    8G  0 disk
└─xvda1 202:1    0    8G  0 part /
xvdf    202:80   0  500G  0 disk
└─xvdf1 202:81   0  500G  0 part
13.    Create a mount directory and then mount with root privileges:
Amazon Linux, Ubuntu, and Debian:
sudo mount /dev/xvdf1 /mnt
Amazon Linux 2, CentOS 7 or 8, SUSE Linux 12, and RHEL 7.x or 8.x:
sudo mount -o nouuid /dev/xvdf1 /mnt
Check the mount point in the console for the newly attached volume. Usually that mount point is /dev/xvdf1.
14.    Chroot into the mounted directory.



  


                       
  




for dir in {/dev,/dev/pts,/sys,/proc}; do sudo mount -o bind $dir /mnt$dir; done
chroot /mnt
15.    Edit the sudoers file using visudo command.
visudo
There are two options for editing the file:
Option 1: Revert the changes you made that created the syntax error.
Option 2: Replace the /mnt/etc/sudoers file with a known correct file from the recovery instance by copying the file from the recovery instance.
Create a backup of the original file.
sudo mv /mnt/etc/sudoers /mnt/etc/sudoers.backup
Copy the file to the instance.
sudo cp /etc/sudoers /mnt/etc/sudoers
16.    After you edit or replace the sudoers file, unmount the volume.
for dir in {/dev,/dev/pts,/sys,/proc}; do umount /mnt$dir; done
sudo umount /mnt
17.    Attach the volume to the original instance. Specify the mount point as /dev/xvda or /dev/sda1, as this is the root volume for the original instance.
18.    Start the original instance.
19.    Connect to the instance using SSH and try running sudo commands.



  


                       
  





Related information
Why am I unable to run sudo commands on my EC2 Linux instance?