10x. Помогло.

> Есть вкладочка Аdvanced

Почему-то считается, что в ней тоже зло:) Пользователь ведь глупый и тупой, но любопытный - он ведь сразу туда полезет:)

> может ну их нах?

Опа! А вот это низзя. Потому что тупых - БОЛЬШИНСТВО (мне иногда кажется - подавляющее:). А значит, сбрасывая их - сбрасываем концепцию массового десктопа. Сбрасываем бабульки, которых недополучат Sun/RH/Novell. Для них-то массовость=бабульки. Элитарный десктоп "для умных" построить, как ни смешно, проще - если сам умный. А вот Вы попробуйте, будучи умным, построить десктоп, которым бы хотел и мог пользоваться тупой - вот это challenge:)

> те оставшиеся 20%, они что, в централизованном управлении не нуждаются

Нуждаются. А кто сказал, что ими нельзя управлять? Даже спрятанные настройки - они же все равно в GConf. А значит, потенциально, их можно запихать в LDAP сервер - и рулить...

> > даже винда не такого плохого мнения о своих пользователях ;)

> Поэтому гномовцы считают ее негодной с точки зрения юзабилити. Бывает забавно смотреть, как некоторые на нее сверху поплевывают и попинывают:)

они, наверное, уже захватили мир и 99.9% десктопов. ну тогда конечно, где уж нам с ними спорить :)

>> Есть вкладочка Аdvanced
> Почему-то считается, что в ней тоже зло:) Пользователь ведь глупый и тупой, но любопытный - он ведь сразу туда полезет:)

Чего-то я не понимаю логику. Что мешает любопытному пользователю запустить тот же gconf-editor (или как там его...) и напортачить там, а не во вкладке Advance? Причем напортачит он там конкретно, не сомневайтесь. Откуда узнает про gconf-editor? Да сам же админ ему покажет. Это будет любимая программа всех пользователей. Глупых и не очень. Вас это не сильно беспокоит?

Не за что. Мы этих x.org душили-душили, душили-душили, душили-душили:)

>GPL здесь совершенно ни при чем, т.к. речь идет о разработке коммерческого софта не под GPL. В этом случае, тролли могут извращаться с лицензиями как хотят - и, в частности, у них есть право требовать лицензию еще на этапе разработки. Обращаю внимание - GPL-права никто не отменяет, просто _сверх_ них тебе ничего не полагается, пока лицензию не купишь =)

Еще раз. Я разрабатываю коммерческий софт под GPL. И использую GPL-Qt. Но! Я его не продаю (потому как это мое личное дело). А вот когда я закончу свой продукт, то сменю лицензию на коммерческую (это тоже мое личное дело), куплю Qt, и на законных основаниях буду его продавать.

Трюк уже давно известный и используемый.

тонкие настройки пугают неготовых к ним пользователей

>Потому, что тонкие настройки пугают неготовых к ним пользователей. >Ставить пользователя перед выбором, который он не то что сделать - >осознать не способен - это означает создать у него чувство дискомфорта. >Для врачей - "не навреди". Для программистов control center - "не >пугай".
А я и есть пользователь гнома, и дискомфорт у меня вызывыет просмотр длинного дерева gconf.
Хранить настройки в одном месте-это правильно,
отсутсвие в наутилусе локального GUI для настройки опций -
это натуральный фашизм.
А запрещать пользователю приспосабливать программную среду
под свои вкусы-это кощунство.
Я это конечно не в серьез.;-)

> Что такое "XML к месту" - вопрос спорный. По мне так, если конфигурация - дерево, то формат файлов, который изначально основан на "дереве" - совершенно уместен. Скажите честно, тот кусок XML, который я привел - совершенно для Вас нечитаем, действительно?

Скажем так, второй пример более читаем. Поэтому XML тут за уши притянут.
Или для вас нечитаемы
/etc/aliases
/etc/crontab
/etc/fstab
/etc/passwd
/etc/services
/etc/squid.conf
?
Спрашивается, зачем им XML?
Обычные текстовые файлы уже не имеют право на существование, потому что команда Гном узнала про XML?

