Skip to content

Rethinking REIS

The plan with REIS (Restrictions for EIS, also: 🍚, oh, the hilarity) is that it's possible to restrict what a client can do. The use-case here is a portal that creates/obtains the socket to the EIS implementation, then applies some restrictions (e.g. a client may not be allowed touch events or capture keyboard events). The socket is passed to the client, then things go on their merry way.

The restrictions are transparent to the client, it doesn't know about them, cannot know about them. If e.g. touch is restricted, there simply will never be a touch capability.

The implementation is... a bit messy. The idea was that there are ConfigureFoo messages to configure those bits ("configure" is used for anything pre-connect). libreis is the simple library/API for the portal since it doesn't need to care about anything in libei itself. libei doesn't implement Configure*, but obv. that's the library only.

Right now:

  • ConfigureName can be sent once and will be silently ignored after that. If Connect supplies a name, the name will be silently ignored if a name is already set.
  • ConfigureCapabilities can be sent multiple times and reduces the capabilites mask to the intersection of all masks (needed bugfix in !117 (merged)).
  • Properties can be set by a REIS client with custom permissions, so a client can set a property that's invisible or read-only. The properties set by the portal POCs are ei.application.cmdline, ei.application.pid.

The biggest issues are:

  • There is no version negotiation, if we ever add new messages it'll be impossible for the portal to know ahead of time whether those are accepted. It gets worse if we ever have two processes using REIS and they support different versions.
  • REIS allows to send multiple Configure messages, possibly by different processes that have access to the fd. This includes the client itself, there is no way to say "configuration done". This doesn't matter too much as long as restrictions are cumulative - currently they are.
  • There is some overlap with the more generic properties and Configure messages. ConfigureName (and the name in Connect) could easily be changed to a read-only property ei.application.name. However, properties don't have protocol versioning and we cannot know whether an EIS implementation knows that ei.application.name is special. Also, properties can currently mess up the client, see #23 (closed).

So right now, I'm thinking: we need ConfigureStart and ConfigureFinish to make configuration a versioned transaction. The portal starts, configures, is done and only then can pass the fd to the next layer. Which can then do configuration on top, with its own version. Once the client connects, we can ignore any Configure* transaction.

Alternatively, but it gets a lot more complicated: a control socket. The portal obtains a separate socket in addition to the libei fds. That socket can be used for REIS messages only, after some exchange of unique identifiers so EIS knows which client is being controlled. For what we'll likely need, this seems like overkill and it makes nested configuration a lot harder.