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/#.




Reply via email to