>Вы слегка передергиваете "с его Mono". GNOME _никаких_ официальных отношений с Mono до сего дня не имеет. Mono и его производные не входят в состав ни библиотек, ни десктопа (только в language bindings - среди других языков есть #).

Да, я передергиваю. Смотрите, в каком контексте я это говорил.

Re:

> Можно попросить привести пример захламления конфига ненужными данными - захламления, обусловленного строгой типизацией?

<?xml version="1.0"?> <gconf><entry name="show_toolbars" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="show_statusbar" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="open_in_tab" mtime="1050834005" muser="alex" type="bool" value="true"/><entry name="popups_in_tab" mtime="1050834006" muser="alex" type="bool" value="true"/><entry name="show_bookmarks_bar" mtime="1055320290 " muser="alex" type="bool" value="false"/></gconf>

(Копи-паст из ~/.gconf/apps/epiphany/interface/%gconf.xml)

Ну и зачем, в общем случае мне видеть, что show_statusbar - это boolean, не говоря уже о том, что его редактировал alex? Кто его еще мог там редактировать? :-)

> А как насчет того, что не допустить ошибку лучше, чем ее устранить?

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

> Ну, если действительно использовать препроцессор - да, конечно. Только зачем? Представьте, если бы sendmail умел сам кушать sendmail.m4 и выполнять препроцессинг в память и на лету.

Угу. И до ошибок тогда было бы не добраться вовсе :-)

Re:

Примечание: в оригинале текст %conf.xml выглядел так:

<?xml version="1.0"?>
<gconf><entry name="show_toolbars" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="show_statusbar" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="open_in_tab" mtime="1050834005" muser="alex" type="bool" value="true"/><entry name="popups_in_tab" mtime="1050834006" muser="alex" type="bool" value="true"/><entry name="show_bookmarks_bar" mtime="1055320290 " muser="alex" type="bool" value="false"/></gconf>

(форматирование сохранено)

> Скажем так, второй пример более читаем. Поэтому XML тут за уши притянут. Или для вас нечитаемы

Для меня ВСЕ читаемо - и эти файлы, и XML от gconf. Это Вы жаловались на нечитаемость gconf. И Вы все-таки мне скажите - а где в формате KDE хранится timestamp?

> Обычные текстовые файлы уже не имеют право на существование,

Разумеется, имеют. Только определите, пожалуйста, что такое "обычный текстовый файл". И /etc/passwd, и КДЕ .ini формат - тоже имеют структуру. И XML имеет структуру. Все они text-based - и лично для меня они все читаемы. С точки зрения программиста - вообще не важен формат, важен API. Чем же Вам тогда XML не угодил?

> Да, я передергиваю. Смотрите, в каком контексте я это говорил.

Контекст не оправдывает передергивания:)

>Это Вы жаловались на нечитаемость gconf.

Нет, не я. У меня его и на машине-то нет)

>И Вы все-таки мне скажите - а где в формате KDE хранится timestamp?
Вы имеете ввиду конф.файл? Нет там этого. Потому как эта информация есть в файловой системе.

> Разумеется, имеют. Только определите, пожалуйста, что такое "обычный текстовый файл". И /etc/passwd, и КДЕ .ini формат - тоже имеют структуру. И XML имеет структуру. Все они text-based - и лично для меня они все читаемы. С точки зрения программиста - вообще не важен формат, важен API. Чем же Вам тогда XML не угодил?

Я вот думаю... Может, вообще файлы не нужны? И каталоги. Весь диск - один большой XML-файл ;)
И доступ унифицирован к любой информации... Все гладко и красиво. Один такой большой реестр)

<?xml version="1.0"?>
<gconf><entry name="show_toolbars" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="show_statusbar" mtime="1055320290" muser="alex" type="bool" value="true"/><entry name="open_in_tab" mtime="1050834005" muser="alex" type="bool" value="true"/><entry name="popups_in_tab" mtime="1050834006" muser="alex" type="bool" value="true"/><entry name="show_bookmarks_bar" mtime="1055320290 " muser="alex" type="bool" value="false"/></gconf>


А че не сдулать два чек-бокса, и мозги себе не парить??

Строгая типизация.... Ну, вы, клоуны, чес слово. А что, если я там поковыряю этот икс-эм-эль до неузнаваемости? Что будет? Правильно, гном грохнется, как полугодовалый малыш, которого забыли подпереть подушками.

А почему? А просто в коде влом было ставить проверку.
Вывод один - простой текстовый файл а-ля /etc/passwd + хороший ГУЙ + четкая проверка в проге. Если что не так - в дефолт.

З.Ы.: Что творится с гномом после мало-мальского апдейта, это ужас. Лучшее средство - это или никогда не трогать ничего, ни апдейтить, ни стирать. А если уж че обновил, плиз нафиг ~/.gnome и все похожее в /дев/нулл

А говорят винда корявая...

Очень странно. Почему же мой gconf выдает нормальную индентацию?...

> show_statusbar - это boolean, не говоря уже о том, что его редактировал alex? Кто его еще мог там редактировать? :-)

Аллах его знает - возможно, техноложество и overengineering :)(возможно, bool нужен для производительности - чтобы в файл со схемой лазать пореже?). Но это же не данные - это мета-данные. Я думал, Вы говорите о ключах, которые плодятся в силу того, что данные типизованы. Вообще, поднимался вопрос о смене формата XML (в смысле - на другой XML). Не знаю, чем дело кончилось.

> Знаете, как плевалась моя жена, когда я отвлекал её во время набора теми очепятками, которые она сделала.

Очевидно, не знаю:) Это просто у Вас пользовательский интерфейс неправильный. Если бы Вы каким-то способом _не_допустили_ появления опечаток - вот тогда можно было бы сравнивать. Типа, вводит жена "не ту букву" - а Вы ей "биип" - и буковка даже не появляется на экране.:) Вот это и называется предупреждение ошибок.

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

В принципе - да. Только при чем тут fvwmrc, я не понял?

> Потому как эта информация есть в файловой системе.

Для каждого entry?:)

> Может, вообще файлы не нужны? И каталоги. Весь диск - один большой XML-файл ;)

Нет. Разумеется, файлы не нужны. И каталоги, кстати, тоже. Нужно универсальное хранилище именованных объектов. Которое, по потребностям, может корчить из себя реляционную и/или иерархическую структуру (типа OS/400 - которая просто СУБД - но только погибче, чтобы деревянность поддерживало). Как оно устроено внизу (XML или что другое) - не очень важно. Только к классическому униху это все не имеет отношения. Что-то типа WinFS или того гномьего Storage:) И ReiserFS пытается туда же двигаться.

> Все гладко и красиво. Один такой большой реестр)

Для больших объемов данных плохо подходит. А вот для средних объемов - как в хранилище конфигурации - самое то. Если только отдельно продумать вопрос надежности (почему GConf не обошелся одним файлом, а паразитирует на каталогах, одна из причин - надежность: что будет, если этот один большой файл гикнется...)

Очень странно. Почему же мой gconf выдает нормальную индентацию?...
---
у него наверное в виме нет строчки:
set autoindent

:-)

> А че не сдулать два чек-бокса, и мозги себе не парить??

Это Вы к чему? Какие чек-боксы? У Вас gconf - АЛЬТЕРНАТИВА GUI? GUI куда складывает результат этих чекбоксов? И кто Вас заставляет ручками этот файл читать-писать (я туда очень редко смотрю - почти никогда)? Вам gconf-editor мало? Вам gconftool мало?

> А что, если я там поковыряю этот икс-эм-эль до неузнаваемости? Что будет? Правильно, гном грохнется, как полугодовалый малыш, которого забыли подпереть подушками.

Пробовали? Я - если честно - нет. Если грохнется - плохо, должен быть устойчивым. Но это совсем другая проблема. Испоганить можно любой файл с конфигурацией, было бы желание - хорошо бы, чтобы при этом система не падала, но это, повторяю, о другом. И все-таки прошу мне объяснить, зачем Вы будете руками туда лезть при наличии gconftool. Еще посмотреть - я могу понять, сам так иногда делаю для скорости, но модифицировать...

> Вывод один - простой текстовый файл а-ля /etc/passwd + хороший ГУЙ + четкая проверка в проге. Если что не так - в дефолт.

Категорически не согласен. Что такое "а-ля /etc/passwd"? Если набор записей, разделенных '\n' и полей, разделенных ":" - то КДЕ сразу не подходит. Более того, такой формат - это "реляционная БД для нищих" - а зачем это в конфигурации, где нужно не реляционность, а иерархичность? "Хороший ГУЙ" - это святой Грааль, недостижимая вещь. И даже если мы просто будем это тут обсуждать - на это уйдет вся оставшаяся жизнь, моя и Ваша (надеюсь, мы не будем этого делать:). Вот проверка в проге и хороший дефолт - это, пожалуй, да.

> Что творится с гномом после мало-мальского апдейта, это ужас

Странно. А я вот живу с 2.2 - и ничего. Единственная прога, чуткая к апдейтам - Ева. Но тут я просто сношу старое и ставлю новое (благо у меня почта в IMAP, а адресная книга в LDAP).

Re:

> Это просто у Вас пользовательский интерфейс неправильный. Если бы Вы каким-то способом _не_допустили_ появления опечаток - вот тогда можно было бы сравнивать. Типа, вводит жена "не ту букву" - а Вы ей "биип" - и буковка даже не появляется на экране.:) Вот это и называется предупреждение ошибок.

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

Re:

> Пробовали? Я - если честно - нет. Если грохнется - плохо, должен быть устойчивым. Но это совсем другая проблема. Испоганить можно любой файл с конфигурацией, было бы желание - хорошо бы, чтобы при этом система не падала, но это, повторяю, о другом. И все-таки прошу мне объяснить, зачем Вы будете руками туда лезть при наличии gconftool. Еще посмотреть - я могу понять, сам так иногда делаю для скорости, но модифицировать...

Грохнется-грохнется. У меня на XFS (давно уже) при нештатных перезагрузках из-за Нвидии и ее драйверов иногда портились файлы (полностью или частично нулями забивалось). Грохалось за милую душу.

Re:

> В принципе - да. Только при чем тут fvwmrc, я не понял?

Хех, это элементарно, ватсон! .fvwmrc _предполагается_ к редактированию руками. И для него доступны все средства удобного редактирования. А для %gconf.xml - только, по большому счету, gconftool. Неплохо, конечно, но нужно понимать, какая часть удобств теряется, и чего достигаем взамен утраченной функциональности.

> Попробуйте предложить этот способ людям, умеющим быстро набивать (проф. машинисткам или просто людям с соответствующими навыками). Результат превзойдет ожидания :-).

Это невозможно в данный момент. Мой умозрительный эксперимент требует умения читать мысли - чтобы узнать, какое слово человек собирается набрать. Так что Вы меня еще услышите:) Кстати, привычка OpenOffice.org пытаться "угадывать" слова меня сначала немного раздражала - а теперь мне этого не хватает в других редакторах.

А вот это просто бага. Так быть не должно при любой системе конфигурирования. Надо было жаловаться.

Мой вопрос "при чем тут fvwmrc" относился к поствалидации. Вы его как валидируете? В состав fvwm входит утилита командной строки, проверающая, не напортачили ли Вы в файле, не запихали ли True туда, где нужен цвет?

> А для %gconf.xml - только, по большому счету, gconftool. Неплохо, конечно, но нужно понимать, какая часть удобств теряется, и чего достигаем взамен утраченной функциональности.

Есть еще gconf-editor - но это неважно. Чего достигаем? Дуракозащищенности. Разумеется, упорный дурак полезет и искорежит XML (и тогда гном не должен падать, но это о другом). Но простой дурак-твикер не сможет запихать неправильный тип туда, куда не следует... А какая часть удобств теряется? Командную строку тяжело набрать? Тогда пользуйте gconf-editor, интуитивно-понятная тулза (только бы к ней search скорее приделали).

> Вы пытаетесь все защитить на нижнем уровне, на файлах-протоколах-сокетах. Это неудобно.

1) Это _единственный_ способ что-то защитить.

2) Это удобно -- потому как есть наследование, role & type transition tables, etc.

> Почему Вы не хотите, чтобы админ работал в терминах тех объектов, которые его интересуют?

Я-то хочу, только это означает, что ОС должна поддерживать защиту этих объектов, а это трудно сделать...

> Почему для запрещения смены скринсейвера админ должен чего-то там ковырять в настройках запускаемых программ

Нет, просто написать policy.

> кстати, а почему из запрещения смены скринсейвера должен _обязательно_ следовать запрет на запуск шелл-скриптов?

Дык он и не следует.

> > А че не сдулать два чек-бокса, и мозги себе не парить??

> Это Вы к чему? Какие чек-боксы? У Вас gconf - АЛЬТЕРНАТИВА GUI? GUI куда складывает результат этих чекбоксов? И кто Вас заставляет ручками этот файл читать-писать (я туда очень редко смотрю - почти никогда)? Вам gconf-editor мало? Вам gconftool мало?

Мне не мало, мне его даром не надо. Я хочу прогу конфигурить из-под проги. А то доходит до маразма, что я свою любимую игрушку "махджон" не мог запустить из-за апдейта - крешало, так мне посоветовало оно полезть в гконф и че-то там поправить.

Кстати, еще один плюс конф. (и др.) файлам в текстовом формате (с ключами я имею ввиду). Это удобство обработки:
cat bla-bl-bla.xml | grep "Value="
Для обработки XML UNIX-утилиты не годятся. Это очень большой минус, который ограничивает использование XML в UNIX.

>Нужно универсальное хранилище именованных объектов. Которое, по потребностям, может корчить из себя реляционную и/или иерархическую структуру (типа OS/400 - которая просто СУБД - но только погибче, чтобы деревянность поддерживало). Как оно устроено внизу (XML или что другое) - не очень важно. Только к классическому униху это все не имеет отношения.

