> Более того, практически все остальные ОС общего применения обладают теми же свойствами.
> Это же относится и к WinNT, и к *BSD и к Ну вот и разобрались с модульностью.
>> Ошибки в коде одной подсистемы чреваты отказом или компрометацией всей системы.
> Ошибки в ядре и драйверах всегда чреваты неприятными последствиями. Если даже вынести
> драйвер ФС в юзерспейс, он, имеючи низкоуровневый доступ к диску, может
> внести на диск любые изменения в ФС, включая и нежелательные. Например,
Вы говорите банальности. Зачем? Чтобы абстрактно обосновать равноценность рисков в случае FUSE и ядерных драйверов?
Вы видели мою аргументы касательно принципа разделения привилегий, надёжности (возможность перезапуска, обработки ошибок FUSE-драйвера и клиентов его раздела), возможности писать FUSE-драйверы на более надёжных языках?
> изменение конфигурации ОС и сервисов оной, подпихивание в нужные моменты времени
> не тех файлов и данных что ожидалось, подделка записей в ACL,
> и так далее. По сути поломаный драйвер ФС - это открытые
> ворота в ОС, как ни крути.
Не по сути, а - в случае FUSE - в некоторых (!) ситуациях, когда драйвер отвечает за обслуживание разделов с такими файлами (настройки служб, ОС и т.п.). Устал объяснять.
Вы хотите по существу поговорить, или как соседний комментатор, беспредметно лить воду? Вопрос не риторический. Ответьте, пожалуйста.
>> Я понимаю, вам хочется поговорить на смежные темы, лишь бы не по существу.
> А вам, видимо, хочется меня потроллить? Или зачем вы так демонстративно тупите,
Мне хочется поговорить по существу, но вы усердно не замечаете моих аргументов и - куда уж там! - не стремитесь получить уточнения. Вместо этого вы считаете, будто я "туплю", троллю и не знаю элементарных вещей. Вам нравится недопонимание? Если да, то продолжайте в том же духе. Если нет, читайте внимательнее, запоминайте и задавайте уточняющие вопросы. Вопросы!
> как будто не понимаете что если я получил полный доступ к
> тому через баг в драйвере - я уже царь и бог.
Успешная эксплуатация уязвимости в ядерном драйвере - царь и бог. Эксплуатация уязвимости в FUSE-драйвере - доступ к данным, доступным FUSE-драйверу, с последствиями для клиентов его раздела, не более. Если привилегированные процессы не являются клиентами раздела (либо являются, но не доверяют его содержимому), то и компрометация драйвера не позволит вам повысить привилегии через манипуляции с файлами.
> Особенно в posix-like, где "everything is a file".
Перестаньте обобщать - дьявол в деталях. И мы придём к взаимопониманию.
>> Это нисколько не архитектура ядра. Это организация процесса разработки.
> Организация процесса разработки связана с делением по архитектурным границам.
Я думал, с модульностью мы уже разобрались. Каким границам - вот вопрос. Ни логическое разделение на файлы, модули, подсистемы, ни возможность подгрузки/выгрузки модулей в рантайме - никак не влияют на такое архитектурное свойство ядра, как монолитность в смысле общего адресного пространства и совместного доступа к данным. Монолит.
Если вы хотите довести всё до абсурда и оспаривать терминологию, я пасс. Для глумления над невежеством мне вполне хватает соседнего товарища.
>> И где же пролегают эти *архитектурные* границы в едином адресном пространстве ядра?
> По различным подсистемам являющим более-менее самостоятельные сущности.
Что значит, самостоятельные сущности? Адресное пространство одно? Одно. Доступ к данным совместный? Совместный. Вот, что существенно для определения такого свойства, как монолитность.
>> ...то ошибка в FUSE-драйвере ставит под угрозу стабильность работы этих программ, но
>> не всей системы.
> В случае проблем чтения своп-файла проблемы с стабильностью будут system-wide, например.
> Потому что внезапно, драйвер в пользовательском режиме, запросто сможет порушить не
> только данные другим процессам, но и даже всю выгруженную в своп
> память.
Господи, как я устал от этих беспомощных, вырожденных примеров. Над ними можно лишь глумиться, не более. Вы этого от меня ждёте? Да, можно извернуться и использовать FUSE так, чтобы система встала раком, но можно не изворачиваться и использовать так, что при отказе FUSE-драйвера не только система, но и клиенты его раздела смогут возобновить работу в штатном режиме после сбоя. А внутриядерные драйверы в линуксе так использовать НЕЛЬЗЯ. Вот, в чём суть. Если же вам что-то не ясно, не талдычьте мне о банальностях - задайте уточняющий ВОПРОС. Будьте человеком.
>> При этом после краха FUSE-драйвера ядро вернёт ошибки
>> в ответ на сисколы процессов-клиентов раздела, и у последних будет как
>> минимум возможность обработать эти ошибки и завершить работу.
> Ну да, щаз. Если не прочелся например своп, процесс словит page fault
А если не своп? Вас послушать, так все пользователи FUSE, на всех FUSE-разделах в системе хранят непременно свопы. Когда стоит задача повысить надёжность работы системы путём использования перезапускаемых FUSE-драйверов, КТО в здравом уме положит туда своп (который вообще не используется в большинстве таких случаев)? Не доводите до абсурда, если хотите разговора по существу.
>> Теперь, как события развиваются после сбоя ядерного драйвера.
>> В худшем случае kernel panic, мёртвое зависание с произвольно тяжёлыми последствиями (повреждение
>> данных на других разделах)
> В хучшем случае, то же самое будет и в случае FUSE драйвера
Нет, не то же самое. Ошибка в FUSE-драйвере не повлечёт за собой ни панику, ни зависание системы даже в худшем случае.
> побившего своп-файл на своей ФС, например. Более того, скомпрометированный драйвер ФС
> может внаглую инжектить в своп любые произвольные данные, произвольно перекраивая работу
Опять своп... Ладно, в рамках одного сообщения. Но если продолжите всё сводить к этому абсурдному юз-кейсу, я выйду из разговора.
> это полное поимение ОС со всеми потрохами. Аналогично, при чтении бинарей,
> скомпрометированный драйвер может например тело вируса в каждый файл подшивать, или
> что там ему угодно.
Не в каждый файл, а в каждый файл на данном разделе, у которого, в случае, когда FUSE используется для усиления защиты системы, не будет привилегированных клиентов, готовых запустить троян. Иначе теряется весь смысл разделения привилегий, понимаете?
> Знаете, если драйвер скомпрометирован и вернет вам при чтении бинаря не бинарь
> а вирусяку - хрен вы это оспорите, даже если это FUSE'вый
> драйвер сделал. Аналогично, драйвер может на лету патчить своп на своем
*facepalm*
> томе с целью получения управления в рамках всех остальных частей системы,
> может оверрайдить записи ACL на томе в пользу себя и хозяина
> малвари, etc. А кто ему запретит то? Если он разбирает эти
> структуры, он же и соврать при этом остальной части ОС запросто
> может. И это может иметь далеко идущие последствия. Более того, обычно
Запретит ему архитектор системы безопасности, который в здравом уме и твёрдой памяти не станет класть на непривилегированный раздел "привигелированные" данные.
Если провести аналогию с chroot, наш разговор мог бы выглядеть так:
- chroot позволяет изолировать процессы от доступа к файлам вне chroot-окружения.
- chroot небезопасен, потому что если посадить в него процесс с правами root, то он сможет модифицировать систему.
- Это вырожденный случай, в котором chroot как механизм строгой изоляции неприменим. Но ведь я говорю о непривилегированных процессах, чувствуете разницу?
- Нет никакой разницы, потому что root может модифицировать систему, даже не имея доступа к внешним файлам, либо выбравшись из chroot.
- Но ведь я говорю о непривилегированных процессах!
- А если положить внутрь chroot-окружения своп-файл или файлы, которые запустят пользователи вне chroot-окружения, то процесс внутри chroot-окружения сможет эти файлы модифицировать и протроянить систему!
- *facepalm*
> в CPU аппаратная изоляция кернела от юзера сделана куда более кардинально
> чем юзера от юзера.
Скорее наоборот. В линуксе 2.6 процессы ядра работают в одном адресном пространстве с пользовательскими, разница лишь в уровне привилегий страниц.
>> В лучшем случае BUG'нутая нить драйвера блокирует доступ к разделу без возможности
>> удостоверить консистентность данных и перемонтировать его повторно без перезагрузки всей
>> системы.
> Простите, а если драйвер FUSE напортачит и сольет битые данные на свой
> том - чем это неконсистентное состояние ФС будет отличаться от того
> что выше?
Тем, что если драйвер напортачил и упал, мы прогоняем по разделу fsck, исправляем ошибки, перезапускаем драйвер, и он снова в работе. А процессы-клиенты, даже если они попадали с ошибками при обращении к сбойному разделу, могут быть перезапущены без перезагрузки системы.
>> При этом процессы-клиенты раздела при любом обращении к разделу уходят
>> в контекст ядра без возможности обработать ошибки,
> То что вы описываете - баг ядра. А приколитесь, что будет если
> драйвер FUSE получит запрос "запишите мне 20 байтов в файл по
> смещению 0x100500" и ... повиснет? Как абсолютный максимум, драйвер можно пристрелить
> по таймауту. Но при этом том скорее всего будет основательно испорчен,
Вот именно, что можно "пристрелить по таймауту". И даже если (а вовсе не скорее всего) раздел будет испорчен, по нему можно прогнать fsck, в том числе в автоматическом режиме (и в ручном, но всё так же без перезагрузки системы, если ошибки серьёзные), перезапустить драйвер, службы, и система заработает в штатном режиме.
> особенно если таймаут случится в тот момент когда драйвер что-то делал
> и например оборудование решило стормозить. Ну может диск там минуту бэд
> ремапал, пытаясь его подчитать. Никто нам не гарантирует за сколько жесткий
> диск нашу команду смолотит.
А что нам мешает опрашивать драйвер на административном сокете и различать штатное ожидание с подвисанием или крахом драйвера? Даже однопоточный драйвер можно потрейсить и выяснить, в каком стостоянии он находится.
>> быть перезапущенными и даже без возможности аварийно завершить работу (SIGKILL
>> на них тоже не действует).
> Ну вообще-то взвис в драйвере - это баг. Даже не столько драйвера
> ФС, сколько драйвера работающего с железкой. Правильная реакция - задетектить что
Речь не о взвисе, а о BUG'е, когда нить драйвера дала сбой, но ядро продолжило работу.
> железо померло и вернуть ошибку. Кстати, а часто у вас драйвера
> ФС все вешали? Я вообще видел только 1 раз OOPS в
Не частно, но было дело. Приятного мало. Причём, все ошибки исключительно на ext2/3/4, поскольку другими ФС под линуксом пользоваться я не рискую - проще влить немного денег в железо и получить требуемый уровень производительности.
Последний раз ошибка была на Ext3-разделе с включёнными квотами в ядре то ли 2.6.29.х, то ли 2.6.30.х, и ошибка та была введена сразу в ДВЕ актуальные на то время стабильные ветки ядра, в рамках какого-то патча, связанного с работой Ext4.
При желании можете убедиться сами. Переберите несколько серединных стабильных версий 2.6.29.х или 2.6.30.х (в ранних .х ошибки ещё не было, в поздних .х её уже пофиксили). Создаёте раздел Ext3, включаете квоты, вызываете chmod на любой файл, и вуаля - раздел стоит колом, а все его клиенты намертво повисают в контексте ядра.
> драйвере ФС, при том это был сырейший драйвер btrfs, год назад
> примерно. В результате упал процесс который вызвал оопс. И все. Отсюда
> мораль: криворуким обезьянам нечего делать в драйверах ФС. Вообще. Они с
Вы только что наехали на разработчиков ядра, которые умудрились в две актуальные стабильные версии ядра портировать баг, созданный при работе над Ext4, который поймали пользователи стабильных (хе-хе) Ext3-разделов с квотами. ;) Помню, в IRC народ ещё долго поминал их добрым словом... ;)
> пользовательскими данными работают, поэтому сбои там попросту недопустимы. А кому нужна
> ОС, теряющая или разрушающая пользовательские данные? :)
Правильно, никому не нужна. Поэтому ни один "массовый" дистрибутив не пользуется "стабильными" версиями ванильного ядра, а стабилизирует и выпускает собственные. ;)
>> При этом нельзя освободить занятую процессами память, кроме как постепенно вытеснить
>> страницы в своп, и другие ресурсы: сетевые сокеты, shm-сегменты и т.п.
> А вы хоть раз на практике такое видели с драйверами из майнлайна,
> объявленных стабильными? Их в оопс то свалить - надо крепко постараться.
Как написал выше, видел. И не раз. Причём, в последний раз даже не пришлось интенсивно грузить систему круглые сутки (обычно при такой нагрузке баги и вылезают), а лишь включить квоты и сделать chmod. ;)
> Вот так и надо работать, потому что сбой в драйвере ФС
> в любом случае означает что пользователь потеряет свои данные. Доверять писать
Опять-таки, не каждый сбой влечёт потерю данных. Сохранность данных в ядерных драйверах, кстати, обеспечивается подсистемой журналирования, устойчивой к сбоям, и регулярными профилактическими прогонами fsck (обратите внимание - на интенсивно используемых разделах он иногда находит ошибки; чаще, кстати, это ошибки вовсе не критичные).
> это кому попало? Спасибочки. Сами пользуйтесь сбоящими драйверами. А я буду
> пользоваться теми, которые не сбоят, не крашат систему и не виснут.
> Мне мои данные нужны не в виде вермишели размазанной по диску.
;)
>> Пример из жизни хомячков-виндузятников. Заведомо ненадёжное применение интерфейса.
> Файловые системы применяются и так и сяк. Откуда вы заранее знаете как
> вообще будет применяться тот или иной драйвер? И кстати само допущение
Ещё раз, на всякий случай... Сделать бесполезными можно практически любые инструменты обеспечения надёжности и безопасности (и вообще любые инструменты), если не уметь ими пользоваться. Низкая квалификация пользователя - проблема пользователя.
> что сбой в драйвере - это что-то легитимное, допускает что потеря
> пользовательских данных за счет глюков драйвера почему-то считается штатным и допустимым
> явлением. А какого, собственно?
Да нету такого допущения. Есть уверенность, что любой, сколько-нибудь сложный код содержит ошибки и рано или поздно может дать сбой. Наличие возможности оперативного восстановления после сбоя - иногда приятный плюс, а иногда жёсткое требование. Всё зависит от сути и специфики конкретных задач.
>> Мне? Мне вообще своп не нужен, как и для решения сколько-нибудь серьёзных
>> задач. Кстати, по критерию скорости, который все вы так любите.
> Для сколь-нибудь серьезных задач, очень редко но все-таки может потребоваться объем памяти
Да, иногда действительно проще раз в 3 года добавить своп и повозиться в системе, невзирая на деградацию качества обслуживания. Но это скорее исключение, чем правило. Я не понимаю, зачем вы вообще делаете на нём акцент. Факт остаётся фактом: в большинстве случаев увеличение используемой памяти через своп кардинально и неприемлемо снижает качество обслуживания.
> превышающий физически доступный в системе. И, кстати, если уж мы о
> надежности, при нехватке памяти как минимум обломается 1 или несколько процессов,
В надёжных системах никто не доводит до нехватки памяти и необходимости включения свопа. А в ОСРВ свопа нет вообще, поскольку его наличие убило бы гарантии по времени реакции на события.
> и еще не факт что они корректно переваривают нехватку памяти. А
> может и OOM киллер пройтись по расстрельному списку. Вы уж определитесь
> - или уж надежность, или уж скорость. А то какие-то двойные
> стандарты прямо.
Одно другому не мешает. Ещё раз: во избежание нехватки памяти в надёжной системе устанавливаются избыточные объёмы памяти, а вовсе не включается своп.
>>> А административные операции - они для админов, вы прикиньте?! Позволить любому болвану
>> Вы о разделении привилегий что-нибудь слышали? А о системных псевдопользователях?
> Да, я слышал о разделении привилегий. Ну вот административные операции - они,
> внезапно, для административных пользователей. Например, рута. Или иных пользователей,
Выше я там пошутил на примере chroot, почитайте. Я вам про непривилегированных пользователей говорю, а вы мне про рута опять. *facepalm* ;)
> которым теми или иными механизмами позволят делать те или иные привилегированные
> операции. Как именно это реализуется, через системных псевдопользователей, suid'ные флаги
> или какое-нибудь sudo - да вообще вопрос десятый и относится уже
> к конкретике реализации системы деления прав в той или иной ОС.
В плане безопасности вопрос первый, а вовсе не десятый. То, что FUSE позволяет монтировать разделы непривилегированным пользователям - это плюс. Не требуется как раз всех этих setuid-root бинарников и привилегированных служб - минус один потенциальный риск повышения привилегий до root через уязвимость в таких службах и бинарниках.
> При том ядру ОС чисто технически никто и ничто не мешает
> делить права так как они захотят. Просто они работают более-менее в
> рамках выбранной абстракции, POSIX и прочая. Там - вот так. Но
И зачем вы мне это объясняете? Выводы сделайте какие-нибудь уже. Если тут есть риторический смысл, я его не понял.
> если надо чтобы вон там бесправный лузер получил вон те права
> на монтирование тома и вдруг почему-то вам не понравились уже существующие
> рычаги воздействия и механизмы - ну поменяйте сорцы и пусть вон
> тому юзеру тоже можно будет юзать этот сискол. Законом не запрещено,
А зачем мне что-то менять, без сторонней верификации этих изменений, без поддержки их в апстриме и т.п., когда в FUSE для монтирования пользовательских разделов уже всё есть? По сути вы предлагаете отказаться от стандартных удобств и изобретать велосипед.
> законы природы не нарушает. Хотя почти наверняка эквивалентное деление прав можно
> реализовать какими-то менее варварскими методами. Например, засунув юзера в контейнер
> и дав ему там права "псевдорута". Ну и будет он рулить,
Зачем городить контейнеры и давать пользователю capabilites, активирующие, помимо кода монтирования разделов, и другие привилегированные code paths? Незачем.
> но только в своем загончике, а остальным напакостить не сможет. И
> простая абстракция, и вполне эффективно.
Не вполне. Потому как attack surface более широк, а накладные расходы на реализацию более высоки.
>> Вы не представляете себе модель привилегий доступа к FUSE.
>> Позорьтесь дальше, продолжайте эту добрую традицию.
> И вас также.
Ладно, не принимайте на свой счёт. Вы вроде бы, пока, пытаетесь говорить по существу.
>> А я здесь причём? Ваши абсурдные доводы, вы и пользуйтесь - хоть
>> 95-ой, хоть 3.10-ой.
> В лично моем понимании, ядро - отличное место для энфорсинга правил контроля
> доступа. Потому что от юзеров хорошо заизолировано. Драйвер ФС имеет дело
Вообще-то по современным меркам "заизолировано" плохо, ну да ладно. Ход мысли ясен.
> с списками контроля доступа и подобными сущностями, собственно и определяющими кому
> и что льзя на вон той ФС. Стало быть - он
> вполне выглядит как часть ядра и как вполне логичный компонент в
> ядре.
Логичный, кто ж спорит. Вот только потенциальное наличие уязвимости в таком логичном драйвере обуславливает гораздо большие риски *в любом случае*. В отличие от FUSE-драйверов, изолированных в юзерспейсе, на базе которых можно строить более безопасные системы.
> Да-да, вы не троллите, а только пытаетесь, довольно уныло, имхо. Местами тупя
> не хуже собеседников. Кстати, синдром Д`Артаньяна вам засчитан.
Да засчитывайте, сколько угодно. Волновала б меня оценка со стороны, я бы и до уровня таких разговоров опускаться постыдился, в принципе.
> Наверное я. Хотя я в этом рубилове уже потерялся слегка. Насчет копеек
> - не обязательно платить за товар/услугу/что там еще чтобы обсуждать их
> преимущества и недостатки. Если кому-то не нравится обсуждение недостатков их результата
> труда, есть ровно один способ: сделать так чтобы этих недостатков не
> было.
Одно дело - оценивать, и другое - требовать соответствия своим критериям и с апломбом отвергать чужие, отличающиеся.
>> Вы отвечаете на собственные глупости. Претензий к разработчикам по этой части у
>> меня нет.
> Тогда какие к Торвальдсу претензии? С чем вы не согласны? С тем
Уже озвучивал. Здесь: https://www.opennet.ru/openforum/vsluhforumID3/78554.html#183
> что FUSE дрова тормозят и жрут процессор? Так это бенчмарками и
Это не у меня такие претензии. :)) Это у господ хомячков, которые ничего, кроме своих потребностей к скорости, во внимание не принимают (как оказалось, патологически).
> мониторами ресурсов проверяется на раз и результат получается совсем не в
> ползу FUSE почему-то.
Наверное потому, что FUSE действительно тормоз. Но моя-то позиция на том, что невзирая на просадку по скорости, FUSE применим для решения задач, в которых первостепенное значения имеют иные свойства (надёжность, безопасность, скорость и стоимость разработки, выбор инструментария).
>> Сразу видно, что микроядерными ОС вы не пользовались. "Гигантский проигрыш по скорости",
>> о котором все говорят - это 10-20%, не более, даже на
>> микроядерных ОС реального времени.
> А вы какими микроядерными ОС пользовались, и под какими нагрузками получили 10-20%
QNX пользовался, лет 9 назад. Под пиковыми нагрузками на сетевые службы, в том числе с высокими pps. Разница с вылизанным линуксом 2.4 не превышала 20%.
> и все такое? А то почему-то FUSE'вый NTFS грузит проц раз
> в пять сильнее чем ядерный EXT4. И вечно норовит упереться в
> проц, а не диск почему-то. И чего б это вдруг?
Наверное, потому, что переключений контекста в FUSE как минимум в два раза больше, чем в драйверах микроядерных ОС, а механизм IPC не отличается особой простотой и эффективностью? Вы ведь в ключе сравнения с микроядрами спросили? Не сравнивайте. FUSE абы как прибит к монолиту сбоку.
>> Размахивайте руками. Убеждайте окружающих. Это забавно.
> Вай-вай. Вы тоже с забавлением окружающих имхо справляетесь. Ну вот например очередная
> попытка потроллить, не особо удачная, имхо :P.
Самое забавное, что это искренняя констатация факта, с малой надеждой на то, что она заставит собеседника задуматься. ;) "Троллю" я весьма по-своему и исключительно для себя.
>> вот те, кто". Согласно его словам, заблуждаются ВСЕ пользователи FUSE, которые
>> считают FUSE ФС чем-то большим, чем игрушки.
> По большому счету так оно и есть. Те кому надо было драйвера
Нет никаких больших счетов. Есть. Отдельно. Взятые. Задачи. Всегда! Если стоит задача сделать сложный, надёжный, безопасный, верифицированный, покрытый тестами и относительно недорогой в разработке и сопровождении специализированный драйвер и при этом скорость работы (читай: аппаратные требования) вторична, то наиболее вероятный ответ - FUSE + <нужное вписать> (джава, ада, хаскелль и т.п.). Под ядро ничего подобного за сопоставимые деньги написать практически нельзя.
> в юзермоде, линукс вообще не должны были использовать с самого начала.
А что, есть другие ОС, с функциональностью как в линуксе, но микроядерные и всё прочее? Вообще, странно слышать такие заявления в контексте обсуждения FUSE, который в линуксе (и других юниксах) есть, поддерживается и используется. ;)
> Если кому всерьез нужна изоляция дров друг от друга и он
> даже может научно обосновать это - им таким дорожка сразу в
> микроядерные системы явно. А если кто хочет по быстрому налабать кривой
А если нет подходящей системы? Например, по критерию стоимости и гомогенности (уже есть системы и команда линуксоидов) инфраструктуры на выходе? Если дешевле написать "тормозной" FUSE-драйвер и прикупить чуть больше железа?
> драйвер, абы как, своими индусами вместо профессиональных ядерных разработчиков - так
> таким проектам вообще место на кладбище, т.к. падучие драйвера, теряющие пользовательские
> данные, налабанные лишь бы побыстрее - это крайне сомнительное "достижение".
А какое вам, вообще, дело, если они драйвер для себя пишут? И как я уже говорил, под FUSE как раз можно написать драйвер, который будет надёжнее, безопаснее, удобнее (разработка, сопровождение) и дешевле ядерного.
>> Торвальдс сказал ровно то, что сказал. Вы оспариваете факт, пытаясь дополнить его
>> несуществующими подробностями.
> Ну так и правильно сказал, по большому счету. А дополнения были лишь
Не видите ничего дурного в необоснованных обобщениях и переходе на личности в предметном разговоре? Ну так держать.
> в допущении что у собеседника есть мозги и он понимает, что
> если не было призыва вынести поддержку FUSE совсем, значит возможность "копания
Вопрос прекращения поддержки FUSE здесь ни при чём.
> бункера" никто полностью отбирать не собирается. Но повертеть пальцем у виска
> - в своем праве, ага.
Вертеть пальцем у виска в предметном разговоре - удел хамов. Имеют право, да.
