[RFC] Input design
daniel at fooishbar.org
Fri Apr 20 16:46:46 PDT 2007
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
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
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
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
(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
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 .
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg