Darren J Moffat wrote: > Riny Qian wrote: > >>Darren J Moffat wrote: >> >>>Riny Qian wrote: >>> >>> >>>>All, >>>> >>>>Please take a look at the updated virtual console spec: >>>> >>>>http://www.opensolaris.org/os/project/vconsole/vconsole-spec.txt >>>>http://www.opensolaris.org/os/project/vconsole/vt.7i.txt >>>> >>>>Any comments are welcome. >>> >>>DJM-1 2.6 /dev/console & root login >>> >>>I'm not sure you can allow root login on /dev/console >>>and on /dev/vt#. The /etc/default/login variable CONSOLE >>>only specifies a single device and I'm not sure I'm comfortable >>>with /dev/console meaning /dev/console and all of /dev/vt. >>> >>>However I do see possible value in allowing local root >>>logins on multiple vts, so I'll need to think more about >>>this. >> >>Since we trust it on /dev/console, we should trust it on /dev/vt#. >>Otherwise it would be inconvenient in practice. > > > I don't think that necessarily follows, consider this > case. > > /dev/console could, I believe, be a serial line. That > means that the console could be in a physically separate > location to the usb attached keyboard/mouse and the monitor. > > In that case it may not be desirable that root can login > on the /dev/vt# entries but we would accept it on > /dev/console since that is the serial line. > > My concern is with CONSOLE=/dev/console suddenly starting > to mean /dev/console and all the allocated /dev/vt# entries. > > Now in my opinion CONSOLE= is actually the wrong interface > here. On at least one Linux system I've seen they do > this check in a PAM module (where we should be doing it) > and it checks a file /etc/securetty. > > That file has listed in it all of the /dev entries > that root may login on. I notice on CentOS that vc/1 > etc are listed. > > Now I don't think this case should need to fix the > problem we have with login(1) being the place we do > the CONSOLE= check, nor do I think this case needs to > ship a PAM module to replace that. > > What we do need to agree on though is if /dev/console > should continue to mean just /dev/console or should > it mean /dev/console and all /dev/vt# devices. Personally > I prefer that it say meaning just /dev/console and that > some other case fix login(1) and introduce the appropriate > PAM module to allow root to login on other devices. >
What if we do extend /dev/console meaning to include /dev/console and all /dev/vt# devices in this case, and will do that fix in later case? Is there any impact? > > Which brings up another question why are we naming the > device /dev/vt# when Linux is naming them /dev/vc/# ? > Any reason to be different here ? > No, Linux is using /dev/tty#. (/dev/vc/# is for some other purposes.) >>>DJM-7 General >>> >>>Is the ioctl interface compatible with that on any other >>>platform or is it unique to OpenSolaris systems ? >> >>compatible. > > > So if the ioctl interface is compatible with Linux > it seems to me that we should also be using /dev/vc/# > as the device names. Using a subdir seems more like > what Solaris would do here, eg /dev/pts/7 /dev/term/a. > > IIRC the /dev/tty* devices are SunOS 4.x compatibility > names only. > We thought /dev/vt# would be compatible with Linux, and is simpler than /dev/vc/#.