Итак, у нас имеется:
16120 open("/dev/ppp", O_RDWR) = -1 EPERM (Operation not permitted)
Вы упоминали, что права "дадены"... Хммм... Ну что ж пробую воспроизвести у себя:
2.6.16-026test017
template: fc4
pppd (fc4):
-bash-3.1# rpm -qa | grep ppp
ppp-2.4.2-7
Имею ту же ситпацию!
Смотрю в исходники ядра:
drivers/net/ppp_generic.c:
...
static int ppp_open(struct inode *inode, struct file *file)
{
/*
* This could (should?) be enforced by the permissions on /dev/ppp.
*/
if (!capable(CAP_NET_ADMIN))
return -EPERM;
return 0;
}
...
Ага, значит VE нужны NET_ADMIN права. Останавливаю VE и даю ей эти права
(без перезапуска VE установка прав не работает)
(вообще это "грязный хак", и так делать не стоит.
. Это баг что проверяется NET_ADMIN, а не VE_NET_ADMIN, будем фиксить)
[hw]# vzctl stop 35
Stopping VPS ...
VPS was stopped
VPS is unmounted
[hw]# vzctl set 35 --capability net_admin:on --save
Saved parameters for VPS 35
[hw]# vzctl start 35
Starting VPS ...
VPS is mounted
Setting CPU units: 1000
Setting devices
VPS start in progress...
[root@dhcp0-174 tmp]# vzctl enter 35
entered into VPS 35
-bash-3.1# pppd
pppd pppdump
-bash-3.1# pppd
-bash-3.1# echo $?
1
-bash-3.1# pppd
-bash-3.1# echo $?
1
Ага. Прошли куда-то дальше и там провалились...
Что же в логах:
-bash-3.1# cat /var/log/messages | grep pppd
Sep 18 00:57:42 hw pppd[17673]: pppd 2.4.2 started by root, uid 0
Sep 18 00:57:42 hw pppd[17673]: Couldn't set tty to PPP discipline: Invalid argument
Sep 18 00:57:42 hw pppd[17673]: Exit.
Sep 18 01:12:23 hw pppd[20190]: pppd 2.4.2 started by root, uid 0
Sep 18 01:12:23 hw pppd[20190]: Failed to open /dev/pts/0: Device or resource busy
Sep 18 01:12:23 hw pppd[20190]: Exit.
Установка некоего discipline фейлиться... Посмотрим что там в коде pppd:
if (ioctl(tty_fd, TIOCSETD, &ppp_disc) < 0) {
if ( ! ok_error (errno) ) {
error("Couldn't set tty to PPP discipline: %m");
return -1;
}
}
Между тем ppp_disc = N_PPP. Посмотрим кто его провайдит в ядре:
linuxsrc $ grep -r tty_register_ldisc ./ | grep N_PPP
./drivers/net/ppp_async.c: err = tty_register_ldisc(N_PPP, &ppp_ldisc);
linuxsrc $ cat kernel-2.6.16-026test017-i686.config.ovz | grep CONFIG_PPP_ASYNC
CONFIG_PPP_ASYNC=m
Т.е. в OpenVZ он скомпилен модулем. Видимо он у нас на HW не загружен! Проверяем и загружаем:
[hw]# lsmod | grep ppp
ppp_generic 20620 0
slhc 6240 1 ppp_generi
[root@dhcp0-174 ~]# modprobe ppp_async
[root@dhcp0-174 ~]# echo $?
0
[root@dhcp0-174 ~]# lsmod | grep ppp
ppp_async 8960 0
crc_ccitt 2048 1 ppp_async
ppp_generic 20620 1 ppp_async
slhc 6240 1 ppp_generic
Отлично пробуем сызнова =)
-bash-3.1# pppd
-bash-3.1# echo $?
1
-bash-3.1# tail -3 /var/log/messages
Sep 18 01:59:15 dhcp0-174 pppd[25632]: pppd 2.4.2 started by root, uid 0
Sep 18 01:59:15 dhcp0-174 pppd[25632]: Couldn't create new ppp unit: Operation not permitted
Sep 18 01:59:15 dhcp0-174 pppd[25632]: Exit.
Значит приключения не кончаются! =)
strace даёт:
25784 ioctl(10, PPPIOCNEWUNIT, 0x80083c08) = -1 EPERM (Operation not permitted)
Между тем в логаз на ноде появилось:
PPP: couldn't register device ppp0 (-1)
что соответствует следующему в ядре
ret = register_netdev(dev);
if (ret != 0) {
printk(KERN_ERR "PPP: couldn't register device %s (%d)\n",
dev->name, ret);
goto out2;
}
значит провалились в register_netdev()....
Смотря дальше по коду попадаем в функцию register_netdevice, которая проверяет следющеее:
ret = -EPERM;
if (!ve_is_super(get_exec_env()) && ve_is_dev_movable(dev))
goto out;
Т.е. зарегестрировать net_devive из VE можно только, если он в списке так называемых "movable". К ним относится например: tun, loopback, ...
Почему не относится ppp? Очень просто - это баг! Будем фиксить.
В результате ответ на ваш вопрос
Quote: |
Такое вообще возможно?
|
Пока нет!
Пока нет. Сейчас зафайлю баг и в ближайшее вермя профикшу.
Огромное вам спасибо,
за обнаружение!