Для построения TUI для alterator необходимо и достаточно обеспечить возможность общаться с демоном через сокет, напрямую. В каком-нибудь удобоваримом (XML?) формате. При этом сохраняется вся существующая инфраструктура, к которой планируется добавить модульный TUI.
Давайте я попробую.
У нас уже есть alteratord, имеющий /var/run/alteratord/.socket. alterator-browser-qt тоже общается через Unix-сокет (/root/tmp/alterator/browser-sock) (насколько я знаю, обмен происходит через структуры Scheme). Осталось научится снифферить эти сокеты (ни через nc, ни через strace у меня это не получилось). Считаю, что XML будет оверхедом. Если уже делать грамотно, то лучше JSON.
(В ответ на комментарий №2) > Если уже делать грамотно, то лучше JSON. Разработчики, которые обещали мне содействие в решении вопроса с TUI, также произносили это слово. +1 за JSON.
(В ответ на комментарий №2) > насколько я знаю, обмен происходит через структуры Scheme К browser-qt XML, обратно Scheme.
(В ответ на комментарий №3) > JSON. его синтаксис соответствует синтаксису JavaScript и это создает ряд проблем безопасности. Зачастую для обработки данных, полученных от внешнего источника в формате JSON, к ним применяется функция eval() без какой-либо предварительной проверки. http://ru.wikipedia.org/wiki/JSON#.D0.92.D0.BE.D0.BF.D1.80.D0.BE.D1.81.D1.8B_.D0.B1.D0.B5.D0.B7.D0.BE.D0.BF.D0.B0.D1.81.D0.BD.D0.BE.D1.81.D1.82.D0.B8
(В ответ на комментарий №4) > К browser-qt XML, обратно Scheme. Преобразование ведётся в alterator-browser-qt, которая и держит сокет?
> формате JSON, к ним применяется функция eval() без какой-либо предварительной > проверки. Ну и не надо применять eval. и вообще, YAML читабельнее.
(In reply to comment #7) > > формате JSON, к ним применяется функция eval() без какой-либо предварительной > > проверки. > > Ну и не надо применять eval. > > и вообще, YAML читабельнее. Что вы имеет против eval? Хотелось бы отметить, тот факт что в eval приезжает результат работы backend-а, который выполняется с правами root. Какая безопасность, о чем вы?
(В ответ на комментарий №8) > Что вы имеет против eval? Хотелось бы отметить, тот факт что в eval приезжает > результат работы backend-а, который выполняется с правами root. Какая > безопасность, о чем вы? Это для alteratord. Здесь же предлагается сделать общий сервер приложений с отдельным сокетом.
(В ответ на комментарий №9) > Здесь же предлагается сделать общий сервер приложений с отдельным сокетом. Зачем отдельный? alteratord уже сть. И сокет у него уже есть. И backend-ов много понаписано. Не хватает только TUI для полного счастья. Если alteratord будет уметь "разговаривать" с внешним миром посредством JSON или еще каким-то удобоваримым образом, то TUI может быть реализован в обозримом будущем. Если сегодня в backend можно написать все, что угодно, вплоть до rm -rf /, то о какой (без)опасности еще говорить? Все останется в таком же виде.
(В ответ на комментарий №8) > Что вы имеет против eval? Не только. Там еще есть. А против того, что это потом начнут в веббраузер тащить.
(In reply to comment #10) > Если сегодня в backend можно написать все, что угодно, вплоть до rm -rf /, > то о какой (без)опасности еще говорить? > > Все останется в таком же виде. Отличный вид. (In reply to comment #11) > (В ответ на комментарий №8) > > Что вы имеет против eval? > Не только. Там еще есть. А против того, что это потом начнут в веббраузер > тащить. Там это где? Что тащить в веббраузер? Eval и так там уже. form.js -> form_ajax() Есть какая-то опасность, что от backend-а приедет s-выражение, которое потом будет преобразовано в некий json, который выполнится на стороне клиента и приведет к ужасному и страшному? (речь про alterator-fbi)
(In reply to comment #10) > Если сегодня в backend можно написать все, что угодно, вплоть до rm -rf /, > то о какой (без)опасности еще говорить? > А что хочется то? Выполнять backend-ы под учетной записью пользователя?
(В ответ на комментарий №13) > А что хочется то? Выполнять backend-ы под учетной записью пользователя? Дожить до того дня, когда комментирующие будут помнить о том, что все эти телодвижения ради TUI, о чем написано в первой же фразе описания FR. TUI, естественно, запускается от root. Либо доступ к модулю также, как и в web-варианте.
(In reply to comment #14) > TUI, естественно, запускается от root. Типа, работающий с правами рута бэкэнд может провести атаку - передать пакет данных специального вида и выполнить произвольный код с правами рута?
(В ответ на комментарий №15) > Типа, работающий с правами рута бэкэнд может провести атаку - передать пакет > данных специального вида и выполнить произвольный код с правами рута? Типа посредством TUI можно сделать все, то же, что и посредством alterator-qt и/или через WEB-интерфейс. Не больше, но и не меньше. Не понимаю, в чем проблема.
Товарищи, я просто хотел добавить text->xml->scm в качестве альтернативного преобразования к уже имеющемуся сейчас text->scm и всё (d.scm). Если получится, можно будет потом и text->json->scm прикрутить рядышком. Всё остальное останется как было: один alteratord, один сокет, и права рута в бакендах. В браузер тащить оттуда нечего.
(В ответ на комментарий №13) > А что хочется то? Выполнять backend-ы под учетной записью пользователя? Я этого хочу, но в другой баге ;-) https://bugzilla.altlinux.org/23377
(В ответ на комментарий №6) > (В ответ на комментарий №4) > > К browser-qt XML, обратно Scheme. > Преобразование ведётся в alterator-browser-qt, которая и держит сокет? Никакого преобразования не ведется.
