Действительно ли Linux может зарегистрировать полномочия дурачиться?
Можно создать вперед зоны поиска на внутреннем сервере DNS, которые имеют FQDN сервера, Вы хотите разместить информацию для, затем создать запись, которой Вы не даете имя и даете ему Ваш внутренний IP.
Для Вашего примера: создайте новое вперед зона поиска под названием billy.acme.com, создайте записи с пустым полем имени и вставьте 192.168.2.100 для IP.
Можно теперь проверить с помощью ping-запросов billy.acme.com и получить внутренний адрес, потому что сервер является авторитетным для того домена, но он проведет bob.acme.com, потому что он не размещает ту зону.
$ ls -lhd fooledYa/
d-wx------ #snip
Первое, что нужно сделать: я могу писать в каталог (создавать новые записи) и могу выполнять ( cd ) в каталог. Однако я не могу читать каталог. Что это означает, не интуитивно понятно.
Когда вы работаете с каталогами в системах Unix, каталог указывает на inodes , которые отличаются от записи указателя. Возможность отслеживать ссылки вниз по дереву каталогов контролируется битом eXecute . Для каждого уровня каталогов вниз по дереву операционная система проверяет бит выполнения перед переходом на следующий уровень.
Между тем, бит Чтение управляет доступом к содержимому inode. Все, что вы можете ссылаться на свою файловую систему, - это запись inode. Каталоги или файлы, они указывают на индексный дескриптор.
ls -ldi fooledYa/
121100226 d-wx------ #snip
В этом случае индексный дескриптор каталога - 121100226. Разрешение на чтение указывает, могу ли я получить доступ к этому файлу индексного дескриптора в пользовательском пространстве для чтения его содержимого. Содержимое inode каталога - это ссылки на другие файлы. Ядро всегда может это прочитать. Вы, как пользователь, управляете решениями ядра относительно записей в нем.
Таким образом, поскольку ls пытается прочитать содержимое, чтобы сказать мне, что там (что проверено Read ] flag), это отклонено. Однако поскольку у меня все еще есть разрешение eXecute , ядро позволит мне переходить к файлам, которые я указываю, если все каталоги над файлом, который я хочу, разрешают мне eXecute в них, независимо от того, могу ли я прочитать их, чтобы увидеть, на что идет ссылка.
Итак, чтобы подвести итог для каталогов, подумайте о выполнении как о главном разрешении. Без него вы не сможете войти в каталог, чтобы что-либо делать. После этого считайте их файлом из двух столбцов. Если у вас есть разрешение на чтение, вы можете видеть записи. Если у вас есть разрешение на запись, вы можете добавлять или удалять записи. Если у вас нет этих двух разрешений, но у вас есть выполнение, вы можете делать ссылки на записи в списке, но не можете читать список.
Это хороший иллюстративный пример индексных дескрипторов и того, как они представляют ссылки на каталоги и блок файлов на дисковых ссылках. : http: //teaching.idallen. com / dat2330 / 04f / notes / links_and_inodes.html
I believe the specific thing that is fooling you is that every directory below / has at least two links to it: the directory's entry in its parent and . within itself (plus any .. links from child directories). When you type ls -ld . it's looking at the . link in the current directory (which you have permission to read), not the link to the current directory from the parent directory (which you don't have permission to read).
For +x, I've found the easiest way to understand how it works on directories is permission to "get into" the directory. You can't get into a directory without +x at all, even if you have read and write access to it. If you aren't allowed into a directory, you can't get into the subdirectories whether they have +x set or not. So, if you have fooledYa/ohReally/foo.txt and fooledYa is is chmod 0000, assuming no other ACL system overrides the file mode, only root would be able to get into ohReally/ or open foo.txt even if they know the path to the file without having to list the directory contents.
One of the odd things about these permissions is that if the directory is +r but not +x, you have permissionto read the directory contents so you can "peek in" from outside and read the list of files in the directory, but without +x you won't be able to get into the directory to access (stat) the individual files. Therefore if you try to ls -l such a directory you'll get filenames but all the other fields for filesizes, modes, ownership, etc will be ? marks.
As you anticipated, plenty of people have explained how your example is perfectly logical. "Works as designed."
To answer your question, it would be an egregious kernel bug if you were able to fool the OS into letting you view files/inode info which you are not supposed to. The file permissions are associated with the inode itself and are applied when you actually try to open the file. In case you didn't pick it up from the other answers, I'll point out that a directory has an inode like any file does, it's just that the permissions mean something slightly (or greatly) different when applied to directories.
File permissions are the original Unix security mechanism and are still an integral part of Unix/Linux security. Any scenario you can cook up that looks like you have fooled the system is almost certainly a case of you not understanding what the correct behavior is. If you found a legitimate way to bypass security, even in hacks, it would be considered a critical security bug and would be among the highest priorities to patch.
For example, if you were able to read the contents of a file you were not supposed to be able to read, you could steal the (hashed) passwords of all the users and the private ssh key for the system and the private ssh keys of everyone on the system (though hopefully those would be encrypted) and via a device inode read the entire contents of system memory (and much more). It would be less dangerous if you could read file info you were not supposed to, but it would still be considered a major breach.