[vconsole-discuss] Where is the source code ?

[LingBo Tang]

No source available outside.
You can refer from internal workspace if you want.

Regards,
Lingbo

Moinak Ghosh wrote:
> Hello,
> 
>Looking at the downloads I cannot see any source code available. where
> can I grab the source ? Is there a mercurial repository present ?
> 
> Regards,
> Moinak.
> --
> This message posted from opensolaris.org
> ___
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

[vconsole-discuss] Trusted Extensions impact investigation

[LingBo Tang]

Hi all,

The attached file is the summary of investigation on TX with
virtual console project. Your feedback are appreciated.

Regards,
Lingbo
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: tx-investigation.txt
URL: 

[vconsole-discuss] Re: Trusted Extensions impact investigation

[LingBo Tang]

William Young wrote:
> LingBo Tang wrote:
>> Hi all,
>>
>> The attached file is the summary of investigation on TX with
>> virtual console project. Your feedback are appreciated.
> This looks like a good summary to me.
> 
> A few concerns I have are:
> 
> Whether the system will remain properly usable without the hotkeys and 
> will not leave open hidden sessions.  I.e. when starting X it must move 
> automatically to the new VT (if X is started on a new VT) and must kill 
> any existing commandline login and must also transition back correctly.
>

When X start on a new VT, it will not kill anything because it will
open a fresh VT to use. For instance, there are 6 VTs in text mode,
and the default X server runs on the 7th VT. Whenever we start a new
X server via gdmflexiserver or other ways, the new X server will open
the 8th VT to use.

Because the console login was disabled and can not be switch, I think
this way is safe.

> While it is necessary for TX systems to have hotkeys off by default, we 
> do allow administrators to intentionally enable solaris features that 
> would not pass evaluation.  My preference would be to first use a (SMF?) 
> property if the administrator has explicitely set it but otherwise 
> determine the default of whether hot keys are enabled by 
> libc::is_system_labeled().
> 
>  From the perspective of solaris secure by default, I do not think it is 
> acceptable if hotkeys are session remappable either.  I think you need 
> the keys to be administrator configurable and then need to deliver key 
> events first to the VT management and if they do not match a VT hot key, 
> on to the active VT session.
> 
> Multiple X servers and a gui switch event is an interesting problem.  It 
> will be necessary to disable the possibility of any single label X 
> sessions or one can visually emulate the switcher with trusted path.  I 
> don't think that is a concern right now, but should be a noted 
> requirement if a secure X switcher is mentioned.
> 
> Thanks,
> -Will
>>
>> Regards,
>> Lingbo
> 
> ___
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

[vconsole-discuss] What is the current status of virtual consoles?

[LingBo Tang]

Nigel Smith wrote:
> Hello. My question is 'What is the current status of virtual consoles?'
> 
> I know this question was asked earlier in the forum, but all I can find
>  are off-topic replies!
> Is there an answer to the question in one of the posts, hidden amongst 
> the spam? If there is, then sorry - I did not find it.
> 
>  From what I can understand of the proposals posted in the forum,
>  it all looks very good, but probably a bit over the top for what
>  I actually need at this stage.  But has any code been written yet? And is
> anything available for testing with Solaris Express?
>  
> What I would like, is to be able to use Solaris in the same way I 
> often use Linux - Just press Alt-F1, Alt-F2, Alt-F3, etc, & switch to a
>  different console. Often I don't even use X on a Linux server, 
>  as having multiple text consoles is sufficient for what I want to do.
> 

This project is in progress and focusing on security issues, like secure
hot keys and switching. And this is the mainly advantage of virtual
console on Solaris comparing with the other OS.

You can install the basic version with normal switch functions from
http://opensolaris.org/os/project/vconsole/Downloads/
This bfu archive is based on onnv_47. It works as you expected, like
hot key switch. You can have a try.

We will upgrade the workspace to the latest version soon but we have not
decide when the new binary can be available because of current security
issues.
Of course, if you have any special interests on generic functions,
we can help you.

