Если я не ошибаюсь в адресовании баги, то pppd при установлении соединения меняет права на /dev/modem (устройство, по которому переговаривается) на 640, то есть группа (uucp) теряет право записывать в порт. Если это он виноват, надо его отучить менять права на устройства.
Не этот ли код с этим связан? Просто ничего другого в ppp про chmod не нашёл :) ppp-2.4.2-asp-cbcp-mps.patch: if (fstat(ttyfd, &statbuf) < 0 + || fchmod(ttyfd, statbuf.st_mode & ~(S_IWGRP | S_IWOTH)) < 0) { + warn("Couldn't restrict write permissions to %s: %m", devnam); + } else + tty_mode = statbuf.st_mode;
Женя, можешь проверить/починить?
Уговорили... Беру на выходные модем:)
И как ?
Нужно проверить еще на чистом Compact 3.0rcX Ибо у меня все работает(с)
Дистрибутив: Master2.4 Таже ситуация! Кто-то меняет права на модем. Обычно на 640, а недавно на 600. Модем пользуют: pppd(in) и qico(in). Оба висят на mgetty.
Имею: ppp-2.4.2-alt6 Права меняет с завидной повторяемостью. На буке после kppp сеанса права меняются с 660 на 640. В следствии чего qico звонить не может. На сервере, после входящего ppp сеанса права меняются с 660 на 600. В следствии чего qico виснит при первом же Fidonet сеансе при попытке закрыть устройство. После чего порт вообще блокируется.
2ldv: вам не интересен этот пакет? :) 2mike: сделай что-нибудь :)
2lav: меня устраивает работа этого пакета в том смысле, что я пока не готов инвестировать в его доработку. :)
Возможно это из-за отсутствия записи в /etc/security/console.perms. Сегодня на серваке добавил, вечером проверю на буке и сервере. Как временное решение в /etc/ppp/ip-down.local добавлял команду востановления прав. Ночь прожил без приключений. Хотя заметил одну вещь. После того как я подключился через ppp на сервак и глянул права, то увидел 0600. Выключился, подключился из вне и увидел 0660. Т.е сбросило сразу после подключения, а после отключения востановило из ip-down.local. :)
На клиенте пользующем KPP прописывание прав в /etc/security/console.perms не помогает. Устойчиво меняет на 0640. На сервере, уже три дня как не слетали права.
(In reply to comment #11) > На клиенте пользующем KPP прописывание прав в /etc/security/console.perms не > помогает. Устойчиво меняет на 0640. > На сервере, уже три дня как не слетали права. Вот они и слетели. Складывается впечатление что ppp в отдельных случаях забывает или уже не в состоянии востановить права! Надо что-то делать!
(In reply to comment #12) > (In reply to comment #11) > > На клиенте пользующем KPP прописывание прав в /etc/security/console.perms не > > помогает. Устойчиво меняет на 0640. > > На сервере, уже три дня как не слетали права. > Вот они и слетели. Похоже, на сервере они слетали из-за mgetty. Обновил Mgetty из Сизифа и уже пол месяца права не слетали.
Я вот нынче обнаружил, что права на порт меняются сразу после старта pppd. Он у меня запускается на роутере, доступ к которому только по ssh, поэтому пляски вокруг console.perms не помогли. А обнаружил это просто: sudo chmod 660 /dev/ttyPCT (модем ZyXel, чип PCtel789) Запуск скрипта дозвона и сразу ls -l /dev/ttyPCT выдает crw-r----- 1 root uucp 62, 79 Дек 4 12:50 /dev/ttyPCT Натравил на это дело strace, вывод прилагаю. Там есть еще маленькие comments. Не умея пока разобраться, кладу все. Система- ALM2.4+updates+несколько пересобранных в хашере пакетов, среди них ppp-2.4.2-alt6.
Created attachment 1273 [details] вывод strace
Вот комментарий к выводу strace: Дал команду sudo strace -o ~/pppd.trace -ff /мой/скрипт/дозвона Это кусочек вывода ps -A _во время выполнения_ strace: 9629 pts/0 00:00:04 strace 9633 ? 00:00:00 pppd Нашел такую штуку: [diman@beer diman]$ grep chmod pppd.trace.9633 fchmod(7, 020640) = 0 Вот предшествующий кусок: open("/var/lock/serial/LCK..ttyPCT", O_RDWR|O_CREAT|O_EXCL, 0644) = 7 getpid() = 9633 write(7, " 9633\n", 11) = 11 close(7) = 0 open("/dev/ttyPCT", O_RDWR|O_NONBLOCK) = 7 fcntl64(7, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) fcntl64(7, F_SETFL, O_RDWR) = 0 fstat64(7, {st_mode=S_IFCHR|0660, st_rdev=makedev(62, 79), ...}) = 0 fchmod(7, 020640) = 0 Что, pppd после открытия порта меняет права на него? Или я не то подумал?
Я не понял, pppd не восстанавливает права на устройство по окончании работы? P.S. Пакет ppp давно ищет хорошие мантейнерские руки.
Не восстанавливает. Хотя было бы верным не менять их вообще. Тут как с fstab почти :)
Ну вот, припекло. Придётся заняться.
Created attachment 1680 [details] don't remove group write permission (drop others' though) так покатит? мне (на эту тему) достаточно btw думаю ещё control прикрутить.
(In reply to comment #20) > > так покатит? мне (на эту тему) достаточно > По-моему тоже, достаточно. Полет нормальный (на М2.4). > btw думаю ещё control прикрутить.
Дим, приложи патчик pls или добавь в заливателей lakostis mike mithraen (тех, кто ковырял). ppp ldv
fixed in 2.4.4
Увы, на 2.4.4-alt7 опять воспроизводится.
(In reply to comment #24) > Увы, на 2.4.4-alt7 опять воспроизводится. Виновник найден, это ppp-2.4.4-cbcp-alt.patch, который в т.ч. откатывает ppp-2.4.2-alt-leave-ttyperms-alone.patch: - || fchmod(ttyfd, statbuf.st_mode & ~S_IWOTH) < 0) { + || fchmod(ttyfd, statbuf.st_mode & ~(S_IWGRP | S_IWOTH)) < 0) { Придётся сделать ещё один патч к этому патчу...
Объехато здесь (mike/fix-perms-6042): http://git.altlinux.org/people/mike/packages/?p=ppp.git;a=commitdiff;h=06b8deb7a0e5efba8f14a27944986c081b279952 2 mithraen: возьмёшь или выдашь? :)
Спасибо! Отправил в incoming/