Вот тут я согласен. Только мечты все это. Ибо придется переделать весь софт. Типа GNU2 :)

>Для каждого entry?:)

А зачем? Опять-таки, вы решаете проблему локально. Ограничились GConf. Берите шире. Все это проблемы ФС, а не гнома или кде. Разве что гордиться тем, что гном делает работу ФС...

> Для больших объемов данных плохо подходит. А вот для средних объемов - как в хранилище конфигурации - самое то. Если только отдельно продумать вопрос надежности (почему GConf не обошелся одним файлом, а паразитирует на каталогах, одна из причин - надежность: что будет, если этот один большой файл гикнется...)

Нет файлов. Ноды в ФС указывают на ветки этой-самой XML-структуры. Хотя тогда половина ФС будет занята таблицей...

> Это _единственный_ способ что-то защитить.

Неочевидное утверждение. Высокоуровневые способы защиты могут (может, даже должны) использовать низкоуровневые - но почему Вы просто хотите всю защиту перетащить на низкий уровень?

> Я-то хочу, только это означает, что ОС должна поддерживать защиту этих объектов, а это трудно сделать...

Почему? А если, допустим, ОС предоставит только механизмы защиты - а вышележащие пользовательские проги будут их комбинировать и расширять? Вообще, в микроядерных ОС практически вся защита находится на пользовательском уровне - это делает ее менее надежной?

> Нет, просто написать policy.

В каких терминах? "screensaver.change=no" иди "noexec $HOME/bin"? Мне не нравится второй вариант.

> Дык он и не следует.

Вы же предложили запретить запуск из ~/bin? Или это были не Вы?

Ну, это просто бага. Она должна быть пофикшена - и все. Баги есть везде (сходить, что ли, посмотреть, сколько их открыто про gswitchit?:)

Пожалуй, я на днях специально поставлю, посмотрю этот 2.6. В jail-е, чтобы потом не вычищать полдня несколько дюжин пакетов. Svu тут так гладко стелет, а я вспоминаю 2.4 - это же был просто ужас. И почему-то я почти уверен, что с тех пор ничего там не изменилось.

> Для обработки XML UNIX-утилиты не годятся. Это очень большой минус, который ограничивает использование XML в UNIX.

xsltproc - утилита командной строки. Универсальный обработчик XML с неограниченной мощностью. Для всех, как говорится, веков и народов. В _некоторых_ случах и grep сойдет. Опять же, perl почти всегда под рукой - а там есть парсер...

> Типа GNU2 :)

Не, это будет GANU - GANU is Absolutely Not Unix:)

> Разве что гордиться тем, что гном делает работу ФС...

Угу. А чем мы тут с Вами полдня занимаемся? Обсуждаем, то ли дерево доверить ФС, то ли не доверить. В идеальном мире это должно быть прозрачно. Есть дерево - и все. Узлы адресуемы по именам, по путям. Но то в идеальном...

> Нет файлов. Ноды в ФС указывают на ветки этой-самой XML-структуры. Хотя тогда половина ФС будет занята таблицей...

Угу. В том-то и проблема. Сложно сделать так, чтобы эффективно работало на больших объемах.

Умоляю - не надо. Вы же потом за мной с топором бегать будете, если что не понравится. Пожалуйста, не ставьте, пожалейте меня:)

> Ваши действия, чтобы запустить ~/bin/startMyHackerXprog.sh?

(Навскидку) В Mozille назначить этот самый startMyHackerXprog.sh MIME helper'-ом.

Так что это "защита" от [sensored].

> Формально, с т.зр. униха, у Вас остается право запустить что угодно (с соотв. битиками прав).

И всегда найдется путь это запустить...

> Реально - Вы не можете реализовать это право.

Фундаментально неверный путь. Все, что не разрешено, должно быть запрещено. ОСью, а не WM'-ом.

## /etc/selinux/assert.te

neverallow user_t ~{ office_progs_t shell_exec_t}:file_class_set execute

neverallow user_t dir_file_class_set { setattr relabelfrom relabelto };

neverallow user_t ~user_home_t:dir_file_class_set { write append create unlink }

И пусть тогда они хоть на уши становятся -- ничто (кроме бага ядра) не поможет запустить какую-то дрянь...

Мозиллу тоже перекроем - точнее, заменим епифанью, а ей (возможно, не проверял) эти штуки (пользовательские установки MIME) через gconf перекрыть можно. В этом же треде не только я об этом говорил - кто-то другой был готов поспорить на большие деньги, что закроет запуск чего попало из иксов (кстати, в моем изначальном варианте было условие про итеративность, оставляю за собой право на сколько угодно попыток).

