Хорошо бы ссылку на RelNotes дать прямо на http://firebird3.com/en/news/official-firebird-3-release-candidate-1/

А то на Download page она таким "мелким шритом", что не враз и найдешь

RelNotes, page 38, databases.conf

По-моему в примере # Directives for MYBIGDB забыли убрать комментарии собственно для самих параметров

page 39, table 6.1

"Some parameters can be configured at the client connection via the DPB/SPB"

Таблицы какой параметр в каких местах можно указывать - не нашёл.
И в описаниях самих параметров их Scope тоже нет.

Раньше это, вероятно, не было окончательно решено, но в стадии RC наверное можно уже зафиксировать и задокументировать в каких Scopes какой параметр разрешен.

Также не описано разрешение конфликтов, если разные параметры указаны в DPB и database.conf
С потолка - если я в DPB укажу себе "удобный" ExternalFileAccess - я получу доступ к любому месту диска?

Аналогично с SecurityDatabase - можно будет получить полный доступ к любой БД, указав "правильную" security db в DPB ?

Ну и что лично меня напрягает, читая relnotes создается впечатление, что лоальное соединение теперь по умолчанию будет embedded - То есть ошибки в приложении будут потенциально портить кэш сервера и падать они тоже будут вместе.

"Задавить" embedded можно, видимо, зафиксировав Providers=Loopback в DPB
Но если это забыть сделать, то по умолчанию вместо безопасного XNET'a будет опасный Embedded

И наоборот, чтобы принудительно вызвать embedded, надо будет фиксировать "Providers=Engine12" - но я так понимаю как только выйдет версия сервера с новой ODS, то и название провайдера сменится, и эта hardcoded строка перестанет работать.
Как-то это кажется менее гибко, чем раньше, когда загружали либо fbClient.dll либо fbEmbed.dll, а с версиями ODS/сервера была гибкость/анархия/younameit

Симонов Денисах да и в третьих, ты не подключишься с помощью embedded если у тебя уже есть хоть один коннект к БД и используется SuperServer

...зато если Classic, то можно :-) В общем вот эта неопределённость (а точнее длинный список special cases) как-то напрягает.

...ну или тупо прав у юзера на доступ к файлу нет :-)
Вот! кстати!
Предположим у пользователя есть права на чтение (но не запись) файла БД.
Сможет ли тогда embedded подключиться в r/o connection или нет?
Пример - БД на CD-ROM под WinNT

Симонов ДенисЭто наоборот более гибко. Как только выйдет версия с новой ODS ты сможешь записать даже вот так "Providers=Engine12, Engine13"

...и отправить клиенту новую сборку старой аппликухи с другой hardcoded строкой

видимо мы смотрим на гибкость в разных местах

Симонов Денисточнее это чуть ниже описано в "URL-Style Connection Strings"

Да, это интересно. Спасибо.

Честно говоря, был бы рад увидеть там meta-протоколы Embedded ( in-process ) и not-embedded ( out of process ) на слчай например xnet почему либо не срабатывает, но TCP loopback работает.

Случаи отвала xnet при перезапуске 2.х после паления сервера на форуме были описаны

Запускаю установку на win7 x64 rus - и вижу эту прелесть.

Нет, я конечно и так в общих чертах помню, что там написано...

Следующее окошко уже было на номральном русском.

hvladНа линуксах всю жизнь так и было, там нет локального протокола.

Не линуксом единым же.

То есть я рад, если в FB будут появляться фишки "больших" серверов, но хотелось бы, чтобы при жтом он оставался прстым и удобным для "малых форм" тоже.

also

Симонов ДенисArioch,

это уже обсуждалось на первой странице. В трекер занесено

Эх, где там был мой пароль....

Именн этого там нету, но в принципе то же, да

Симонов Денис,

надеюсь, хотя немного стрёмно из-за мекой надписи внизу.

но в любом случае, для проверки исправления скриншоты пригодятся

Dimitry Sibiryakov,

Тут еще такое дело, мне вот *кажется*, что завязывать клиентскую аппликуху на названия DLL с провайдерами - это leaking implementations details

hvladЭто описано в firebird.conf

Да, спасибо. Но на этапе RC хорошо бы это уже переносить в доки, доступные без установки сервера.

hvladAriochТакже не описано разрешение конфликтов, если разные параметры указаны в DPB и database.confDPB имеет приоритет, иначе в нём вообще смысла не было бы.

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

hvladAriochС потолка - если я в DPB укажу себе "удобный" ExternalFileAccess - я получу доступ к любому месту диска?Это per-database, соответственно будет учитываться только для первого коннекта в embedded случае

