3

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

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

Более того, если я использую команду mv чтобы переместить файл из того места, где я его храню, в место, где он хочет быть, это приведет к ошибкам. Если я использую cp чтобы скопировать файл в нужное место, ошибок нет.

Очевидно, что такие вещи, как diff , file или ls -l , не показывают различий между этими двумя файлами, поскольку один является копией другого, поскольку cp создает точную копию файла.

Я не могу поделиться слишком большой информацией о файле, потому что это работа. Суть в том, что команды cp fileA fileB и mv fileA fileB создают "другой" файлB. Мое лучшее предположение - некоторый супер низкоуровневый атрибут из fileB, оставленный позади во время cp (даже cp -p производит то же самое поведение).

Что mv делает иначе, чем cp, в отношении точного содержимого полученного файла?

РЕДАКТИРОВАТЬ: С помощью ls -l:

-rw-r--r--. 1 root root 3389 Aug  8 22:53 fileA
-rw-r--r--. 1 root root 3389 Aug  8 23:03 fileB

РЕДАКТИРОВАТЬ: приложение MySQL и файл представляет собой файл .cnf, и элемент в этом файле конфигурации, который представляет особый интерес, является именем двоичного журнала, используемого при репликации базы данных master-slave. "Ошибка" в том, что "вы не используете двоичное ведение журнала", потому что двоичного журнала нет, поскольку этот элемент никогда не "читался" mysql.

Сначала я подумал, что в файле конфигурации произошла синтаксическая ошибка, из-за которой все это не читалось, и это привело меня к его воссозданию вручную путем копирования блоков текста.

РЕДАКТИРОВАТЬ: Получение где-то ... Наконец, что-то другое в файлах.

ls -lZ

-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 server.cnf.bad
-rw-r--r--. root root unconfined_u:object_r:mysqld_etc_t:s0 server.cnf.good

3 ответа3

3

Это то, что может происходить (вы даете очень мало информации о приложении или об этих ошибках, поэтому я могу только догадываться).

В Linux обязательная блокировка файлов встречается редко. Вызовы типа flock(2) управляют консультативными блокировками. Это означает, что ядро отслеживает блокировки, но не применяет их, приложения должны подчиняться им.

Если что-то блокирует fileA и ваше приложение подчиняется блокировке, оно может отказать в обслуживании. Давайте предположим, что это то, что происходит.

Блокировка влияет на индекс, а не на путь или имя. Перемещение (переименование) заблокированного fileA в fileB пределах одной файловой системы ничего не делает для inode, файл все еще заблокирован, приложение по-прежнему отказывается работать с ним. При копировании файла создается отдельный fileB со своим собственным индексом, который не заблокирован, приложение работает.

(Примечание: перемещение файла в другую файловую систему на самом деле копирование + удаление, поэтому он должен снять блокировку, если таковая имеется).

3

TL; DR: в системе, где используется SELinux , файлы, используемые системой (например, демоны), следует копировать или перемещать с помощью cp -aZ и mv -Z вместо cp -a и mv . Если это не было сделано, нужно просто использовать restorecon -v -r или restorecon -v -F -r в месте назначения, чтобы попросить систему восстановить контексты SELinux по умолчанию. Всегда полезно использовать restorecon в конце скрипта, который работал с ключевыми файлами конфигурации.

RHEL и, следовательно, большинство его производных по умолчанию используют SELinux.

Итак, чтобы решить вашу проблему, если ваша система основана на RHEL и использует пакет mariadb-server , просто сделайте на последнем шаге, когда файл находится в правильном месте:

# restorecon -v -F /etc/my.cnf.d/server.cnf
Relabeled /etc/my.cnf.d/server.cnf from unconfined_u:object_r:user_home_t:s0 to system_u:object_r:mysqld_etc_t:s0

(Обратите внимание , что без -F это не изменит unconfined_u к настроенному system_u Это не имеет значения для обычных систем. Мое знание разницы и почему это не имеет значения, не заходит так далеко).

Было бы просто больше работы, чтобы поместить правильный контекст в файл в другом месте. chcon может сделать это (либо указав его с помощью -u -t и т. д., проще, скопировав контекст из другого файла с помощью --reference):

# ls -lZ /home/test/server.cnf.bad
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 744 Apr 30  2017 /home/test/server.cnf.bad
# chcon -v -u system_u -t mysqld_etc_t /home/test/server.cnf.bad 
changing security context of '/home/test/server.cnf.bad'
# ls -lZ /home/test/server.cnf.bad
-rw-r--r--. 1 root root system_u:object_r:mysqld_etc_t:s0 744 Apr 30  2017 /home/test/server.cnf.bad

Если вы подозреваете проблемы с SELinux, проверьте /var/log/audit/audit.log наличие записей со словом « denied относящихся к вашему процессу или файлу. Вы всегда можете временно попросить SELinux разрешить операции, а затем восстановить их с помощью соответственно setenforce Permissive и setenforce Enforcing для сравнения поведения. Не оставляйте его в Permissive особенно для производства.

Различные объяснения следующие ...

Пример и что нужно сделать при работе с файлами конфигурации

Пример bahaviour с различными параметрами cp и mv в системе с поддержкой SELinux:

$ id
uid=1034(test) gid=1034(test) groups=1034(test)
$ pwd
/home/test
test@glasswalker:~$ ls -lZ foo
-rw-r--r--. 1 test test unconfined_u:object_r:user_home_t:s0 0 Aug 11 11:25 foo
$ cp foo /tmp/foo1
$ cp --preserve=context foo /tmp/foo2
$ cp -a foo /tmp/foo3
$ cp -aZ foo /tmp/foo4
$ mv foo /tmp/foo5
$ ls -lZ /tmp/foo?
-rw-r--r--. 1 test test unconfined_u:object_r:user_tmpfs_t:s0 0 Aug 11 11:25 /tmp/foo1
-rw-r--r--. 1 test test unconfined_u:object_r:user_home_t:s0  0 Aug 11 11:25 /tmp/foo2
-rw-r--r--. 1 test test unconfined_u:object_r:user_home_t:s0  0 Aug 11 11:25 /tmp/foo3
-rw-r--r--. 1 test test unconfined_u:object_r:user_tmpfs_t:s0 0 Aug 11 11:25 /tmp/foo4
-rw-r--r--. 1 test test unconfined_u:object_r:user_home_t:s0  0 Aug 11 11:25 /tmp/foo5
$ touch bar
$ ls -lZ bar
-rw-r--r--. 1 test test unconfined_u:object_r:user_home_t:s0 0 Aug 11 11:49 bar
$ mv -Z bar /tmp
$ ls -lZ /tmp/bar
-rw-r--r--. 1 test test unconfined_u:object_r:user_tmpfs_t:s0 0 Aug 11 11:49 /tmp/bar

Поэтому использование cp -aZ или mv -Z прекрасно работает, когда контексты безопасности имеют значение и сохраняют другие атрибуты. Скрипт, перемещающий системные файлы, всегда должен использовать опцию -Z для любой команды cp или mv , или просто использовать restorecon на последнем этапе, чтобы избежать непредвиденных проблем.

Почему эти различия?

Команда mv поддерживает согласованное поведение. Если бы это произошло в той же файловой системе, то, конечно, все, что связано с файлом, включая контекст безопасности, не было бы изменено, так как это просто "переименование". Таким образом, в двух файловых системах, где на самом деле это копия, а затем ее удаление, она также копирует без изменений все, что прикреплено к файлу, и знает о ней, включая контекст безопасности, для согласованности.

Команда cp по умолчанию просто создает новый файл, так что этот файл наследует родительский контекст selinux как обычно, если, конечно, не указано иное с --preserve=context который включен в -a . --preserve=context может быть извлечен из -a с опцией -Z поэтому лучше всего копировать целую древовидность - использовать -aZ вместо -a если SELinux имеет значение.

По умолчанию при создании файла, что является обычным случаем, этот новый файл наследует контекст своего каталога SELinux, поэтому все работает нормально (не по теме: в редких случаях контекст файла должен отличаться от контекста своего каталога только из-за Если править его именем, ядру все равно, для его обработки потребуются такие программы, как restorecond восстановления демона).

Что такое SELinux

SELinux - это обязательный механизм контроля доступа (MAC), используемый в дополнение ко всем другим механизмам (разрешения Unix, такие как DAC, списки контроля доступа, ACL и т.д.). Когда процесс выполняется в контексте безопасности процесса, существует "матрица правил", позволяющая проверить, может ли этот контекст процесса выполнить запрошенную операцию (открыть, прочитать, записать, mmap, ...) в контексте файла, с которым он пытается работать.

Пример для случая OP: Если контексту процесса mysqld разрешен доступ только к нескольким типам контекста файла, включая mysqld_etc_t но не user_home_t то запуск mysqld завершится неудачно, поскольку он не может прочитать свой файл конфигурации с неправильным типом user_home_t .

На обычных системах это не имеет значения для интерактивного / вошедшего в систему пользователя, поскольку его обычный контекст процесса не ограничен, то есть правило SELinux не будет применяться. Каждый демон, запущенный systemd или другими подобными механизмами , получит контекст процесса, который можно проверить с помощью опции ps -s -Z . Пример в системе Debian под управлением SELinux:

# ps -Z -p $$
LABEL                             PID TTY          TIME CMD
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 22498 pts/7 00:00:00 bash
# ps -Z -p $(pidof /sbin/getty)
LABEL                             PID TTY      STAT   TIME COMMAND
system_u:system_r:getty_t:s0     6158 tty1     Ss+    0:00 /sbin/getty 38400 tty1
system_u:system_r:getty_t:s0     6159 tty2     Ss+    0:00 /sbin/getty 38400 tty2
system_u:system_r:getty_t:s0     6160 tty3     Ss+    0:00 /sbin/getty 38400 tty3
system_u:system_r:getty_t:s0     6161 tty4     Ss+    0:00 /sbin/getty 38400 tty4
system_u:system_r:getty_t:s0     6162 tty5     Ss+    0:00 /sbin/getty 38400 tty5
system_u:system_r:getty_t:s0     6163 tty6     Ss+    0:00 /sbin/getty 38400 tty6
3

Да, есть принципиальная разница:

  • cp делает копию файла
  • mv (если вы остаетесь в файловой системе) просто перемещает некоторые указатели на диске.

Попробуйте следующее:

touch a
ls -i a
cp a b
ls -i a b
mv a c
ls -i b c

Вы увидите, что b - это новый файл с новым номером инода, где c - это тот же файл с номером инода старого a.

Тем не менее, это не объясняет вашего странного поведения.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .