In message <[EMAIL PROTECTED]>, "Martin C. Atkins" writes: >On Mon, 18 Jul 2005 12:45:32 +0200 [EMAIL PROTECTED] wrote: >"Plan 9 way" of dealing with this be to run a multiplexer process >pre-login, that multiplexes access to /dev/draw(etc) across several >virtual consoles, and puts a login process in each one? Could that be >done with the current mechanisms? I guess it would have worked with 8
I've avoided chiming in on this one because the whole thing seemed a very non-Plan 9 thing and because I've never worked that way or needed that behavior. But this suggestion has piqued my interest. >From the user's perspective I'm picturing something along the lines of a new menu entry in rio that is, say, Suspend. When that is selected, the current set of windows all "go away" (really hidden but no longer accessible from the menu) and are replaced by a dialog that lets you select a suspended session or to start a new one. Both options would require a password. As other's have mentioned, this password doesn't provide any real security. It's just there to make it hard for your daughter to save her latest artistic masterpiece on top of your latest coding masterpiece. As to implementation, I'm thinking that on boot the multiplexer starts up running as the machine owner. As has also been mentioned, it has a capability to change /dev/user which it does each time it brings up a new or suspended session. On creating a new session, it creates a new child process running as the new user and serves the usual /dev stuff to the child process. The only change to rio would be the new menu entry that would result in a note to the multiplexer or a message to some other file it serves. The behavior could either be controlled by a command line switch or rio could look for the multiplexer process and do the right thing when it's found. I know from experience how dangerous it can be to throw out ideas as I think them up. But it's up the flagpole now. Anybody interested in saluting or is this one that would be better off burried? BLS
