models for user sessions, ssh, su, etc.

[Jörg Barfurth]

Havoc Pennington schrieb:

> Simple model: in a very simple model, you have 1 machine (set of
> hardware), 1 home directory, 1 user, 1 graphical display, 1 instance
> of each singleton app, etc. There's 1 instance of dbus to go with all
> this, and 1 instance of each thing on dbus. Developers from a
> Windows-type background are probably thinking along these lines.
> 
> Things that can mess up the simple model
> ===
> 
[...]
> * use *dm/startx to create two sessions on the same machine (N sets of
> apps, dbus, displays for 1 user and homedir)

> * multi-user systems (N user/app/homedir collections per 1 set of hardware)

There is one more twist in a similar direction as these items, but which 
doesn't seem to be fully reflected in your lists: multi-seat systems, 
where one machine (set of 'core' hardware) has multiple sets of 
peripheral hardware (including graphical and i/o), which are presented 
to users as self-contained seats. This could be realized in pluggable 
hardware (multiple graphics and I/O cards) or in a virtualized way with 
thin (or 'zero') clients or a similar form of remote access.

Here there may be multiple concurrent, active, local, graphical sessions 
(each having their own X server). If a user that still has a session on 
one seat tries to log in on a different seat, you can't generally 
redirect the existing X server to the different hardware.

So for one user that leads to your 'two sessions on same machine' case, 
but now hardware is only partially shared (for example every seat can 
have its own audio devices). And denying the second sessions means to 
lock out the user.

For multiple users this is a classical multi-user system, but again 
hardware is only partially shared. And as such setups often involve 
redundant servers and load balancing they frequently go with network (or 
replicated/synchronized) home dirs.

> * automounters (anything running outside of a login session has no
> homedir, or prevents homedir from unmounting)

Not sure how automounters fit in here (in general). But the issue of 
security contexts certainly has to be considered. Often a login creates 
credentials or an evironment that can be populated with credentials 
("the session") and those credentials should not all be active in a 
different session for the same user/home dir/hardware. That means that 
anything running outside a login session should not automatically have 
access to the same resources as a login session would nor to credentials 
of an existing login session (if any).


> ===
> 
> * Singleton GUI application, such as a music player. Launching it
> again on the same display should run the existing instance. Launching
> it again on a different display on the same machine should run a new
> GUI - for bonus points, the two GUIs could share the same backend,
> rather than having different music stomping on each other. 

In the multi-seat case they could just use their own hardware each. Any 
attempt to add intelligence to make them share a backend could actually 
break that case - while implementations that stomp on each other in the 
shared (contended for) hardware case would probably work fine

> But stomping could be fine - "don't do that then." Launching it again on
> the same display but on a _different machine_ is even more fun, and
> this case has with-same-homedir and without-same-homedir subcases.
> 
> * So say you go to open a url from app A which is not a browser, the
> relationship to the browser could be:
> - app A is on the same bus as the browser, same display, same homedir
> - app A is on a different bus (session? su?) from browser, but same display
> - app A is on a different machine from the browser, but same display
> and homedir.
> - app A is on a different machine from the browser, but same display
> and different homedir.
> 

Actual behavior I have seen included
- app A is on same home dir as (pre-existing) browser, but different 
display (same or different machine)

That definitely felt broken ...

> * "Suppress screensaver" API used by presentation and multimedia apps.
> This should be per-display.
> 

Yes.

> * GUI app from a second user, created with su or sudo, displaying on
> first users display. How do the following work:
> - suppress screensaver API
> - open an URL in browser
> - save settings to a configuration service
> - receive "about to logout" warning message and run a conversation to
> block logout while showing a dialog
> - add an icon to panel
> 
> * tray icons / window manager plugins / window manager itself: one per display
> 
> * hardware-related services: one per machine, but UI such as tray
> icons may be per-display. may be a (user,machine) service as well as
> per-machine service? Power manager, pulseaudio, network manager, etc.
> Some of these may go on system bus and simply be system services, as
> well.
> 

The assumption that all hardware devices are machine-global and either 
have to be shared by all sessions or allocated exclusively may not be 
true in the multi-seat case. Work on modeling that on the system bus 
(via consolekit) hasn't progressed very far, but singleton system 
services don't go together well with this.

> Research tasks that would be helpful
> ===
> 
> * Log into a default desktop session and list every name on dbus.
> Document what each one does and what whether it would ideally be
> per-user or per-display or per-homedir or per-machine. Document what
> would ideally happen with su and sudo and etc.
> 
> * What do users actually expect in various cases. Unfortunately I
> think the expectations may be contradictory. But map out the
> user-visible scenarios much better.
> 

Regards

- Jörg

-- 
Joerg Barfurth
Software Engineer        mailto:joerg.barfurth at sun.com
Desktop Technology       http://blogs.sun.com/joergb/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/vdi/

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Jürgen Kunz