Продолжаю верить в то, что это возможно.

> Все, что не разрешено, должно быть запрещено. ОСью, а не WM'-ом.

Извините, зачем Вы путаете desktop environment и wm? Это же совсем разные вещи. И можно запрещать действия в environment на уровне этого environment (разумеется, при этом нельзя запретить средствами GNOME/GConf делать что-то в twm - если админ такой глупый, что разрешил пользователю туда добраться и не отрубил там всего и вся).

> Вообще, в микроядерных ОС практически вся защита находится на пользовательском уровне - это делает ее менее надежной?

AFAIK, не совсем так. Там просто разделены механизм и политика. Ядро "знает" про security server и "спрашивает" у него, разрешать или нет то или иное действие (фактически -- IPC). Поскольку обращение к любому серверу ( в т.ч. и к exec-серверу ) -- это IPC, то никуда Вы от ядра не денетесь...

> В каких терминах? "screensaver.change=no" иди "noexec $HOME/bin"?

neverallow screensaver_t ~good_images_t:file_class_set read_file_perms;

neverallow user_t screensaver_exec_t:file_class_set { relabelto write append create unlink setattr };

neverallow screensaver_t ~screensaver_exec_t:file entrypoint;

domain_auto_trans(user_t, screensaver_exec_t, screensaver_t);

dnl все, что было до этого момента, уже есть в SELinux. dnl дальше -- вымысел, чтоб это было реальностью, нужно хакать XFRee86

neverallow ~screensaver_t root_window_t:window { changepixmap }

> Мозиллу тоже перекроем -

У Вас фактически _весь_ установленный софт является TCB. Этого НЕ ДОЛЖНО БЫТЬ! К TCB должны относится ядро, login, sshd, etc., но никак не mozilla и еще-какая-то-там-фигня-нужная-данной-конторе.

> И можно запрещать действия в environment на уровне этого environment

Нет, должен быть один (и только один!) security framework, остальное -- от лукавого.

> Поскольку обращение к любому серверу ( в т.ч. и к exec-серверу ) -- это IPC, то никуда Вы от ядра не денетесь...

Ну, это не разговор. Я тоже могу сказать, что обращение к gconfd - это тоже через ядро, поэтому... (в чем, кстати, для Вас принципиальная разница между gconfd - в том, что касается защиты некоторых ветвей конфигурации - и security server?) В конечном итоге, реальное определение того, кому что можно делается не в ядре, а на пользовательском уровне.

Полиси выглядит действительно круто. Я не смотрел SELinux - можете рассказать, в чем смысл этих иероглифов?

Кстати, судя по dnl там тоже m4. Зачем?...

> Продолжаю верить в то, что это возможно.

Только потенциально. С ростом количества приложений, которые нужно _разрешить_ запускать пользователю, и/или их сложности количество точек, куда надо пойти и поправить (причём править согласованно!) растет, очень сильно (~по экспоненте?). И после определённого предела получается, что админ умрёт раньше, чем закончит сей неблагодарный IMHO труд.

Причём #1: предыдущий абзац неявно предполагает, что каждое приложение поддаётся конфигурации в достаточной степени, чтобы решить задачу, что, естесственно, не так.

Причём #2: предыдущий абзац неявно предполагает, что админ обладает бесконечно большими и к томуже правильными сведениями обо всех документированных и не-документированных функциях, равно как и обо всех ошибках всех приложений, стоящих в системе и самой системы. Что, естесственно, не так.

> Ну, это не разговор. Я тоже могу сказать, что обращение к gconfd - это тоже через ядро, поэтому...

Нет, ядро не спрашивает у gconf'-а, можно ли потоку XXX позволить записать что-то в адресное пространство процесса YYY.

> В конечном итоге, реальное определение того, кому что можно делается не в ядре, а на пользовательском уровне.

Определение, но не enforcement. В случае с gconf оный вообще отсутствует...

> Полиси выглядит действительно круто.

Это только набросок, еще нужно разрешить загружать библиотеки, читать конфиги, etc.

> Я не смотрел SELinux - можете рассказать, в чем смысл этих иероглифов?

neverallow screensaver_t ~good_images_t:file_class_set read_file_perms;

Не разрешаем домену screensaver_t читать файлы, тип которых не совпадает с good_images_t neverallow user_t screensaver_exec_t:file_class_set { relabelto write append create unlink setattr };

