Casper.Dik at Sun.COM wrote:
> For now, it seems that the only thing we deal "properly" with is
> the "screen".
> Security does not allow sharing of any of the input devices (keyboard,
> mouse, audio) but because multiple sessions coexist we cannot
> revoke the access, even if we had the mechanism to do so.
> For the audio device, this is much more difficult:
> - device allocation does not solve this because it only gives
> one concurrent user access and it calls 'fuser -k' on
> running processes in other sessions
> - Windows is also broken as it allows all sessions to continue
> to stream output (as far as I can tell); is this something we
> want to emulate (well, Darren said he liked playing iTunes in
> one account while doing something else in another account, yet
> this seems wrong on general principle to me)
That was on MacOS X (I don't do Windows) and it doesn't appear to work
anymore - can't remember when it stopped working or if it was an
iTunes or OS upgrade that changed the behaviour.
> - the input of the audio device (eaves dropping, who remembers
> the "rsh hostname cat /dev/audio" scare??
Remember it, not only that I used it (for fun when a student!).
> This sort-of screams for a "session aware" audio mixer.
Hmn, now aren't we having that same discussion on an internal Sun list
at the moment with respect to Sun Ray audio!
> There is, of course, another solution: PUNT.
Which I take to mean do not update /etc/logindevperm with
/dev/vt/# entries so that login on a VT doesn't get changes to
any of the devices.
That at least means this project doesn't make things any worse
than they already are.
> Just assume that it's always the same physical user who is using
> different sessions so leakage is not an issue. But if this is
> acceptable, then we must have a secure attention key:
> - KILL ALL VT SESSIONS using a key sequence which cannot be
> disabled by programs, revoking all session I/O devices and
> resetting all ACLs, giving a clean "/dev/console" login.
> Such a secure attention key combination is long overdue anyway, but....
Ineed but I'm not sure this project should be given the task of
Darren J Moffat