Да это ни от кого не скрывалось, процесс планирования был довольно публичным. Первые наброски делались вообще на собрании в переговорной с выводом на проектор, потом по мере развития проекта актуальные версии рассылались. Просто директор изначально хотел опенспейс — дескать, от сидения рядом проистекает синергия и повышаются открытость и вовлечённость. А я, как единственный айтишник, сказал, что у меня с менеджерами по продажам, логистиками и маркетологами синергии быть не может, что мы друг другу будем только мешать, и что в районе моего рабочего места всегда царит некоторый беспорядок из разобранных ноутбуков и клубков кабелей, которыми лучше не смущать пришедших на переговоры клиентов.
Но теперь, конечно, некоторые косятся с завистью.
Статья, конечно, старая, но только сейчас увидел. Пару лет назад наша контора переезжала в новый офис в довольно сжатом режиме, и как-то внезапно получилось так, что его план рисовал я, в Visio. В результате отдельные кабинеты с непрозрачными стенами есть у бухгалтерии и у меня. У генерального и технического директоров — отдельные кабинеты, но со стенами из прозрачных стеклянных перегородок. Остальные сидят в опенспейсе.
Код был на LotusScript, там нет фигурных скобочек :-) Массивы заполнялись вручную, по шагам — т.е. функция начиналась с двухсот строк вида «Массив[Индекс] = Значение», после чего начинался поиск в заполненных массивах.
Это да, самый душераздирающий кусок кода, который я когда-либо видел, был обнаружен в, к счастью, уже почившем, клиентском софте одного из крупнейших и наиболее известных в России банков. Там была функция, возвращавшая значение цвета (как число, RGB) по его строчному названию. Значения и названия цветов хранились в двух одномерных массивах одинаковой длины. И ладно, что значение цвета зачем-то хранилось в виде строки — шестнадцатеричной записи числа, которая перед возвращением конвертировалась в число (с ошибкой). Ладно, что поиск в массиве названий производился линейным способом (а известных цветов было не то 100, не то 200). Но всё это меркло перед тем фактом, что массивы были локальными переменными функции — т.е. чтобы найти один цвет, она КАЖДЫЙ РАЗ вначале заполняла два эти массива, далее устраивала в них поиск и возвращала результат.
Разные — да, даже не оспаривал. Атомарные — нет. Атомарность прав доступа в математическом смысле означает «необходимость и достаточность».
Ну я вот как-то затруднюсь назвать авторитетный источник, в котором даётся строгое математическое определение понятия «атомарности» применительно к правам доступа. Я этот термин использовал в смысле «нельзя разложить на более мелкие права».
Т.е. атомарные права самодостаточны, т.е. не требуют наличия некоторой комбинации других прав для однозначного понимания, исполнимо ли соответствующее право, а также не зависят от соседних прав.
Самодостаточность — дело такое… Все права требуют для своей работы выполнения каких-то внешних условий. «Атомарное» право запуска в Линуксе требует, чтобы в опциях монтирования не стояло noexec. А возможность записи требует, чтобы том не был read-only. Так что они тоже не вполне «самодостаточные», и возвращаясь к NTFS можно сказать, что «в NTFS при наличии права чтения файла пользователю так же можно дать право запуска».
С тем, что «Чтение» или «Запись» атомарны я готов согласиться
И напрасно, потому что ни то, ни другое в NTFS не атомарно, какое определение ни возьми :-) Чтений есть аж четыре — чтение данных, атрибутов, расширенных атрибутов и разрешений. А запись различается на запись данных, дозапись данных, запись атрибутов, расширенных атрибутов, запись разрешений (DACL и SACL) и установку владельца.
Кстати, могу привести интересную иллюстрацию сложностей с правами в Windows — правда, не в NTFS, а в Active Directory. В Windows Server 2008 была такая проблема с шаблонами сертификатов. Если у тебя есть право на изменение разрешений шаблона, но нет права на установку владельца, то ты не можешь и разрешения поменять: консоль выдаёт ошибку, что у тебя нет права на изменение владельца, хотя ты его не менял. Это был косяк самой консоли: при попытке изменения разрешений она пыталась записать не только изменённый DACL, а весь Security Descriptor объекта, включающий DACL, SACL и Owner, что AD воспринимала как попытку установки владельца и отказывала в выполнении. Для решения проблемы я писал отдельный скрипт, который устанавливал DACL — кажется, через WMI.
В NTFS есть отдельные права на чтение, и отдельные права на чтение-и-запуск. Атомарное право на запуск в NTFS не существует.
Ну как это не существует? Именно атомарное и именно существует. Название в GUI — «Traverse folder/Execute file». Бит 5 в поле AccessMask структуры ACE, если не вру. Другое дело, что наличия одного этого права недостаточно для того, чтобы иметь возможность запускать файл, надо ещё иметь как минимум атомарные права «Read data» и «Read extended attributes». Но это всё — разные атомарные права.
И что «Read&Exec» — это пара прав, а не одно право — это я тоже знаю.
Не пара, а целых пять :-)
Но вот с «атомарностью» буду спорить. В паре Read&Exec exec без read не работает — странная какая-то атомарность.
У Майкрософт такой подход встречается и в других местах. Например, у шаблонов сертификатов есть атомарное право «Enroll», которое необходимо, чтобы иметь возможность отправить запрос на выпуск сертификата на основании данного шаблона. Но в одиночку это право не работает, надо иметь ещё и право на чтение шаблона.
В принципе в этом можно углядеть свою логику. Если у вас есть ключ от квартиры, а в подъезде дверь запирается, то чтобы попасть в квартиру, вам всё равно ещё нужен ключ от подъезда.
Мюнхен, кстати, единственный город, где я в аэропорту видел живую мышь. Поднимаюсь на эскалаторе, а она передо мной стоит столбиком. Я на неё осуждающе посмотрел, и она куда-то убежала.
Делал два раза. Первый раз для подготовки применял «Фортранс», а второй раз отечественный «Лавакол». Не сочтите за рекламу, но «Фортранс» омерзительно-сладковатый (чёртова привычка западной фармакологии делать сладкие лекарства), «Лавакол» слегка солоноватый, мне его пить было гораздо легче. Плюс «Лавакол» ещё и дешевле.
В первый раз с трудом, но прошёл процедуру до конца, второй раз не смог из-за боли, ввести зонд получилось сантиметров на тридцать. Если бы знал, что так будет, проходил бы со сном. Процедура была нужна для подготовки к небольшой операции, тридцати сантиметров оказалось достаточно, поэтому переделывать не пришлось.
Почему бы не просто
?
Но теперь, конечно, некоторые косятся с завистью.
Может, на носу? Корма — это не для короля, а для боцмана.
Ну я вот как-то затруднюсь назвать авторитетный источник, в котором даётся строгое математическое определение понятия «атомарности» применительно к правам доступа. Я этот термин использовал в смысле «нельзя разложить на более мелкие права».
Самодостаточность — дело такое… Все права требуют для своей работы выполнения каких-то внешних условий. «Атомарное» право запуска в Линуксе требует, чтобы в опциях монтирования не стояло noexec. А возможность записи требует, чтобы том не был read-only. Так что они тоже не вполне «самодостаточные», и возвращаясь к NTFS можно сказать, что «в NTFS при наличии права чтения файла пользователю так же можно дать право запуска».
И напрасно, потому что ни то, ни другое в NTFS не атомарно, какое определение ни возьми :-) Чтений есть аж четыре — чтение данных, атрибутов, расширенных атрибутов и разрешений. А запись различается на запись данных, дозапись данных, запись атрибутов, расширенных атрибутов, запись разрешений (DACL и SACL) и установку владельца.
Кстати, могу привести интересную иллюстрацию сложностей с правами в Windows — правда, не в NTFS, а в Active Directory. В Windows Server 2008 была такая проблема с шаблонами сертификатов. Если у тебя есть право на изменение разрешений шаблона, но нет права на установку владельца, то ты не можешь и разрешения поменять: консоль выдаёт ошибку, что у тебя нет права на изменение владельца, хотя ты его не менял. Это был косяк самой консоли: при попытке изменения разрешений она пыталась записать не только изменённый DACL, а весь Security Descriptor объекта, включающий DACL, SACL и Owner, что AD воспринимала как попытку установки владельца и отказывала в выполнении. Для решения проблемы я писал отдельный скрипт, который устанавливал DACL — кажется, через WMI.
Ну как это не существует? Именно атомарное и именно существует. Название в GUI — «Traverse folder/Execute file». Бит 5 в поле AccessMask структуры ACE, если не вру. Другое дело, что наличия одного этого права недостаточно для того, чтобы иметь возможность запускать файл, надо ещё иметь как минимум атомарные права «Read data» и «Read extended attributes». Но это всё — разные атомарные права.
Не пара, а целых пять :-)
У Майкрософт такой подход встречается и в других местах. Например, у шаблонов сертификатов есть атомарное право «Enroll», которое необходимо, чтобы иметь возможность отправить запрос на выпуск сертификата на основании данного шаблона. Но в одиночку это право не работает, надо иметь ещё и право на чтение шаблона.
В принципе в этом можно углядеть свою логику. Если у вас есть ключ от квартиры, а в подъезде дверь запирается, то чтобы попасть в квартиру, вам всё равно ещё нужен ключ от подъезда.
С остальным в целом согласен.
В первый раз с трудом, но прошёл процедуру до конца, второй раз не смог из-за боли, ввести зонд получилось сантиметров на тридцать. Если бы знал, что так будет, проходил бы со сном. Процедура была нужна для подготовки к небольшой операции, тридцати сантиметров оказалось достаточно, поэтому переделывать не пришлось.