Re: Access control in Emacs?

[Qiantan Hong <qhong@mit.edu>]

> A multi-user OS exists, and it is called UNIX.  It would be hard to improve
> upon it.  What you seem to want is remote shell.  That also exists.  If port
> forwarding or a simple X11 connection is not slick enough, there is
> emacsclient.
I don’t think UNIX is a particularly good multi-user OS — the access control
model is arbitrary and coarse grain. There’re improvements like SELinux,
but a CLOS generic function in Elisp will do much better.

But that’s rather a tangent. There are things that UNIX doesn’t attempt to do,
e.g. the collaboration aspect. I think the root cause is that although UNIX manages
shared state arguably well, it uses such a low level byte-stream model such that only
very few operations on shared state make sense. E.g. two users simultaneously editing
the same file just doesn’t work (because UNIX doesn’t really know edit nor text, it knows
read/write raw bytes).

I see Emacs potentially a much better platform for collaboration than UNIX,
however I must point out there’s already a great challenge from proprietary software.
I heard people saying m$’s VSCode server and live share blow emacs tramp 
(and I suppose current state of crdt.el) "out of water”.
They can share autocompletion, tags, debugger… etc,
and I’ve heard that it’s a killer feature for mentoring and attracting freshmen.

UNIX apparently doesn’t help with the above.
Let’s consider jump-to-definition. crdt.el already have all the facility to make it happen,
one peer sends jump-to-definition remote call request (we have to allow this!),
after the server run it, it finds itself possibly in a different buffer 
(we have to allow create buffer and file access!),
then in the post-command state synchronization phase the server
add the newly created buffer into the shared session (we have to configure this!)
and tell client to go into this buffer.

If I assume we allow everything, it’s a matter of 20 lines for me to implement
it on top of current crdt.el. And in general Emacs can easily surpass VSCode
in all collaboration aspect just because we start with a much more powerful piece
Of single-user software.
However there's grave security question.

> Given the way Emacs is designed/structured this is a recipe for big
> gaping security holes.  It can be OK to allow such things for *very*
> specific cases (a few specific well understood variables), but even such
> a "whitelist" is a problem because it requires careful and
> long term maintenance.

I think for Emacs to catch-up/surpass proprietary solutions there has
to be an extensible way to add remote command/variables, ideally
each package hackers could just add a few annotations to make
their packages work over shared sessions.

In the worst case we just outsource security to underlying OS
(ask host to run inside containers etc) but that might be too coarse grain...