Не этот ли код с этим связан? Просто ничего другого в 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/