Не разрешаем домену user_t писать, создавать, удалять файлы типа screensaver_exec_t. Также не разрешаем домену user_t назначать файлам (любого типа) тип screensaver_exec_t

neverallow screensaver_t ~screensaver_exec_t:file entrypoint;

Перейти в домен screensaver_t разрешено только путем запуска файла типа screensaver_exec_t.

domain_auto_trans(user_t, screensaver_exec_t, screensaver_t);

Когда домен user_T исполняет (exec, execve, execl, etc.) файл типа screensaver_exec_t, процессу автоматически назначается домен screensaver_t ( _очень_ отдаленная аналогия: suid бит )

neverallow ~screensaver_t root_window_t:window { changepixmap }

А это -- вымсел; но идея та же -- все объекты window system ( window, pixmap, font, clipboard ) принадлежат к определенному типу, и каждый домен имеет имеет определенные права по отношению к каждому типу. Запрещаем делать XSetWindowBackgroundPixmap, XFreePixmap, etc. для окон типа root_window всем доменам, кроме screensaver_t

А может сделать полу-форк и создать проект, занимающийся вытаскиванием спрятанных настроек на поверхность и вообще продвинутыми возможностями, которые всякие Хавоки прячут? Даже MS делала MS PowerTools и MSPlus.

>Это все меня, как пользователя ровным счетом волнует не больше, чем >когда марс войдет в созведие козерога. Я сравниваю то, что было в >мурзилка 1.4 и в 1.7 бета какая то. Разницы - не вижу. Беру первый >какой то фаерберд и теперешнюю огненную лису, опять - разницы ноль. >Повторяю - оцениваю с точки зрения пользователя.

Так же можно сказать, что сравнивая вин 95 и вин ХР разницы никакой. Те же окна, те-же функции. А вот если немного полазить по интернету с помощью огнептица, то сразу станет ясно в чём разница.

> Еще раз. Я разрабатываю коммерческий софт под GPL. И использую GPL-Qt. Но! Я его не продаю (потому как это мое личное дело).

Да, это сколько угодно =)

> А вот когда я закончу свой продукт, то сменю лицензию на коммерческую (это тоже мое личное дело)

Это уже не твое личное дело. Так как твоя прога имеет зависимость от GPL'ной Qt, то ты не можешь выпустить ее не под GPL. Тролли продадут лицензию - но она будет применима только к тем программам, которые разработаны в период ее действия (и они имеют на это право). То есть на твою GPL'ную софтину она не распространяется.

Хотя понятно, конечно, что спор чисто теоретический. Ибо что-то доказать тролли никогда не смогут ("а мы прогу за день написали, как лицензию получили, вот!"), так что кому не нужен их саппорт - могут пользоваться таким методом и спать спокойно =)

> С ростом количества приложений, которые нужно _разрешить_ запускать пользователю, и/или их сложности количество точек, куда надо пойти и поправить (причём править согласованно!) растет, очень сильно (~по экспоненте?).

Не совсем так. Оно все-таки растет линейно. И, самое главное, теоретически есть способ с этим бороться - иерархия, дерево пермишенов. Тогда это все вполне обозримо и управляемо.

> каждое приложение поддаётся конфигурации в достаточной степени

За это надо бороться. Нужна полиси (типа HIG - только про блокировку). Если приложение поставляется с гномом - оно должно быть гарантированно управляемым

> админ обладает бесконечно большими и к томуже правильными сведениями

Иерархия пермишенов лечит и это. Админ может отключать базовые пермишены - а может заниматься файн-тюнингом по настроению.

Правда, это все уже отдельная история - сегодня в gconf я ничего такого не вижу. До этого у них еще руки не дошли - и дойдут ли... Кстати, управление правами в жабке - очень миленькое.

> Даже MS делала MS PowerTools и MSPlus.

Не надо ничего форкать. Есть какой-то проектик про приделке гуев к спрятанным ключам. Я даже скриншотики видел - симпатично и внятно. Зачем форкать?

> Нет, ядро не спрашивает у gconf'-а, можно ли потоку XXX позволить записать что-то в адресное пространство процесса YYY.

А микроядро - знает что-то про "можно позволить"? Мне казалось, ему по барабану. Оно просто передает какую-то мессагу - а смысл ее для ядра темен. Так чем же оно отличается от линуха, который передает пакетики для gconfd?

> Определение, но не enforcement.

Это как это? Допустим, в случае с микроядром у меня есть сервис файловой системы. И он обслуживает некий диск. На нем файл с правами 555. Кто не даст записать этот файл - ОС или сервис файловой системы?

> Это только набросок, еще нужно разрешить загружать библиотеки, читать конфиги, etc.

