Могу ли я смело менять владельца группы /var/log/auth.log?

Я администратор Splunk, работаю с системой Ubuntu 12.04 LTS и хочу собирать события из /var/log/auth.log.

-rw-r----- 1 root adm 16534643 Jan  8 09:49 /var/log/auth.log

Splunk работает как обычный пользователь, splunk .

$ id splunk
uid=1984(splunk) gid=1984(splunk) groups=1984(splunk)

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

$ chgrp splunk /var/log/auth.log
-rw-r----- 1 root splunk 16534643 Jan  8 09:49 /var/log/auth.log

Это отлично работает на других дистрибутивах Linux, и я полагаю, что это нормально и для Ubuntu. Но я хочу спросить, не вызовет ли в будущем удар по adm у меня (на самом деле, у другой группы, владеющей коробкой) головные боли? Я не привилегированный пользователь в системе, поэтому я не могу проверить такие вещи, как / var / log / cron / adm или mail для учетной записи adm. Я также предполагаю, что logrotate удостоит моего нового владельца группы новых файлов.

(Прежде чем вы спросите, доступ к разделенному индексу для auth.log ограничен ограниченным числом людей.)

6
задан 8 January 2014 в 20:21

2 ответа

Последующее наблюдение: поскольку никто никогда не приводил причину, по которой владение группой «adm» было важно, я изменил владение группой на «spunk».

Через 6 месяцев проблем не было замечено. Я решил не давать пользователю spunk дополнительные групповые привилегии, добавив его в группу adm. Я решил, что мог бы предоставить учетной записи adm дополнительную привилегию «разрозненного» членства в группе, если это необходимо.

0
ответ дан 8 January 2014 в 20:21

adm group может быть важна, если для обеспечения дополнительной безопасности используется инструмент безопасности, такой как AppArmor (см. https://wiki.ubuntu.com/AppArmor ).

Я упоминаю об этом только потому, что столкнулся со странными проблемами (сбоями доступа) при попытке настроить связывание в Ubuntu и при использовании разных каталогов. То есть bind отказывался работать с изменениями, которые имели смысл для меня, но не были настройками AppArmor по умолчанию. Поскольку я не хотел переконфигурировать AppArmor, я вернулся к его настройкам по умолчанию - и sudo su, когда мне нужно внести изменения. Для однопользовательской системы это нормально, но я бы не хотел этого в производственной системе.

Наконец, группа adm может быть важна, если вы проверены - то есть аудитор может посчитать это нарушением целостности системы, если это не группа adm. Способ, которым вы могли бы «пройти», - это использование ACL (списков контроля доступа) - см. https://help.ubuntu.com/community/FilePermissions#ACL_.28Access_Control_List.29 для получения дополнительной информации о что.

0
ответ дан 8 January 2014 в 20:21

Другие вопросы по тегам:

Похожие вопросы: