Multiuser device support

[Darren Kenny]

Totally agree.

As Artem mentioned there needs to be some concept of a policy handler 
that enables devices to be allocated as, for example, system devices or 
session based devices, and so to elaborate a bit more...

A session could be defined as any of the following:

    * a console session (USB port on machine, internal CD-ROM, etc -
      similar to that of logindevperm)
    * a device that exists only for a given "remote" (yet processes are
      generally all running local) session - eg:
          o Sun Ray (where a device sitting on your desk has USB ports,
            but are visible as physical devices on the server system)
          o RDP client (if it's fully featured and in a similar fashion
            to Sun Ray allows a remote device to be seen to the local
            system).

So devices that are associated with sessions, eg. Mouse, USB Mass 
Storage, Digital Camera, etc. then such devices will need to allocated 
to a session, and only that session.

A system device then would be one that isn't specifically allocated to 
any give session, such as the hard-disks, the CPU, etc.

I would think that most devices would default to being system devices 
and as such don't need specific configuration to say that - and only 
non-system devices would then need to be specified somewhere (in pretty 
much the same way as logindevperm does, but better! ).

I am not sure how you could allocate devices to an XDMCP session, eg. 
where a user is connected to a server via XDMCP, but they got someone to 
insert a CD-ROM in for them  - who should see such an event? I would 
guess that if there is someone logged into the machines console, they 
should, but if not, then maybe all sessions would be notified (in this 
case the devices isn't specifically allocated to a session since there 
isn't one on the console.... ) Do you see what I mean?

This all lies in the domain of a policy setting mechanism - who sees 
what and when. So this is definately an area that should be highly 
configurable and possibly even totally replaceable (eg. plugin style) so 
that it can be as simple or as complex as a sys-admin desires. If it is 
also possible to have HAL use session-based D-BUS for session specific 
notifications then it would also provide a certain level of privacy in 
that area too, and while it's at it, enable applications to only see 
session based events unless they really want to see system based events, 
which they can do by connecting to the System D-BUS as well...

Just some of my thoughts on it...

Thanks,

Darren.



Jon Smirl wrote:

>On 8/2/05, Artem Kachitchkine <Artem.Kachitchkin at sun.com> wrote:
>  
>
>>OTOH, the separating of user sessions should probably be HAL's
>>responsibility. For instance, hotplug events from one user session
>>should not be visible to another. Our work is still very preliminary,
>>but we're leaning towards having per-session D-BUS instances, with HAL
>>presenting each session with a subset of Global Device List according to
>>the session-device assignment.
>>    
>>
>
>Something needs to sort this out. The hotplug events coming from an
>operator taking SCSI drives offline are of a completely different
>class than a user plugging in a mouse. You really shouldn't be able to
>see events for devices that you don't have permission to use.
>
>We need to start thinking multiuser now so that we don't end up with
>something that is completely single user centric.
>
>  
>
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal