Каковы корневые полномочия для файла?

Fedora 18 не использует iptables по умолчанию (необходимо выключить firewalld, если Вы еще не имеете): http://www.chesterproductions.net.nz/blogs/it/sysadmin/changing-back-to-iptables-in-fedora-18/616/

У меня нет установки Fedora для попытки..., но на CentOS, я должен добавить правила к Цепочке, названной 'RH-Firewall-1-INPUT'. Регулярные ВХОДНЫЕ ссылки цепочки RH-Firewall-1-INPUT.

Последнее правило в Вашем RH-Firewall-1-INPUT могло бы быть:

REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

-A (добавляют) в Вашей команде, поместил бы Ваше правило SMB после всеобъемлющего ОТКЛОНЕНИЯ... Ваши пакеты SMB будут отброшены прежде, чем добраться до Вашего правила!

Это могло бы быть тем, в чем Вы нуждаетесь:

[root@localhost ~]# iptables -I RH-Firewall-1-INPUT -p tcp --dport 137 -j ACCEPT

5
27.11.2016, 01:11
5 ответов

Я бы проверил эту страницу . Там подробно рассказывается о разрешениях на файлы.

Но чтобы ответить на ваш вопрос напрямую, нет:

Суперпользователь "root" имеет возможность получить доступ к любому файлу в системе.

В вашем примере, например, если файл принадлежит, скажем, bob, а владельцем группы был также bob, то вы увидите нечто подобное:

-r--r-xrw-. 1 bob bob 8 Jan 29 18:39 test.file

Третья группа битов (rw) также применима к root, так как root является частью группы других . Если бы вы попытались редактировать этот файл как root, вы бы увидели, что у вас нет проблем с этим.

Но чтобы проверить свою теорию еще больше, если бы файл принадлежал root:

-r--r-xrw-. 1 root root 8 Jan 29 18:40 test.file

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

Наконец, если бы вы сделали крайнее:

chmod 000 test.file
ls -lh test.file
----------. 1 root root 8 Jan 29 18:41 test.file

И вы снова пошли бы редактировать файл, который вы бы увидели (по крайней мере, в vi/vim) "test.file" [только для чтения]. Но вы все равно можете отредактировать файл и принудительно сохранить его с помощью :wq! .


Тестирование @Stéphane Chazelas утверждает с помощью файла скрипта оболочки:

#!/bin/sh

echo "I'm alive! Thanks root!"


[root ~]# ls -lh test.sh
----------. 1 atgadmin atgadmin 31 Jan 30 10:59 test.sh

[root ~]# ./test.sh
-bash: ./test.sh: Permission denied

[root ~]# sh test.sh
I'm alive! Thanks root!

@Shadur уже сказал это, так что я просто процитирую вместо того, чтобы повторять:

Примечание: Бит выполнения проверяется на существование, а не на то, применим ли он к root.

8
27.01.2020, 20:31

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

chattr +i file

Это установит неизменяемый флаг на GNU/Linux. Вы можете удалить его с помощью -i вместо +i.

Во FreeBSD вы можете использовать

chflags schg file

для отмены schg вместо noschg.

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

Смотрите также: https://superuser.com/questions/104015/removing-write-permission-does-not-prevent-root-from-writing-to-the-file

7
27.01.2020, 20:31

Могут ли быть изменены права так, чтобы у корня было меньше прав, чем у владельца?

Shure, это просто, просто измените файл passwd так, чтобы uid корня не был равен нулю. С другой стороны, не делайте этого - это плохая идея.

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

Чтобы запустить часть компьютера, которая осуществляет проверку доступа, не знает вашего имени, она знает вас по номеру, и этот номер называется uid или идентификатор пользователя. аналогичным образом она не знает имен групп, в которые вы входите, только gid. сопоставление между uid и именем находится в файле passwd, а gid отображается в файле групп.

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

Иногда можно пропустить тесты с разрешениями на доступ к файлам. Почему? И (очень важно) Когда? Теперь есть некоторые вещи, которые иногда нужно сделать, но которые Вы не хотите, чтобы их делал кто-то один, и которые не очень хорошо вписываются в модель разрешения файлов. Всевозможные вещи, такие как открытие сетевого подключения на низком порту, монтирование раздела или пропустить проверки разрешений. В наши дни эти вещи известны как возможности. В старые времена UID0 имел все это, и с этим ничего нельзя было поделать, в наши дни вы можете предоставлять возможности другим пользователям или отказываться от них, но по умолчанию это старое поведение.

Другой способ ограничить root - это что-то вроде selinux, но это еще один шарик воска.

3
27.01.2020, 20:31

Предыдущие ответы предполагают, что root имеет полный доступ ко всему. Хотя это верно на большинстве вариантов Unix, это только частично верно на современном (с конца 90-х годов; ядро ​​2.2) ядра Linux. На современных Linux повышенные привилегии контролируются моделью возможностей. По умолчанию ядро ​​предоставляет все возможности в программе, если она работает как UID 0. Один из этих возможностей является DAC_OVERRIDE, который переопределяет дискреционный контроль доступа - AKA, разрешения файлов. Это актуально, потому что на 2,6,26 или более поздней системе (так, что теперь, большинство современных систем не встроенных Linux), есть флаг SecureBits, который может быть установлен, который отключает некоторые или все возможности, предоставляемые для приложений, которые Переключитесь в root или который начинается как root. Чтобы узнать, что UID 0 может сделать, вам технически нужно знать, какие возможности разрешено унаследовать процессы, работающие как UID 0.

, так, обычно Root может делать все всякий раз. Но, если вы пишете программу, которая должна делать вещи «как root» на Linux, вам действительно необходимо ознакомиться с моделью возможностей и функциями, связанными с ним. Не будь как многие поставщики, которые пишут то, что «нужно» запустить CUID Root, чтобы открыть файл или открыть сырье; Определите возможности, которые требуют вашей программы и тестируйте на эти вещи. Возможности человека .

2
27.01.2020, 20:31

, которые права для корня в этом случае? У него 777?

Да.

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

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

root может также иметь меньше прав, чем у владельца, если файл хранится в дистанционном монтируемом каталоге, как NFS.

Наконец, обратите внимание, что разрешения символических ссылок по существу бессмыслены.

1
27.01.2020, 20:31

Теги

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