[RFC] Input design

[Daniel Stone]

Hi,

On Fri, Apr 20, 2007 at 04:16:58PM -0400, David Zeuthen wrote:
> On Thu, 2007-04-19 at 16:16 +0000, an Daniel Stone wrote:
> >  * Too much onus on the client
> >    Right now, we rely on an intelligent config client to get things
> >    done: you cannot simply have the server add all devices, or do
> >    something otherwise sensible.  This, IMO, is a big mark against us.
> 
> I can see why some people object to this. Still, I think an intelligent
> client is what most of the desktop projects (e.g. GNOME, KDE) wants to
> do - your thoughts on that?

Intelligent clients should absolutely be possible.  Anything which
blocks the creation of intelligent config clients is, IMO, dumb.

> (Just because I have this point of view doesn't mean I object to it
> being easy to use dumb clients or have the server do _some_
> autoconfiguration if that's what the user wants.)

Right.  For a few usecases (embedded/consumer devices in particular, as
well as minimal systems, LTSP-type setups, et al, not to mention systems
which are merely misconfigured or incomplete -- it's kind of hard to fix
that without input), we really want the server to be able to bring up
our devices.

If people want complexity, they can install a smart client.  If they
just want every device added, they can go with the server, or a really
dumb client.

Consider this analagous to xcompmgr -a vs. client-side compositing (as
well as no compositing at all), and to xrandr: you don't _need_ the
client tool.  If you want to do various complex setups, you can use one,
but by default, the server will attempt to DTRT for you.

> for rebuttal and also surrounding messages. Anyway, I don't think it's
> useful to rehash that discussion, at least not right now. It's more an
> implementation detail at this point I think...

On this we agree. :)

> >  * Security issues not even solved properly
> >    Right now, we need someone to write a D-Bus authentication plugin to
> >    map X servers to users, in order to come up with a sensible security
> >    policy.  Plus, MPX kind of blows this out of the water.
> 
> There's things like ConsoleKit that is already shipped with Fedora 7;
> I've copied some docs here for consideration
> 
>  http://people.freedesktop.org/~david/ConsoleKit.html

Thanks, I'll have a read through this.  My point was that it's not a
magic bullet for these kind of issues out of the box.

> > Here's the proposed new approach:
> >   * More server-centric configuration
> >     The server should at least be aware of which input devices are
> >     around it.  We can do this by adding HAL support to the server, and
> >     having it enumerate input devices via HAL.  This way, it always
> >     keeps a list of active input devices, and enabling them is just one
> >     step away from enumerating.  This provides for an xcompmgr -a type
> >     situation where the server can just DTRT for us.
> 
> Adding HAL support to the server means it needs to talk to HAL - this
> can only be done via D-Bus (the system bus specifically) so your
> complaints about libdbus may apply here. It's true, however, that
> there's a C library, libhal, that does this for you (via libdbus) and it
> checks everything (or tries to) to make sure it doesn't send garbage to
> libdbus. And this works fine.

Sure, but if libdbus is effectively an implementation detail of libhal,
then that's not something I'm bothered with, as you say.

