forgot to followup ngetty answer... -------- Original Message -------- Subject: about getty Date: 25.02.2011 16:44 From: Nikola Vladov <vla...@riemann.fmi.uni-sofia.bg> To: gur...@phys.ethz.ch
Hi Guerkan! Your patch is interesting. I didn't test it. I just received it. Next 4-5 days I am very busy. Seems that this is not a problem to patch ngetty with this feature. I must to beside first, if it is important, how dangerous is it. Off any case some notes: -- ngetty could start any programs with arbitrary arguments. I can make a shell script (for example login-ssh) and changing the configuration of ngetty it is possible to invoke ngetty-ssh, instead of /bin/login. The script login-ssh have to do similar to your patch for agetty. -- better is to write extra one program login-ssh instead of shell-script. One could include it in ngetty package and write how we could use it. On this way the main daemon ngetty will not include more code. -- the bad in this configuration is that ssh run as root on the console. I would say this is a big security hole. Better to have an ssh-public and process run as this UID. This is another arguments for separate program. The user have root access using ssh escape. -- Your idea for VT_OPENQRY is good. Some days ago a wrote a similar program lsvt. You could see it on: http://62.44.100.74/ngetty/ngetty-1.2-rc1.tar.gz My code is similar to yours: One could use it also as denial of sevice. For example on some tty the user could make chmod 0 /dev/path/to/my/tty + if (newvtno < vtno) + { + char vtname[TTY_NAME_MAX+3]; + + sprintf( vtname, "tty%d", newvtno ); + + if ((fds[vt_cnt++] = + open(vtname, O_RDWR|O_NONBLOCK, 0)) < 0) ^^^^ /* Ops ;) */ + { + error(_("/dev/%s: cannot open: %m"), tty); + } + } -- Your words about the kernel are right !!! I am also unhappy. It is not easy to open a tty. See my lsvt.1 Ragards, Nikola I am also a montain guide. Next week I'll go in montain. I don't have access there to PC, but I have lots of time to tink about your IDEA. Thanks for the mail. BTW some people have problems to start ngetty. That's exactlly as you describe: + * Try to avoid opening a vt that is already open, as this will + * mean that the keyboard will be unusable. + * + * Unfortunately, all the kernel gives us to find out is an ioctl + * for the next available vt. As the kernel doesn't open the vt for + * you with the ioctl, there is still a chance of both processes + * opening the same vt, but this check is far better than nothing at + * all.