??? Это мрачно. А как-то крупноблочно это можно оформить? И - главное - Вы сместили акцент на конкретные функции X для конкретного окна. А кто сказал, что я не захочу в root запустить какой-нибудь xsnow - он же не скринсейвер?

&gt > Это существенный архитектурный недостаток, если это правда. Вы совершенно не думаете о таких вещах, как централизованное > администрирование, lockdown и пр. И если KDE действительно не обеспечивает этих вещей - мне его жаль, ему в корпорациях > будут не очень рады. В гноме редактирование gconf тоже делается достаточно легко и без напряга (в control center, во > всяком случае).

В KDE для этого дела есть специальная технология Kiosk, которая активно спонсируется немецким правительством.

Re:

> Кстати, привычка OpenOffice.org пытаться "угадывать" слова меня сначала немного раздражала - а теперь мне этого не хватает в других редакторах.

Это не совсем то же самое. Точнее, совсем не то же самое. OpenOffice.org предлагает дополнение визуально, поэтому при слепом наборе (т.е. не смотрим на клавиатуру, а в экран) этот способ приемлем, наверное. И этот способ - не intrusive, а suggestive, то есть, если продолжать набирать слово "руками" никакого перерыва в работе не будет. А предложенный Вами способ - это все равно что трогаться с взведенным ручником: неправильная буква - бдымьс, встали разбираемся, что там не так, еще одна неправильная буква - опять остановились.

Re:

> "при чем тут fvwmrc" относился к поствалидации. В состав fvwm входит утилита командной строки, проверающая, не напортачили ли Вы в файле, не запихали ли True туда, где нужен цвет?

Не знаю. Я fvwm'ом не пользуюсь, наверное, года с 97, а его производными (AfterStep'ом) - с 98-99го. Я видел только что RH прикручивал к этому делу макроязык с крупноблочным конфигурированием, а там уже и до валидатора недалеко.

> А какая часть удобств теряется? Командную строку тяжело набрать? Тогда пользуйте gconf-editor, интуитивно-понятная тулза (только бы к ней search скорее приделали).

Причем здесь командная строка? Автодополнение для ключей в gconftool как раз приделать довольно просто (через zsh completion, н-р). Но теряются возможности:

1. внесения требуемых _тебе_ комментариев по поводу ключа и его свойств и возможных значений (типа

# этот ключ будет равен true, когда @#$%^c васька поправит свою долбаную библиотеку

my_super_nuper_key = false

2. внятной версионизации с внятными же комментариями на каждую версию. Много мне удовольствия знать, что некоторый ключ был поправлен в 1084501971 пользователем alex. А _почему_ поправлен был, может, этот самый alex в этот момент был в зюзю пьяный и пытался сдуру навести таким образом резкость на изображение?

3. Удобство редактирования. Вы будете спорить, что в части текстового редактирования нормальные текстовые редакторы на порядки удобнее этих вот недоделанных gconf-editor'ов? И gconf-editor _всегда_ будет хуже, чем текстовый редактор, потому что в текстовом редакторе я могу сделать undo, могу проскакать обратно курсором по тем местам, по которым я уже скакал, н-р, ища некоторый ключ (см. incremental search) итп?

4. Насчет интуитивной понятности - это, блин, прямо песня какая-то. Непристойная по большей части. Хотите, я дома эксперимент поставлю, посажу семидесятишестилетнюю бабушку разбираться с этой "интуитивно-понятной" тулзой разбираться? А что, с _интуицией_ у бабушки неплохо, чес-слово.

Да и преимущества "интуитивной понятности" в сравнении "логичностью" интерфейса, знаете, далеко не очевидны. Мне профессиональные бухгалтеры рассказывали (в 97 году), что пользоваться 1C _неудобнее_, чем тем же БЭСТом (а человек знал и то, и другое, и у меня нет оснований ему не верить). Но теперь по прошествии 7 лет я вижу, что 1С в конечном итоге выиграла. Почему? Явно не из-за интуитивной понятности, а, скорее, из-за более низкого стартового порога и удачного маркетинга.

И если цель у всех этих гномьих приблуд именно такая - завоевание доли на рынке за счет дебильного большинства, то так и нужно говорить: мы ориентируемся на дебилов, которые слаще морковки ничего не едали, а _удобство_ работы этих самых дебилов нас не волнует совершенно. Тупой, еще тупее, @#$.

Re:

> В Mozille назначить этот самый startMyHackerXprog.sh MIME helper'-ом.

noexec на ~? Мы вообще про песочницу говорим, или где?