Всем привет!Есть скриптик на перл, взаимодействующий с базой данных
Есть юзер, имеющий право этот скриптик запускать
Есть пароль, записаный в скриптике для доступа к БД
Есть права на чтение на этом скрипте для этого юзера, ибо без них скрипт не может быть выполнен.Хочется что бы умный юзвер не мог сказать more скрипт и прочитать пароль для БД.
Кто нить может предложить какие либо варианты решения данной задачки?
Компиляция при помощи экспериментальной утилиты perlcc, что нежелательно, ибо даст огромнейший бинарник, либо при помощи обфускации - особого способа шифрования перл-скриптов. Поищи в сети или на CPAN'е как это делается.
есть ещё комерческая утилита perl2exe
>есть ещё комерческая утилита perl2exeда, я забыл указать - работаю под FreeBSD 4.10 - 5.4, а она Фрю как то не любит
>>есть ещё комерческая утилита perl2exe
>
>да, я забыл указать - работаю под FreeBSD 4.10 - 5.4, а
>она Фрю как то не любитЗдесь в форумах уже поднимался подобный вопрос, только там вроде задача была скрыть исходники, у вас задача сложнее - вам надо скрыть строку. ИМХО, при желании, даже очень небольших знаний достаточно, чтобы вытащить эту строку из вашего бинарника.
>Всем привет!
>
>Есть скриптик на перл, взаимодействующий с базой данных
>Есть юзер, имеющий право этот скриптик запускать
>Есть пароль, записаный в скриптике для доступа к БД
>Есть права на чтение на этом скрипте для этого юзера, ибо без
>них скрипт не может быть выполнен.
>
>Хочется что бы умный юзвер не мог сказать more скрипт и прочитать
>пароль для БД.
>
>Кто нить может предложить какие либо варианты решения данной задачки?Вот выдержка из "man perlcompile":
> The Bytecode Back End
>
> This back end is only useful if you also have a way to load and execute
> the bytecode that it produces. The ByteLoader module provides this
> functionality.
>
> To turn a Perl program into executable byte code, you can use "perlcc"
> with the "-B" switch:
>
> perlcc -B myperlprogram.pl
>
> The byte code is machine independent, so once you have a compiled mod-
> ule or program, it is as portable as Perl source (assuming that the
> user of the module or program has a modern-enough Perl interpreter to
> decode the byte code).
>
> See B::Bytecode for information on options to control the optimization
> and nature of the code generated by the Bytecode module.Это то, что вам нужно. И, что самое главное, это то, что всегда с вами :-)
Почитайте еще man perlcc.
Может это - я на тупняке=)
но всё таки предложу решение...
perl как язык предназначен для работы с текстовыми файлами, так?
а что мешает вынести пароль и юзверя для доступа к БД в отдельный тектовый файл и потом номальным образом считать его оттудова?
чем такая идея не подойдет?
>Может это - я на тупняке=)
>но всё таки предложу решение...
>perl как язык предназначен для работы с текстовыми файлами, так?
>а что мешает вынести пароль и юзверя для доступа к БД в
>отдельный тектовый файл и потом номальным образом считать его оттудова?
>чем такая идея не подойдет?
Потому как юзверь:
а) открывает скрипт
б) смотрит на какой файл ссылаемся
с) смотрит этот файл
д) снова знает логин/пароль
>Потому как юзверь:
>с) смотрит этот файлАсь? а если права доступа 700 задать?.. Или это сам админ так хулиганит... Ну на то он и админ ;-)
>>Потому как юзверь:
>>с) смотрит этот файл
>
>Ась? а если права доступа 700 задать?.. Или это сам админ так
>хулиганит... Ну на то он и админ ;-)а овнер кто? Поскольку скрипт запускает пользователь, выполняться он будет с его правами, => у него должно быть право на чтение и другого файла
>>Может это - я на тупняке=)
>>но всё таки предложу решение...
>>perl как язык предназначен для работы с текстовыми файлами, так?
>>а что мешает вынести пароль и юзверя для доступа к БД в
>>отдельный тектовый файл и потом номальным образом считать его оттудова?
>>чем такая идея не подойдет?
>
>
>Потому как юзверь:
>а) открывает скрипт
>б) смотрит на какой файл ссылаемся
>с) смотрит этот файл
>д) снова знает логин/парольЯ никогда не возился до такой степени и наверное скажу жуткую глупость - но по моему на файл можно поставить права read и execute, а вот без read будет ли производится выполнение?
кроме того что за юзверь такой который могет понять скрипт ?
если он продвинутый но не до конца тогда есть простое решение - запихать сичтываение файла за экран=) то есть просто чтобы его не было видно на экране когда просматриваешь скрипт - для просмотра текста скрипта нужно было бы двигаться стрелкой вправо достаточно далеко=)
но это - глупое решение но простое для не до конца продвинутых юзверей=)
хотя и продвинутые не всегда на стрелку вправо жмут...
а так - более нормальное и сложное решение написано вверху...
>
>Я никогда не возился до такой степени и наверное скажу жуткую глупость
>- но по моему на файл можно поставить права read и
>execute, а вот без read будет ли производится выполнение?Не будет, поскольку перл скрипт является интерпритируемым, а следовательно читается и передается интерпритатору на выполнение
>>
>>Я никогда не возился до такой степени и наверное скажу жуткую глупость
>>- но по моему на файл можно поставить права read и
>>execute, а вот без read будет ли производится выполнение?
>
>Не будет, поскольку перл скрипт является интерпритируемым, а следовательно читается и передается
>интерпритатору на выполнение
Попробуйте утилиту perlapp от ActiveState. Она имеется и под win и под nix. Хотя насчет freebsd Я не уверен что заработает (на линуксе работает точно).
Есть еще вариант по запудриванию мозгов юзеру. Помести функцию в которой определяется пароль к базе в отдельный модуль (желательно ОО), в скрипте напиши типа:$db_password="blablabla";
при коннекте к базе используй $db_password, НО - переопредели этот параметр в функции из внешнего модуля, типа так,
какой-то код до коннекта к БД здесь переменная $db_password имеет значение blablabla
my $secret=Secret::OO::Function->new();
здесь переменная (она должна быть глобальной) уже имеет реальное значение.
далее коннект к базе.Это конечно фэйк - но юзера даже немного шарящего в perl оттолкнет (или затруднит)
А в чем глубинный смысл сокрытия пароля от юзера?
Что мешает завести отдельного пользователя БД и выдать ему права, которые не позволят делать телодвижения с объектами БД, превышающие функциональность скрипта?>Всем привет!
>
>Есть скриптик на перл, взаимодействующий с базой данных
>Есть юзер, имеющий право этот скриптик запускать
>Есть пароль, записаный в скриптике для доступа к БД
>Есть права на чтение на этом скрипте для этого юзера, ибо без
>них скрипт не может быть выполнен.
>
>Хочется что бы умный юзвер не мог сказать more скрипт и прочитать
>пароль для БД.
>
>Кто нить может предложить какие либо варианты решения данной задачки?
>>Всем привет!
>>
>>Есть скриптик на перл, взаимодействующий с базой данных
>>Есть юзер, имеющий право этот скриптик запускать
>>Есть пароль, записаный в скриптике для доступа к БД
>>Есть права на чтение на этом скрипте для этого юзера, ибо без
>>них скрипт не может быть выполнен.
>>
>>Хочется что бы умный юзвер не мог сказать more скрипт и прочитать
>>пароль для БД.
>>
>>Кто нить может предложить какие либо варианты решения данной задачки?Кстати, опять возвращаясь к этой теме (все таки интересно - даже не то чтобы смысл а вот задача - скрыть пароли в скрипте).
Так вот скрыть пароли на самом деле от простого пользователя хостинга у которого есть только фтп доступ, и нет ssh (или ssh - через jail) не просто - а очень просто.
Пишите свой модуль, самый обыкновенный можно, работающий через use (с Exporter), в котором определяете все пароли и т.п (можно использовать для многих пользователей), кладете его в @INC (/usr/lib/perl/site etc.) - то есть каталоги недоступные для просмотра с jail или ftp и используете его из своего скрипта. Суть в том, что методы модуля возвращают дескриптор подключения, и все. То есть в скрипте это может выглядеть так:use MyModule;
my $dbh=DB_Connect(username,base_name);# передаем в функцию модуля имя пользователя (для многопользовательского скрипта) и имя базы данных.
Далее работаем с дескриптором $dbh как обычно.В модуле можете создать хэш типа:
my %Access=(user1 => passwd,
user2 => passwd
);И использовать этот модуль для всех своих недоброжелательных пользователей.
>>>Всем привет!
>
>Кстати, опять возвращаясь к этой теме (все таки интересно - даже не
>то чтобы смысл а вот задача - скрыть пароли в скрипте).
>
>Так вот скрыть пароли на самом деле от простого пользователя хостинга у
>которого есть только фтп доступ, и нет ssh (или ssh -
>через jail) не просто - а очень просто.К несчастью - это не хостинговый юзер, а типа пом сисадмина на удаленной точке, поэтому логин на тачку у него есть
>А в чем глубинный смысл сокрытия пароля от юзера?
>Что мешает завести отдельного пользователя БД и выдать ему права, которые не
>позволят делать телодвижения с объектами БД, превышающие функциональность скрипта?
>Просто скрипт должен делать еще и update, а вот юзеру давать таких правов не хочется. Ибо апдейт идет строго на определенное поле (timestamp), а юзер своими шаловливыми рученками может поменять значение и других полей
Ну что, Dr. Nebula, на каком варианте решения задачи остановились?
>Ну что, Dr. Nebula, на каком варианте решения задачи остановились?Пока - лишил пользователя права на UPDATE и DELETE, оставив только SELECT и INSERT
основные значения в таблице сделаны первичными ключами, следовательно дубликатов даже при сильном желании сделать не сможет
Думаю вынести поле требующее обновления в отдельную таблицу и дать UPDATE только на нее
Хотя на мой взгляд это не самое красивое решение и нарушает логику БД
>>Ну что, Dr. Nebula, на каком варианте решения задачи остановились?
>
>Пока - лишил пользователя права на UPDATE и DELETE, оставив только SELECT
>и INSERT
>основные значения в таблице сделаны первичными ключами, следовательно дубликатов даже при сильном
>желании сделать не сможет
>Думаю вынести поле требующее обновления в отдельную таблицу и дать UPDATE только
>на нее
>Хотя на мой взгляд это не самое красивое решение и нарушает логику
>БДМожет пирсмотреться к шифрованию пароля и дешифровки на лету?
Красивое решение - стоит того чтобы повозится.
Тут конечно все зависит от степени владения perl этим пом сисадмина.
Может быть тут хватит обычного MD5 и substr какого-то количества символов из хэша который и испоьзовать как пароль - но можно пойти дальше и присмотреться к Twofish например.
>Всем привет!
>
>Есть скриптик на перл, взаимодействующий с базой данных
>Есть юзер, имеющий право этот скриптик запускать
>Есть пароль, записаный в скриптике для доступа к БД
>Есть права на чтение на этом скрипте для этого юзера, ибо без
>них скрипт не может быть выполнен.
>
>Хочется что бы умный юзвер не мог сказать more скрипт и прочитать
>пароль для БД.
>
>Кто нить может предложить какие либо варианты решения данной задачки?Создай для выполнения скрипта отдельного юзера и группу
Сделай этого юзера владельцем скрипта, разреши запуск/выполнение для
группы
Скрипт сделай SUID'ным
В группу добавь юзера который реально скриптом будет пользоваться
Пароль храни в отдельном файле: владелец - фейковый юзер, права на чтение только у юзера ( для группы запретить )Но на самом деле такие проблеммы должны решаться в базе. А что за база?