ага, вот и ссылочка. Именно это я и имел в виду.

2LP

>>Лежит этот mdw у разработчика, пользователи его никогда в руки не получают, и крякалками взломать не смогут

? в смысле по входу - кодом переподключать .SystemDB .DefaultUser и .DefaultPassword, а также закатать это фсе в mde ? Да так, чтобы owner (и пользователи) mde не имел доступа к таблицам (до переподключения)? Тогда, таблицы - заведомо в другой бд (права на объекты, если помню правильно, лежат в базе, разве что вхождениями в группы регулируются снаружи), а ее owner-а юзер найдет крякалкой, если прознает путь подключения... А можно ли запретить ему прознать путь "в лехкую", например подключившись как овнер mde и запросив поля MSysObjects ?

SELECT DISTINCTROW MSysObjects.Database, MSysObjects.Connect, MSysObjects.ForeignName, MSysObjects.Name
FROM MSysObjects
WHERE (((MSysObjects.Database) Is Not Null)) OR (((MSysObjects.Connect) Is Not Null));

Или вообще другое решение? чей-то не соображу

Есть прога Сергея Гаврилова (кажется), которая ИМЕННО по приложению возвращает овнера и его УИД. Посему, узнав его, злой юзер создает СВОЙ mdw с требуемым овнером и уидом уже СО СВОИМ паролем. В менеджере групп (правда, должен иметь права админа в в2000 на машину, на которой будет это делать) переподключает mdw и делает с таблицами что хочет.\r
\r
Либо (если прав админа на тачку нет) подключается к новому mdw программно (- Насчет .SystemDB я, похоже, соврал. когда-то, казалось, пробовал; - но сейчас перепроверил - не меняет. Или я что-то не так творю.)\r
- после входа в свой новый mdb (пишет в процедуре че нить\r
Set DBE = GetObject("", "DAO.PrivateDBEngine.36") \r
DBE.SystemDB = strSysFilePath \r
DBE.DefaultUser = strUserName \r
DBE.DefaultPassword = strPassword \r
Set db = DBE.OpenDatabase(...) )\r
, затем подключает (видимо кодом) требуемые таблицы - ибо для этого нужнО только совпадение логина и уида пользователя (имеющего права), но не путь к mdw, - и вот и ладушки. А что подключать - может выянить "на дому", забрав копию базки, если сможет :0). Там то он поимеет нужные права для подключки менеджером.\r
\r
К тому же (и главное) я не понял, как юзер не будет видеть SystemDB, если для работы ему нужны ВСЕ права (и на чтение и на запись) на эту дрянь?

А.
По пунктам:

1. Создал новый mdw. (New.mdw)
2. Запустил Access с ним (New.mdw). (Ага, вот и ладушки - с параметром командной строки - не все, что можно, вспоминаешь в нужный момент). Естественно перший раз Вы - admin.
2. Создал в New.mdw юзера с логином owner-а требуемой БД и уидом ("кодом" диалога создания нового пользователя Аксес, если лохи не в курсе. Поскольку мдв (и мдб, в каком мы это будем делать) свежий, то ничто не мешает). Кстати сказать, это (ввод точно таких же юзеров с точно такими же кодами) рекомендуемый способ восстановления мдв при случайном или еще каком его крахе (без наличия резервных копий). (Правда при этом надо видимо заранее в сейф запечатать вводимые уиды, иначе ведь в нужный момент недокличешься, без прилад типа прилады СГ). // для нас достаточно ввести именно только овнера.//
3. Задаем стандартному админу (admin) в New.mdw пароль, входим теперь как новый юзер в аксесс (как правильно напомнил ЛП - с параметром стартовой строки New.mdw). И, (о радость) - открываем "взламываемый" файл с правами его ownera.

Что в пунктах не ясно?

___
В.
Убери права на чтение/запись у юзера на файл system.mdw и попробуй под ним (юзером) подключиться к Аксесу имеено с этим system.mdw. Неужто получается? У меня матерится, почем зря. Так вот, я и не понимаю, как >>не давать ему тот mdw-шник<<

Что тут не ясно?

брал там же, только (по моему), MS Access' 95/97/2000 databases password tool v2.2 . В поле Database owner показывает USER .... PID ... (ага, кажется понял - прошу прощения за непонятки с уид - склероз в тяжолой форме - PID!=UID )

Боюсь, лох, ты тут не прав. Посмотри справку по МС Акс. "Личный код, он же PID". Я просто уже ДЕЛАЛ то, что предлагал выше - вводил возвращаемый PID в поле код при создании "нового" юзера (правда, использовал .mda). И подключался к "чужой" бд в качестве владельца. Правда делал я это с год назад. Исключительно в исследовательских целях. Т.к. пароль владельца в "старой" system.mda я и так знал "по обязанности".

Не уверен, что пользовался приладой СГ, но вроде бы больше нечем - надо перепроверить - делал я это дома. Все есть под рукой, но ломает напрягаться в тяпницу).

Файл Access хранит не только Login-ы, но и PID-ы юзеров. А так же все их права на объекты (или права групп, но тогда доступ осуществляется только через проверку вхождения в группы - т.е. через проверку системника).

Именно поэтому достаточно одинаково ввести юзеров (с кодами) в системники, чтобы подключатся к одной и той же бд используя то тот - то этот .mdw (если ты имешь права как юзер self, а не как член группы - а это всегда верно для owner-а). (Наверное, именно поэтому PID доступен программно только на запись, но не на чтение. Как Гаврилов это обходит - его ноу-хау). А отсутствие юзера в системной базе не означает, что его PID недоступен из БД. Он просто "спрятан", но не очень хорошо.

Я патаму и написал, что "боюсь", ибо не помню, какую приладу юзал :). Помню, что похожа была на экзешник (склероз крепчает). А У сГ - .mdb а перепроверять - ленннььь, да такая, чтааа...

И даже вот поюзать приладу СГ и то лень. т.ч. поверю пока что на слово :0). Но не на долго.

БЕБЕБЕ!
Надоело лениться проверил (создал .mda в администраторе групп Access97) Все тики-тики. Прошло, как я и писал. По Гавриловской проге.

Версия:
в mda вводится в качестве "личного кода" PID, А при вводе в mdw меняется? - отпала, в силу прочтения справки по "преобразованию" mda - .mdw (рекомендуется ввести всех заново руками - тоже мне "преобразование".)

Устал ленится второй раз. Создал .mdw (в администраторе групп Access97) Прошло тип. топ.

(К сведению: проверяю каждый раз
?dbengine.SystemDB
?dbengine.Workspaces(0).UserName
хотя это и так панятна - пароли-то при входе разные - как и устанавливал)

БЕ-БЕ-БЕ!

2LP

нашел причину расхождения мнений (PID/SID):
прога Гаврилова дает таки PID owner-а, но не прорубает кирилицы. (напоролся надысь, "синхронизируя" разные, разошедшиеся по жизни системники) Т.ч. если в PID-е была кирилица, то "увы". (хорошо, что использовал однозначное правило создания юзарей). А SID -это "закодированный" PID (см. инструкцию по вводу пользователей - там, где рекомендуется "записать PID в бумажку", т.к. "Акес хранит PID в зашифрованном виде"). т.ч. процедура "подьема PID из SID" обязана сущ-вать - там где-то зашито взаимно однозначное преобразование.