Доля Samba - Мешает пользователю удалять файл

дайте попытку в shorewall... Я довольно доволен им, и я чувствую, что очень легко настроить независимо от того, что мне нужно. (Включая формирование трафика, NAT, DNAT и другие вещи).

2
15.09.2011, 17:34
5 ответов

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

Если файл находится в ext2/3/4 файловой системе на стороне сервера, то удостоверьтесь, что у пользователей самбы нет полномочий записи к ее каталогу. Это избежит случайного или интенсионального удаления. Затем включите атрибут только добавления с chattr +a <filename>, таким образом, информация может только быть добавлена и не удалять/изменять/усеченная. Файл может все еще иметь полномочия записи всем, таким образом, приложение может добавить к нему даже с полномочиями пользователей.

Примечание: chattr мог бы работать на другие файловые системы также, например, xfs. У меня нет точного списка.

5
27.01.2020, 21:55

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

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

3
27.01.2020, 21:55

Цель способности записать в файл и разрешить группу пользовательского доступа только для чтения может быть достигнута принадлежностью файла и полномочиями. Скажем, все пользователи, которым нужен такой доступ, находятся в 'пользовательской' группе, и у Вас один есть доступ к корневой учетной записи в той системе. Затем сделайте (как корень):

touch /var/log/AccessLog
chown root:users /var/log/AccessLog
chmod 640 /var/log/AccessLog

С этого времени только корень сможет изменить файл, но все пользователи смогут считать его.

Если вместо этого Вы хотите позволить пользователям писать в файл, но должны отслеживать то, кто (и когда) изменил его, Вы могли бы использовать FAM (Монитор Изменения Файла). Выше этого, для ведения учет учета всех предыдущих версий файла можно поместить Систему управления версиями (как МЕРЗАВЕЦ, например)) - можно заставить его сотрудничать с FAM так, чтобы каждая модификация файла инициировала фиксацию к локальному репозиторию. Вероятно, могут быть более легкие способы сделать это, но ничто не прибывает по моему мнению (по крайней мере ничто, что работало бы сверху файловой системы).

1
27.01.2020, 21:55

Если Ваши файлы изменили только первые минуты после создания crontab затем:

find /somedir -type f -user sambauser -mtime +3m -exec chown root:users {} \; -exec chmod 640 {} \;

Найдет все файлы со временем от последнего изменения более чем 3 минутами и изменит владельца/полномочия.

-3
27.01.2020, 21:55

Рассматривали ли вы возможность использования / проверки журнала аудита? Или использовать что-то вроде sudo (которое будет регистрировать его), чтобы запустить программу? Вы даже можете подумать о том, чтобы событие системного журнала было отправлено на другой сервер, к которому у пользователя (-ей) нет доступа.

0
27.01.2020, 21:55

Теги

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