Access control in Emacs?

[Qiantan Hong <qhong@mit.edu>]

As I’m experimenting making Emacs a collaborative “OS” (using crdt.el),
I inevitably encountered this classical OS question.
I’m adding more powerful features to crdt.el including buffer local variable
synchronizations and arbitrary remote command/function call,
however, it seems like they need to be accompanied by some access control
mechanism to be used “reasonably safely”.

Now I’m not sure about how to achieve that, there’re several ways I can see:
1. Really makes Emacs a multi-user OS. Add access control checks to 
all essential C primitives (which check against a current-user dynamic variable).
I don’t know how hard or intrusive it is. Does it worth it?

2. Another obvious thing I can do without touching massive amount of C code
is to add advice to interesting functions/primitives from Elisp side.

However I think this is bad security design comparing to 1 because it can
possibly open lots of loop holes, especially privilege promotion.
Suppose we don’t want Ben Bitdiddle to read our FS, we may add an
advice to insert-file-contents that check against an ACL (which excludes Ben).
However, if Ben has access to some other Lisp command that call some
C function that in turn calls insert-file-contents from C, the advice is never
invoked and this is easy privilege promotion.
We can only wish that we wrote a set of access control rules that have some
“closure” property, however given that lots of Emacs command are complex
and “intelligent”, I don’t think this is manageable.

I’m also not sure if extensive usage of advices is bad in a package supposedly
providing some fundamental feature.
I’m current using lots of advice already, to create “mock” buffer process object
that proxy I/O to a process on remote Emacs.

3. Or we can claim access control is for suckers. Trust your friends.

Thoughts?


Best,
Qiantan