А не-embedded ?

Вот соединяюсь я с Бд на сервере и в DPB добавляю себе ExternalFileAccess=C:\ (или /etc) и слизываю файл с паролями к серверной ОС ?

hvladAriochАналогично с SecurityDatabaseАналогично предыдущему случаю
Тут маленькая проблемка, что скорее всего Security Database должна лежать локально относительно движка, с сетевого диска она наверное не подцепится?

Но даже и так, предположим в компании есть два отдела.
На одном сервере у них у каждого по БД, каждая со своей Security
В одном отделе я - главный и у меня на нашу БД есть RDB$ADMIN
В другом отделе мне дали доступ на просмотр какого-то одного отчёта, который они для нас готовят через вьюху или SP.

Теперь я коннекчусь к ИХ БД указывая в DPB НАШУ security - и получаю полный доступ?

AriochВот тут я сомневаюсь. Настройки безопасности должны идти в обратную строну

Старый http://tracker.firebirdsql.org/browse/CORE-4641
Первый же комментарий: Letting the end-user control which security database to use is a security leak waiting to happen. This should be purely serverside.

Dimitry SibiryakovAriochТеперь я коннекчусь к ИХ БД указывая в DPB НАШУ security - и получаю полный доступ?
Зачем обязательно "нашу"? Ты же можешь создать новую или проинициализировать любую
существующую и стать там полноценным SYSDBA. Я уже об этом писал.

На сервере, к которому у меня нет файлового доступа, правильно создать security db ?

Если это и воможно технически, то довольно сложно. В моем случае вообще не надо никаких глубокихз знаний кроме любопытства и ibexpert

hvlad И является ли это неудобство объективным или твоим личным ?

Противопоставление бессмысленное. Личное неудобство является вполне объективным.
Или у нас в Палате Мер и Весов появилась гиря неудобности?

Dimitry Sibiryakov,

ну вот я предполагаю, что у меня нет возможности создавать БД, админ это пресёк
...и все равно

hvladАлех там всё рассказал

Classic server has bigger list of acceptable DPB parameters for obvious reason

"огласите весь список, пожалста" - это к вопросу, что дескать "все уже рассказано в firebird.conf"

hvladПока что кроме нытья "хочу как раньше"

Называем чёрное белым? Шарман.

Как раз "как раньше" - то есть когда все приложения и все БД были завязаны на одну единственную security2.fdb/security3.fdb - я и не хочу.

Именно об этом был CORE-4641 - плюс дополнительно еще там была просьба учитывать в databases.conf DRY-principle и сделать специальное значение, когда SecurityDatabase = DataDatabase, а не копировать полный путь.

~~~~~~~

Возвращаясь к use case и "малым формам".

Допустим есть относительно небольшое приложение, которое свои данные хранит в FDB.
Причем должна быть возможность создавать новые базы и открывать разные базы - как офисный пакет может открывать разные документы.
Использовать Embedded - крайне нежелательно: in-process не защищён от испорченной памяти и внезапных падений программы вместе с embeddeв-движком.
То есть использовать нужно SuperServer установленный локально. Да, для установки самого приложения и супер-сервера зовут админа, как и для становки того же офиса. Или как вариант, приложения и FB могут устанавливаться работать без админских прав (если FB3 все еще ожет работать как приложение win32, а не сервис)

Но возможность открывать/закрывать разные БД по выбору пользователя без звонка администратору нужна.
И вот тут возможность через DPB указать, что БД сама-себе-security и была бы нужна.

Тем более, что и дырки в безопасности при этом нет - есть ли в БД системные таблицы пользовательских прав проверяется движком. Дырка в безопасности появляется исключительно в варианте "БД одна, а SecDB другая, но не сама БД".

Симонов Денисчто-то я не понял чем ты возмущаешься.

"Возмущаешься" - это перебор, давай не нагнетать.

Мне не нравится

1. Нечеткий статус параметров - какие можно менять через DPB, а какие нет, и в кахи случаях. Судя по раздражению Влада - в настоящий момент сами разработчики этого ещё не знают. Менялось в процессе разработки и сводного документа тем более диздока по параметрам нет.
2. Невозможность использования режима "self-security" для маленьких программ работающих с несколькими маленькими БД. Потому что это потребует изменения databases.conf руками сисадмина. Да с высоты "у нас есть выделенный сервер для десятка терабайт данных и одной единственной программы" это кажется не нужным. Но для небольших программ ориентированных на менее опытных пользователей, чем администраторы выделенных серверов, это было бы весьма полезно.
3. Нарушение DRY Principle ( необходимость копипастить полный путь к файлу в случае DataB=SecurityDB )