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

Когда любой пользователь создает новые файлы или каталоги, они обычно принадлежат этому пользователю. Для обычных пользователей это не может быть изменено. Дляroot(или пользователя с доступом к возможности CAP_CHOWN)смена владельца файла возможна... но программа все равно должна явно выполнить системный вызов для смены владельца. Обычно это делают только программы, предназначенные для массового резервного копирования/восстановления файлов.

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

Если новые файлы/каталоги неожиданно создаются как принадлежащие пользователю black, это, вероятно, означает, что процесс их создания выполняется от имени этого пользователя. Возможно, какой-то процесс был непреднамеренно запущен как пользователь black, а не как пользователь company, или, возможно, у этого пользователя есть задание cron или какой-либо другой автоматизированный процесс, который создает файлы или манипулирует ими.

Это одна из ситуаций, когда использование стандартной процедуры -запуска службы может свести к минимуму количество ошибок. Если у вас есть привычка использовать что-то вроде apachectl startдля прямого запуска процесса веб-сервера, будет легко случайно запустить это как неправильный пользователь, требуя очистки -неправильных разрешений после ошибки. исправленный. Но если вы используете что-то вроде systemd .service, который явно определяет пользователя, который должен запускать серверный процесс, или сценарий запуска -, который проверяет, что служба запускается как правильный пользователь перед ее запуском, и всегда используйте стандартный инструмент для остановки и запуска службы, таких ошибок можно избежать.