>  When I show my colleagues Solaris, they are amazed that you
>  cannot just switch consoles, as Linux makes it look so easy. 
>  And the feature has been in Linux for such a long time.
>  
> I'm fairly new to Solaris, so maybe I'm missing something obvious
> & there is any easy way to have Alt-F# consoles, that I have not found.
> If so, I would appreciate some advice.
> 
> But, assuming I do need 'virtual console', then my bottom line is, when
> is this likely to be available in Solaris Express?
> Thanks
> Nigel Smith
> --
> This message posted from opensolaris.org
> ___
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

[vconsole-discuss] console device management proposal

[LingBo Tang]

Hi all,

The attachment is a proposal for "console device management"
in virtual console. Your comments are really appreciated!

Regards,
Lingbo
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: vt-dev-investigation.txt
URL: 

[vconsole-discuss] Proposal for "active link" in VT

[LingBo Tang]

Darren J Moffat wrote:
> LingBo Tang wrote:
>> Dear all,
>>
>> There is a proposal for "active link node" in VT.
>> Your comments are greatly appreciated!
> 
> I don't understand what you are trying to say here.
> 
> Please clearly state what the problem is you are trying to solve.
> 

OK, I add some background.
In solaris, logindevperm(4) will set ownership/permission on
console devices for login users. The console devices are defined
in /etc/logindevperm. Its format looks like:

/dev/console 0600 /dev/sound/*

This means all devices under /dev/sound are treated as console device
for /dev/console.
During a user login on /dev/console, all devices in /dev/sound/
will be set as mode=0600 and their ownership will be set as the
login user.

This works well because there is only one local login device
/dev/console available.
But after virtual console is available, there will be some additional VT
devices for login, these devices are under /dev/vt.
The users can choose to login on anyone of VT devices or /dev/console.

In order to process logindevperm(4) when user logged in on VT
devices, we need to expand the process of logindevperm(4).
In order to make the configuration file /etc/logindevperm more
meaningful after our expansion, we suggest to replace the name
/dev/console with /dev/vt/active. The new format looks like:

/dev/vt/active 0600 /dev/sound/*

Therefore, it's easier to understand that the logindevperm(4) will
be used on active login devices, not only be used for /dev/console.
For application, like devfsadmd(1M), it can retrieve information
from /dev/vt/active when it sets the ownership on plug-in devices.


Regards,
LingBo

[vconsole-discuss] Proposal for "active link" in VT

[LingBo Tang]

logindevperm only take effect during login time and connecting
removable devices.
When previous session end, logindevperm will set these
devices back to 'root' to wait for next login regardless
whether there is another active session or not.

Regards,
LingBo

Darren J Moffat wrote:
> Consider this.
> 
> User logins in on /dev/vt/4  and /dev/vt/active points to that.
> So /dev/sound/* gets owned by the user on /dev/vt/4.
> 
> The active VT is changed to /dev/vt/2.
> 
> The /dev/vt/4 session is ended without it becoming the active VT.
> 
> What happens to the ownership of the devices ?
> 
> -- 
> Darren J Moffat

[vconsole-discuss] Proposal for "active link" in VT

[LingBo Tang]

Darren J Moffat wrote:

> What manages /dev/vt/active ?
>
> When does it change ?
> 
> Does it ever not exist ?
>

In general, we think vtdaemon can manage this file. we also
tried to use devname file system, but not finalized yet.
Anyway, after a success VT switch, the target of the symlink
will be set to new active node. The target will be inited
as "/dev/console", and this symlink can be accessible in any case.

Regards,
LingBo

[vconsole-discuss] [Fwd: devname and VT]

[LingBo Tang]

FYI.

In general, we suggest to let "vtdaemon" maintain the symlink.

 Original Message 
Subject: devname and VT
Date: Mon, 02 Jul 2007 17:03:12 +0800
From: LingBo Tang 
To: Edward Pilatowicz , Vikram Hegde 
, Jerry Gilliam , Artem 
Kachitchkine 
CC: virtual-console-iteam 

Dear all,

According to recent research on "devname filesysetm" for "active
link node" in VT, I have following summary.

1. the device nodes under /dev/vt are managed by build-in devname
file system. During the first access, lookup() routine will create
the node if the user has privilege. This file is a real device node
instead of symlink to /devices. Accordingly, ddi_create_minor_node()
will not be used for device node management.

On the other hand, because there is no master node for VT, we will
decrease the number of device nodes during readdir().
This will cause below result:

ls /dev/vt/200 -> success
ls /dev/vt -> '200' can not be displayed

A workaround can avoid above issue, like defining a static number
as max threshold when display files under /dev/vt. ( users can
modify the threshold explicitly ) But this workaround seems lose
the advantage of dynamic allocation/deallocation from devname file
system.

2. The active node name is /dev/vt/active, which is a symlink file
and points to the current active console, like "/dev/vt/3".

Whenever the symlink is accessed, its content will be validated
and refreshed if the active node was changed.

In order to support create symlink, devname file system need to be
expanded a little ( although its plug-in module can support symlink ).

3. Summary

- current VT usage model is not match with devname as other cases,
   like pts and clearview;
- manage active link as symlink in devname filesystem requests expand
   current devname.
- VT daemon can update the contents of "active link" by two syscalls,
   which only have a very small time window for potential incorrect
   plug-in device accessing.
- suggest to manage "active link" by VT daemon and support devname file
   system as an enhancement for VT if necessary in future.


Regards,
LingBo

[vconsole-discuss] [Fwd: devname and VT]

[LingBo Tang]

Darren J Moffat wrote:
> LingBo Tang wrote:
>> - current VT usage model is not match with devname as other cases,
>>   like pts and clearview;
>> - manage active link as symlink in devname filesystem requests expand
>>   current devname.
>> - VT daemon can update the contents of "active link" by two syscalls,
>>   which only have a very small time window for potential incorrect
>>   plug-in device accessing.
> 
> very small ?
> 
> No window of incorrectness is acceptable, since a race condition like 
> this could lead to possible incorrect permissions and this security 
> problems.
> 
> It MUST always be correct, if you can't make it always correct don't do it.
> 

How about change the target of symlink as below?

During VT switch, change the target to next target VT first, then
do actual VT activate ioctl.

if the target VT has no user login, ( in another words, login programs
is using that VT, and the ownership of VT node is root ) then the
worst case is the ownership of new plug-in device is set to "root".
The user can do plug-out/plug-in again to solve the incorrect ownership
for this case.

If there has been user login on target VT, the plug-in device will
belong to that user.

Because switching VT and changing target of symlink are 2 operations,
how to make it work in synchronization way?

Regards,
LingBo

[vconsole-discuss] [Fwd: devname and VT]

[LingBo Tang]

Darren J Moffat wrote:
> LingBo Tang wrote:
> 
>>Darren J Moffat wrote:
>>
>>>LingBo Tang wrote:
>>>
>>>>- current VT usage model is not match with devname as other cases,
>>>>  like pts and clearview;
>>>>- manage active link as symlink in devname filesystem requests expand
>>>>  current devname.
>>>>- VT daemon can update the contents of "active link" by two syscalls,
>>>>  which only have a very small time window for potential incorrect
>>>>  plug-in device accessing.
>>>
>>>very small ?
>>>
>>>No window of incorrectness is acceptable, since a race condition like 
>>>this could lead to possible incorrect permissions and this security 
>>>problems.
>>>
>>>It MUST always be correct, if you can't make it always correct don't 
>>>do it.
>>>
>>
>>How about change the target of symlink as below?
>>
>>During VT switch, change the target to next target VT first, then
>>do actual VT activate ioctl.
> 
> 
> What happens then if the activate ioctl is interuptted or some how fails ?
> 
> This needs to be atomic.
> 
> 
>>if the target VT has no user login, ( in another words, login programs
>>is using that VT, and the ownership of VT node is root ) then the
>>worst case is the ownership of new plug-in device is set to "root".
>>The user can do plug-out/plug-in again to solve the incorrect ownership
>>for this case.
> 
> 
> Having the user need to plug and unplug things to fix problems in our 
> architecture isn't aceptable.
> 
> 
>>If there has been user login on target VT, the plug-in device will
>>belong to that user.
>>
>>Because switching VT and changing target of symlink are 2 operations,
>>how to make it work in synchronization way?
> 
> 
> It is only to operations because your implementation is making it that 
> way.  It needs to be an atomic operation or you need to drop the active 
> symlink concept.  Maybe a symlink is the wrong implementation.  Maybe 
> the kernel subsystem when it does the switch should be updating the 
> active node (ie it isn't actually a symlink but a different name for 
> /dev/vt/#).
> 
> 
> 

devfsadmd(1M) will retrieve the uid/gid from console tty,
i.e. /dev/vt/active, for plug-in devices by stat(2).
Any other type will require changing current implementation of
devfsadmd.

Regards,
LingBo

[vconsole-discuss] devname file system and VT

[LingBo Tang]

Dear all,

Based on the discussion these days, there is an update version
of summary. It introduces the behavior of /dev/vt on devname
file system for VT. Your comments are appreciated.

1. The device nodes under /dev/vt are managed by devname
file system built-in functions. These files are real device
nodes instead of some symlinks to /devices. Accordingly,
ddi_create_minor_node() will not be used any longer.

2. When the VT nodes were accessed by user/apps at the first time,
corresponding lookup()/readdir() routines will create these nodes.
These file have "root:tty" ownership and mode "0620" as default
attributes. These properties will also be changed after a user
login, which is as same as what will be done for /dev/console.

3. There is a count number for all valid VT nodes in system.
All the valid nodes can be displayed by 'ls' command, and can
be accessed by privilege user. The count number can be changed.
Its default value is 16. After increase/decrease this count,
the valid VT nodes under /dev/vt will be changed during next
accessing time accordingly.

For instance:

By default, there are 7 VT are using by console-login
and graphic login.

A. run "ls /dev/vt", it displays all 16 VT nodes from "0" to "15"
and one active link file.

B. run "ls /dev/vt/16", it will report "no such file".

4. The name of active link file is /dev/vt/active, which is a
symlink file and points to the current active node,
like "/dev/vt/3". Its ownership is "root:sys", and mode is "0777".
This file is always available for end user.

Whenever this file is accessed, its content will be validated
and refreshed if the active node was changed.

In order to support create symlink, devname file system need to be
expanded a little ( although its plug-in module can support symlink ).

5. Summary

- All VT nodes under /dev/vt are real nodes, and will not be managed
   by ddi_create_minor_node.
- There is a count number for valid VT nodes. Default count is 16.
   All valid VT nodes can display with "ls" command regardless it is
   in-use (link open(2) or whatever) or not. The count number can be
   configured dynamically.
- Active link file is a symlink which points to the active node under
   /dev/vt. It requests an expansion of current devname filesystem
   implementation.
- The content of active link file is always correct because it will be
   validated during accessing every time.
- There is no create/remove operations for end user under
   /dev/vt directory. All these create/remove operations will be
   done internal.

Thanks in advance for your time!

Regards,
LingBo

[vconsole-discuss] Proposal for "active link" in VT

[LingBo Tang]

Dear all,

There is a proposal for "active link node" in VT.
Your comments are greatly appreciated!

Proposal:
replace "/dev/console" with "/dev/vt/active" in  /etc/logindevperm as below:

/dev/console  0600  /dev/sound/*

will be changed as:

/dev/vt/active 0600 /dev/sound/*


Justification:
1. /dev/vt/active may be a little more straightforward for users.
This means the logindevperm(4) will take effect on active VT nodes.
Meanwhile, because only one user can take the ownership, the policy
also will follow first-login-first-serve way for multiple users.

This will not change usage of libdevinfo interfaces:
di_devperm_login/logout().

2. For new plug-in devices in this file, their user/group ID can be
retrieved from active node pointed by /dev/vt/active in devfsadmd(1M).
Currently, devfsadmd stat(2) on /dev/console for plug-in devices.

3. VT active link node is a symlink file pointing to the file
under /dev. Its default target is /dev/console.
After a VT switch, the target will point to the new active node.

Thanks in advance for your time!

Regards,
LingBo

[vconsole-discuss] Re: What is the current status of virtual consoles?

[LingBo Tang]

Nigel Smith wrote:
> Ok, I have given it a try, and here is my feedback:
> 
> I have never done an install from a bfu archive before,
> but I thought I would give it a try.  
> Usefully, Ben Rockwood gave some advice, via his blog,
> on how to do a bfu upgrade, at just the right time:
> http://www.cuddletech.com/blog/pivot/entry.php?id=802
> 
> I had snv_57 installed, but was anyway planning soon to upgrade
> to snv_60, so I was not too worried if it trashed my os.
> As the vconsole seemed to be built for build 47, this was
> effectively a downgrade, so I was expecting problems.
> 
> I downloaded the 'vconsole-20060908.i386.tar.bz2' file. (File size is 89MB)
> and used BFU.
> I kept a log of all the commands and output, and rather that post it here,
> as it is rather long, I have uploaded it to my web site in case any one
> is interested to take a look:
> http://www.nwsmith.net/solaris/vconsole-bfu-downgrade.txt
> 
> Ok, so after the BFU was installed, I rebooted.
> 
> During restart, I got various errors:
> ...undefined symbol...
> ...cannot load module...
> ...service failed to start - transitioned to maintenance...
> 
> But, surprisingly, I did end with getting a console login!
> So I logged in:
> 
>   login as: root
>   Password:
>   Last login: Fri Mar 30 20:21:58 2007
>   Sun Microsystems Inc.   SunOS 5.11  vt-gate October 2007
>   bfu'ed from /root/vconsole-20060908.i386/vconsole-bfu-i386-b47/ on 
> 2007-03-30
>   Sun Microsystems Inc.   SunOS 5.11  snv_57  October 2007
>   # uname -a
>   SunOS solaris 5.11 vt-gate i86pc i386 i86pc
>   #
> 
> I pressed Alt-F1 and got a 'vt1 login:'
> (Good!)
> I then pressed Alt-F2, but just got ^[[225z
> (Bad!)
> 
> It seems you cannot (always) immediately follow Alt-F#, by another
> Alt-F# and get the next console. Sometimes it works, but other times
> it just displays ^[[22# (Where # represents a digit)
> 
> (It seems that after you press Alt-F#, you need to press a different
> key, before it will accept another Alt-F#)
>

You can not press one key for next hot-key sequence.
For instance, you need to release "Alt" firstly before "Alt-F2".
This is a typical usage in Solaris.

> And how do you get back to the 'console'?
> 

You can use "Alt-h" to go back /dev/console.
But we will change the hot keys sequence in next version to make these
hot keys compatible with other systems.

> So it sort of works, but not well enough to be usable.
> Ok, you Sun guys still have some work to do on this.
> 
> I think it's an important feature, so I hope you can get it working
>  soon and integrated into a Solaris Nevada release.
> 
> I understand that you need to keep backwards compatibly for people
> familiar with the old Solaris versions. But I think you also need
> to give an option, at install time, for people trying OpenSolaris
> for the first time, who have used Linux or FreeBSD before,
> who will expect a more usable 'console'.
> Thanks
> Nigel
> --
> This message posted from opensolaris.org
> ___
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

[vconsole-discuss] Re: What is the current status of virtual consoles?

[LingBo Tang]

Darren J Moffat wrote:
> David Bustos wrote:
>> Quoth LingBo Tang on Mon, Apr 02, 2007 at 09:15:18AM +0800:
>>> Nigel Smith wrote:
>>>> It seems you cannot (always) immediately follow Alt-F#, by another
>>>> Alt-F# and get the next console. Sometimes it works, but other times
>>>> it just displays ^[[22# (Where # represents a digit)
>>>>
>>>> (It seems that after you press Alt-F#, you need to press a different
>>>> key, before it will accept another Alt-F#)
>>> You can not press one key for next hot-key sequence.
>>> For instance, you need to release "Alt" firstly before "Alt-F2".
>>> This is a typical usage in Solaris.
>>
>> I don't understand how that would be typical.  Please explain.
> 
> I agree with David this seems wrong.  It also if I remember correctly is 
> different to the behaviour on Linux.
> 
> It is also different to the behaviour of GNOME when you have hotkeys 
> programmed to switch between workspaces.  I have F? where ? is 
> the workspace number and I can (and do) keep the shift key pressed and 
> flick between workspaces.   I'd expect virtual consoles to work the same 
> way.
> 

I remembered that there was a scenario that we need to release Alt
key before next function keys ( before virtual console project ) but
I can not find it now.

Anyhow, the hot key usage should be changed as other systems usage
in next version. We will release new version with secure switch feature
in community first.
Thanks!

Regards,
Lingbo

[vconsole-discuss] Re: Re: What is the current status of virtual

[LingBo Tang]

Nigel Smith wrote:
> Lingbo, I'm glad to hear that in the new (next?) version of the code,
> it will not be required to release the 'Alt', before pressing another
> function key, to select the next virtual console.
> 
> When I'm using Linux in text mode, I like to be able to hold the 'Alt' key 
> down
> with a finger on my left hand, and then use a finger on my right hand to
> press the Function keys, and take a look at each of the consoles in turn.
> It would be great if I could do the same thing with Solaris.
> 
> And yes, I think that using 'Alt-h' to get to '/dev/console' needs to change.
> My advise would be to use 'Alt-F1' to get '/dev/console' as the default.
> But then I think once people get familiar with the idea that '/dev/console'
> is special, they may want to move it to another key, like 'Alt-F12'.
> So I think you need to make the key used configurable in some way.
>

The usage of "Alt-h" will be removed in next version because the 1st
virtual console stand for /dev/console now. You can use "Alt-F1" for
system console.
"Alt-h" is a sequence in old solaris (maybe 2.5 or 2.6), and we are
considering the compatibility with other systems, link Linux now.
For instance, "Alt-F7" will go to the 7th console, "AltGraph-F4" goes
to the 14th console if it's created. "Alt-l" is used to invoke last
accessed console etc. All of them will be same as Linux.

For remapping the hot key sequence, you can refer to the usage of
loadkeys(1) and dumpkeys(1), which have same semantics as Linux from my
understanding.

> Also, will we be able to configure how many virtual consoles are available?
> I would like the option of more than 6 virtual console, as there are 
> usually more function keys available.
> 

Sure, you can configure the active number of virtual consoles.

> Another nice feature I've seen on Linux, is the ability to configure
> it to display syslog output on one of the virtual consoles.
> Will it be possible to do something like this with Solaris?

If you can describe more details in this function as you expect,
we may think about it. Thanks!

Regards,
Lingbo

[vconsole-discuss] Re: Re: What is the current status of virtual

[LingBo Tang]

David Bustos wrote:
> Quoth LingBo Tang on Fri, Apr 06, 2007 at 10:26:43AM +0800:
>> The usage of "Alt-h" will be removed in next version because the 1st
>> virtual console stand for /dev/console now. You can use "Alt-F1" for
>> system console.
>> "Alt-h" is a sequence in old solaris (maybe 2.5 or 2.6), and we are
>> considering the compatibility with other systems, link Linux now.
>> For instance, "Alt-F7" will go to the 7th console, "AltGraph-F4" goes
>> to the 14th console if it's created. "Alt-l" is used to invoke last
>> accessed console etc. All of them will be same as Linux.
> 
> I don't recall Alt-L returning to the last console in Linux.  Do you
> have a reference to some documentation?
> 

Linux has "Last_Console" usage, which is not enabled by default now I
think but the user can enable it.
In virtual console, we implement this function by "Alt-l/Alt-UPARROW"
for last accessed console.
And we added "Alt-p" as same as "Alt-LeftArrow" for previous
console; added "Alt-n" as same as "Alt-RightArrow" for next console.

There is an old documentation for linux:
http://www.linuxjournal.com/article/1080

Regards,
Lingbo

[vconsole-discuss] Virtual Console new release available NOW!

[LingBo Tang]

Hi all,

The new release for "Virtual Console" is available in opensolaris now:

http://opensolaris.org/os/project/vconsole/Downloads/

There is a brief changes list for your reference:

1. add many secure feature, like secure switch via vtdaemon, which 
require password during switching. follow SMF policy for vtdaemon and
console-login service etc.

2. virtual terminal names are changed as "/dev/vt/#", and the 1st
virtual terminal use "/dev/console", which can be accessed via "Alt-F1".

3. You can press "Alt" key during switch between several virtual consoles.

...

Your feedback are appreciated. Have fun!

Regards,
Lingbo

[vconsole-discuss] Virtual Console new release available NOW!

[LingBo Tang]

Hi all,

The new release for "Virtual Console" is available in opensolaris now:

http://opensolaris.org/os/project/vconsole/Downloads/

There is a brief changes list for your reference:

1. add many secure feature, like secure switch via vtdaemon, which
require password during switching. follow SMF policy for vtdaemon and
console-login service etc.

2. virtual terminal names are changed as "/dev/vt/#", and the 1st
virtual terminal uses "/dev/console", which can be accessed via "Alt-F1".

3. You can press "Alt" key during switch between several virtual consoles.

...

Your feedback are appreciated. Have fun!

Regards,
Lingbo

[vconsole-discuss] Question regarding compatibility

[LingBo Tang]

virtual console depends on another project "coherent console" which
use "kernel terminal emulator" instead of OBP for console output
on SPARC. So far, coherent console can only run with XVR-100.

The support on other graphic cards are still in development I guess.

William Yang wrote:
> Is virtual console still only supported on the XVR-100 on SPARC?  Is there 
> any support for XVR-500 yet?
> --
> This message posted from opensolaris.org
> ___
> vconsole-discuss mailing list
> vconsole-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/vconsole-discuss

[vconsole-discuss] Re: [osol-discuss] Virtual Console new release available NOW!

[LingBo Tang]

Mike Ford Ditto wrote:
> 
> Also in Amiga Unix there was an "index" screen that showed a brief list of the
> open virtual consoles and a w(1)-like display of what was running on each one.
> You could use the arrow keys or mouse to switch to one of the screens.  The
> index screen could be selected by Alt-Esc, but it also became selected
> whenever the last process closed the currently selected console.  I.e., when
> you log out, you are shown a list of virtual terminals, reminding you that you
> might also need to log out on some of them as well.
>

I think it's not secure to display the other console's sessions for
user, especially in Trusted Extensions systems.

Anyhow, for these user-friendly utilities, we can implement them step
by step after all programming interfaces become stable.

Regards,
Lingbo

[vconsole-discuss] help review updated virtual console spec

[LingBo Tang]

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.
> 
> DJM-2 2.7.2 ACLs for usb etc devices
> 
> Are you saying that if user "bob" logins in on vt1 and
> user "alice" logins on vt2 then there will be an ACL of
> both of them on the audio and usb devices ?
> 
> I don't think this is a good idea.  I'm also concerned
> about how this interacts with device allocation and
> Trusted Extensions.
> 
> Please ask the security community to review this whole
> proposal for possible interactions with Trusted Extensions.
>

As we discussed with Trusted Extensions group before, they said
there is no user login on console in a full configured Trusted
Extensions system, including root who will work like a role.
So the change for /etc/logindevperm will not affect their system.

Anyway, we will send them the latest spec for review.

> DJM-3 2.8 SMF Service
> 
> As per my previous emails I believe that the /dev/vt#
> devices should just be instances of console-login and you
> should not need a separate vconsole-login even due to
> Zones.
> 
> DJM-4 2.9 tipline
> 
> How does this interact with consadm(1M) ?
> 
> DJM-5 2.10 kmdb
> 
> I expected that kmdb and panic would not be displayed
> on the current vt but only on the console and that you
> would still be able to switch to the console to interact
> with kmdb.   However I think this mode might be acceptable
> and even desirable in some cases.
> 
> DJM-6 2.12 Xorg
> 
> What about Xsun since that is still used on SPARC.
> 
> DJM-7 General
> 
> Is the ioctl interface compatible with that on any other
> platform or is it unique to OpenSolaris systems ?
> 
> 
> 

[vconsole-discuss] vconsole prototype yet ?

[LingBo Tang]

Alan Coopersmith wrote:
> Darren J Moffat wrote:
>> Is there a prototype of the vconsole work yet ?
>>
>> See CR# 6446957, we need vconsole to make the GDM/GNOME "Switch User"
>> functionality work properly.
>>
> 
> Virtual console is also needed for gdm to replace the current
> "hacky" method used by dtlogin for "Command Line Login" so that
> users can get to a console prompt from the gdm login screen.
> 

We are going to open '/dev/console' from system startup, and there
is no change in dtlogin for 'command line login' option therefore.
This means the user can return to command line from 'dtlogin' greeting
GUI via choosing 'command line login', and he can get to a virtual
console after login X.

On the other hand, I like gdm's way who does not provide a 'command line
login' option at all.

[vconsole-discuss] vconsole prototype yet ?

[LingBo Tang]

Alan Coopersmith wrote:
> LingBo Tang wrote:
>> On the other hand, I like gdm's way who does not provide a 'command line
>> login' option at all.
> 
> That's a bug, not a feature - before gdm replaces dtlogin, it needs to
> provide a way to get to a command line login, and the planned way of
> doing that is to rely on virtual console to switch to a console with a
> text login prompt.
> 

I know, it's the reason why gdm is not the default one.
I mean I think there is no need for 'command line login' option after
virtual console implementation.

[vconsole-discuss] vconsole prototype yet ?

[LingBo Tang]

Alan Coopersmith wrote:
> LingBo Tang wrote:
>> I mean I think there is no need for 'command line login' option after
>> virtual console implementation.
> 
> There might be an option in the GUI, but it should just activate a
> virtual console switch with instructions on how to return.
> 
> 

Do you mean this option maybe available for gdm? BTW, are you going to
make gdm as the default one after virtual console available?

Furthermore, I think it's a little implicit to return a virtual console
from 'command line login' rather than with 'Alt+Ctrl+F#' keys.
For instance, if there are more than one consoles opening, who knows 
which one is the user's target?

I think it's much explicit if there is no such option, and user may
switch to any console with 'Alt+Ctrl+F#' keys in X. (At least, I was
used to this way on Linux.)

[vconsole-discuss] vconsole prototype yet ?

[LingBo Tang]

Riny Qian wrote:
> 
> 
>>
>> Furthermore, I think it's a little implicit to return a virtual console
>> from 'command line login' rather than with 'Alt+Ctrl+F#' keys.
>> For instance, if there are more than one consoles opening, who knows 
>> which one is the user's target?
> 
> Previous active virtual console or the system hard console before X
> starts up, if this option is really needed.
> 
>>

Can the 'system hard console' be configured by user?
If so, after disable console login on system hard console like:
svcadm disable console-login:xxx,
what will happen when we choose 'command line login'? Or this option
will be disabled at that time?

I guess the X may start on system hard console in most cases.

[vconsole-discuss] current status

[LingBo Tang]

Robert Milkowski wrote:

> Hi.
> 
>   I'm curious what is a current status for vconsoles? Unfortunately I do not 
> understand a word here... :)

This project is going quite well, and it has the highest priority now.
In the 1st phase, the prototype can work well like Linux mode, and it 
can switch with Xorg. We hope it can be available early next year.

[vconsole-discuss] current status

[LingBo Tang]

Robert Milkowski wrote:

> 
> LT> This project is going quite well, and it has the highest priority now.
> LT> In the 1st phase, the prototype can work well like Linux mode, and it 
> LT> can switch with Xorg. We hope it can be available early next year.
> 
> You mean integrated into Nevada early next year or into Solaris 10?
> 

So far, we consider Nevada only.

> Are there any bits to Open Solaris to test something right now?
> 

I don't think it's possible to do this right now although the
prototype is already opened for internal users.
There still are some issues in prototype and Xorg switching.
But I think it might be possible to make this feature accessible early
before the final integration.

Regards,
LingBo

[vconsole-discuss] current status

[LingBo Tang]

Robert Milkowski wrote:
> 
> I guess it would be great to make it available on OpenSolaris.org -
> even in BFU or some other form. At the end you'll have better testing
> and early user feedback.
> 
> 
That's true. It's great to get more feedback from community during our
working.