> (As the maintainer of HAL, I usually tell people _not_ to use libhal; I
> tell them to use native bindings (glib, Qt, Mono, Java, Python,
> whatever) for D-Bus instead. For the X server, I don't know; I guess if
> using libhal makes your life easier (and you don't mind blocking calls),
> then why not. But if it was me, I'd use libdbus directly and just make
> sure my code isn't buggy.)

For us, our native binding is libdbus.  GLib is unacceptable due to the
whole abort()-on-malloc()-failure thing, and for obvious reasons we're
not about to start requiring Qt/C++, Mono/C#, Java, or Python.  So we're
stuck with the low-level lib (which no-one is ever supposed to use, but
we lack for alternatives), and its incredibly awkward API.

> >   * Move from D-Bus back to wire protocol
> 
> For the record, whether you use D-Bus or X protocol to do this both
> works as long as you can get the information you need about the client
> (e.g. uid, pid whatever) to make a security decision. It's not like I'm
> religiously attached to D-Bus; I just don't think your complaints about
> libdbus are valid.

Sure.  The benefit here isn't in getting rid of D-Bus, but in reducing
the number of client/server interfaces from two to one.  I'm not
convinced that the benefits brought by doing things out-of-band outweigh
the downsides of making sure everyone has D-Bus, requiring relatively
complex setups to manage it from a remote machine, and doubling the
number of communication channels that need to be doubled and deal with
authentication.

(i.e., I was wrong.)

> >     So, if we have a list of devices (optionally filtered by the admin;
> >     we'll have to provide some mechanism of filtering the list), our
> >     interaction with the client moves from 'add/remove this device' to
> >     'enable/disable' this device.  This is a relatively safe operation:
> >     HAL won't let us trash someone's partition table by writing the PS/2
> >     init sequence to /dev/hda.  Multi-user issues will require a
> >     security policy; this should probably be dealt with via the
> >     server-side security framework.  Right now, we already allow random
> >     users to steal other peoples' pointers with MPX, so that issue needs
> >     to be solved through the security framework anyway.
> 
> Btw, I don't see why it's useful to let the server keep this list; I'd
> just stick it in a library and let the client use it; I mean, what
> really is the big win between
> 
>  1) client using X protocol to enumerate devices AND select device; vs.
> 
>  2) client using some library to enumerate devices AND then use X
>     protocol to select device
> 
> Maybe there's something I don't get?

3) Server adds all input devices in the absence of a client, is the
killer feature here.  I don't really want to have to run a full config
client on the N800, and I'm pretty sure quite a number of others don't
want to, either.

> > I think we can do this reasonably quickly, and once that's settled down,
> > we can start shoving the 1.3.99.x releases out.
> > 
> > Questions? Opinions?
> 
> The ideas Jon (ConsoleKit author) and myself have for multi-user (e.g.
> fast-user-switching and multi-seat) might be interesting to review in
> this context. Allow me to list them
> 
>  1. HAL will know about what devices are attached to what seats
> 
>  2. ConsoleKit knows about what sessions belongs to what seats and
>     whether they are active or inactive; what /dev/tty device, what
>     X server and so on.
> 
>  3. HAL maintains ACL's on devices; whether a user get an ACL depends
>     on security policy; one such security policy is to grant access
>     to a device only if a user is in an active session that is local to
>     the seat that the session goes on at.
> 
>     So if you fast-user-switch away from a session, the user owning that
>     session will get his ACL removed from one or more device files.
> 
>     (In the future when Linux gains revoke() we will also revoke access
>     to devices; e.g. do more than just remove user from the ACL)

All of the above are certainly useful.

> My point really is that, security policy wise, when a user is requesting
> an X input device to be added to the server, then 
> 
>  1. X.org checks it's really an input device - you need to do this
>     check anyway and it's probably sufficient just checking major/minor
>     numbers

I'm not overly interested in dealing with the platform specifics, to be
honest.  I'd rather just check for an input capability.

>  3. Keep in mind that access to the device may be revoked at any point
>     in the future for the user that added the device; Since the server
>     (currently) runs as root, perhaps that means you want to run your X
>     input driver in a child process with  the uid of the user that added
>     the device... and then handle ENXIO or SIGBUS [1]. 

We're not going down the child user path, nor are we going to strongly
tie users and servers (see, e.g. MPX, which gives you one display for
multiple seats; you might say ConsoleKit here, but think of display
walls and shared collaborative systems).

We can catch the signals and just shut down the device.  That's not a
problem.

> So I guess I'm saying that it would be appropriate if the X server,
> instead of X inventing it's own security access scheme, just uses access
> checks on device nodes as the security check whether a user should be
> allowed to add/remove a device.

I have no intention of encoding any more complex policy than the above
in the server.  If the admin wants to specifically develop a reasonably
involved policy, far be it from me to stop them.  Ditto HAL/ConsoleKit
passing me a device list dependent on what the current seat has access
to, or whatever.

Thanks for your, er, input.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070421/6b6fb731/attachment.pgp>