Почему я не могу проверить с помощью ping-запросов адрес на устройстве закольцовывания в соответствии с FreeBSD?
NTFS не поддерживает блокирование только определенное наследованное разрешение (который, оказывается, единственная функция, которую я хотел бы видеть от старой файловой системы Сетевого обеспечения - фильтры наследуемых полномочий). По сути, необходимо разработать иерархии разрешения с подходом, который дает наименьшее количество разрешений на высоких уровнях и добавляет разрешение на более низких уровнях.
Вы разрабатываете иерархию разрешения вверх тормашками в основном.
Я установил разрешение на доле "данных" к чему-то как:
- Администраторы - полный контроль
- СИСТЕМА - полный контроль
- Аутентифицируемые Пользователи - Содержание папки Списка - Эта папка только (набор в "Усовершенствованном" диалоговом окне)
Затем я создал бы подпапки для каждого определенного необходимого использования и дал бы разрешение к тем папкам группам, которым будет нужен доступ.
Это имеет хороший побочный эффект того, чтобы мешать пользователям заполнить корневую папку доли "данных" с их собственными файлами и каталогами. Если у Вас еще нет ""кучи" файлов" проблемой, и Вы действительно позволяете пользователям заполнять тот корневой каталог, которым Вы быстро будете в такую путаницу. (У нас есть Клиенты, которые потратили много денег, собственно говоря, очистив грязные "общедоступные диски", потому что они не запустили с хорошей подпапки / стратегия разрешения и позволили огромным суммам файлов накапливаться в течение многих лет. Это похоже на плывун - Вы застреваете в нем и, после того как у пользователей есть электронные таблицы со "ссылками" в "болото", ярлыки на файлы в "болоте", и т.д., Вы не можете выйти легко.)
Кроме того, Вы никогда не должны называть отдельных пользователей в полномочиях кроме случаев совершенно определенных для пользователя каталогов (таких как папки профиля роуминга, корневые каталоги, и т.д.). Все другие полномочия, даже если они для "просто пары людей", должны быть основаны на группах. Оборот происходит, и в будущем, когда необходимо дать заменяющему сотруднику "те же права" как человека, они заменяют, Вы будете радоваться, что использовали группы. Вместо того, чтобы иметь необходимость сохранить документацию обо всех полномочиях файловой системы Вы, возможно, установили (или, хуже, имея необходимость унизиться через него вручную), можно просто поместить нового пользователя в те же группы как заменяемый человек и быть уверены, что дали новый wuser "те же права" как замененный пользователь.
"Отклонять" разрешение в NTFS должно выделить сигналы тревоги в Вашей голове. Это редко используется в хорошо разработанных иерархиях разрешения. Обычно, если Вы ловите себя бывший должный использовать, "Отклоняют" затем, Вы, вероятно, разработали вещи назад.
Блокирования наследования разрешения нужно избежать, потому что оно ограничивает будущую гибкость разрешения. Если Вы собираетесь сделать это, у Вас должно быть серьезное основание.
Каждый раз, когда Вы повреждаете иерархию наследования, Вы ограничиваете свою способность добавить полномочия выше в иерархии, которые, очевидно, наследовались вниз.
Предположим, что "босс" приезжает к Вам и заявляет: "Я хочу, чтобы у 'Руководителей' был доступ для чтения ко всей доле 'данных'". Если Вы заблокировали наследование в 20 различных местах, каждому будет нужна добавленная запись ACL. Сравните это с добавлением единственной записи ACL наверху иерархии (предполагающий, что Вы никогда не блокировали наследование нигде в иерархии).
FreeBSD (также OS X, и я верю, NetBSD & OpenBSD) ответит на запросы, отправленные к настроенным адресам на петлевом интерфейсе, как они были бы для адресов в любом другом интерфейсе - Если Вы хотите ответ, необходимо присвоить адрес сначала:
mgraziano@monitor ~]$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
[mgraziano@monitor ~]$ ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
ping: sendto: Can't assign requested address
^C
[mgraziano@monitor ~]$ sudo ifconfig lo0 alias 127.1.1.1 netmask 0xFFFFFFFF
[mgraziano@monitor ~]$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
inet 127.1.1.1 netmask 0xffffffff
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
[mgraziano@monitor ~]$ ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
64 bytes from 127.1.1.1: icmp_seq=0 ttl=64 time=0.020 ms
^C
По логике позади этой реализации посмотрите RFC 3330:
127.0.0.0/8 - Этот блок присвоен для использования в качестве Узла Интернета
петлевой адрес. Датаграмма, отправленная протоколом более высокого уровня в
адрес где угодно в этом блоке должен циклично выполниться назад в хосте.
Это обычно реализуется с помощью только 127.0.0.1/32 для обратной петли,
но никакие адреса в этом блоке никогда не должны появляться ни в какой сети
где угодно [RFC1700, страница 5].
(шахта акцента)
Linux и Windows "полезны" здесь, однако с моего стула, отвечая на запрос, который был отправлен к адресу, не присвоенному этому хосту, не корректное поведение...
На вопрос полностью отвечают в три раза к настоящему времени, таким образом, я хотел, просто добавляют некоторые центы.
Обратите внимание, что для вполне значения по умолчанию некоторого времени ipfw конфигурация отбрасывает этот добрые пакеты:
./rc.firewall: ${fwcmd} add 100 allow ip from any to any via lo0
./rc.firewall: ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
таким образом с включенным брандмауэром вместо
ping: sendto: Can't assign requested address
Вы могли бы добраться
[savetherbtz@PH34R ~]$ ping 127.0.0.2
PING 127.0.0.2 (127.0.0.2): 56 data bytes
ping: sendto: Permission denied
PS. Из причины может быть сервер, созданный без INET (Поддержка IPv4), и Вы не будете иметь даже 127.0.0.1 =)
Его маркировка тенденции. Не имейте поля FreeBSD удобным, чтобы подтвердить ли его FreeBSD или Ваша конфигурация.
RFC говорит, что 127.0.0.1/24 - таким образом, он должен отвечать.
Я вижу то же поведение, которое Вы описываете на FreeBSD 8.1. Mac OS X, который совместно использует некоторый DNA с FreeBSD, также только кажется карте 127.0.0.1.
Windows 7 и Linux (debian с 2.6.26 ядрами) и, кажется, отображают диапазон полного адреса, как Вы описываете в кавычке Википедии (и, как предписано в RFC).
Заключить в кавычки из RFC 3330:
127.0.0.0/8 - Этот блок присвоен для использования в качестве петлевого адреса Узла Интернета. Датаграмма, отправленная протоколом более высокого уровня в адрес где угодно в этом блоке, должна циклично выполниться назад в хосте. Это обычно реализуется с помощью только 127.0.0.1/32 для обратной петли, но никакие адреса в этом блоке никогда не должны появляться ни в какой сети нигде [RFC1700, страница 5].
Зависеть, как строго Вы интерпретируете слово, "должно", некоторые могли бы сделать случай, что поведение FreeBSD/MacOS является неправильным. Но, учитывая повсеместное использование 127.0.0.1 как петлевой адрес, я сомневаюсь, что это, вероятно, будет иметь значение.