Darren J Moffat wrote:
> Riny Qian wrote:
>>Darren J Moffat wrote:
>>>Riny Qian wrote:
>>>>Please take a look at the updated virtual console spec:
>>>>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
>>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
> /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
>>>Is the ioctl interface compatible with that on any other
>>>platform or is it unique to OpenSolaris systems ?
> 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/#.