unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Qiantan Hong <qhong@mit.edu>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
	"Mattias Engdegård" <mattiase@acm.org>
Subject: Re: Prototype of object capability in Emacs
Date: Sat, 19 Feb 2022 16:55:50 -0500	[thread overview]
Message-ID: <jwv1qzyttv4.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <9069C6C8-B901-4F7C-B950-168AFDD119C6@mit.edu> (Qiantan Hong's message of "Thu, 16 Sep 2021 23:09:22 +0000")

> The way it works: ocaps-make-world makes a “powerless” isolated object graph
> (except initially passed in capability). 
> ocaps-import takes an object from ambient environment, and remove any capability
> not presented in the world bound to special variable ocaps-world.

I don't quite understand where are the capabilities in your system.
Maybe it's just a question of vocabulary.
For me a capability is bit like a pointer, and I need to provide it
whenever I want to do a particular operation which requires special
authorization, as evidence that I have the right to perform it.

AFAICT, what your package does is something more like what I'd call
a container.

A big problem with the approach you're following is that it's very
difficult to make sure the container doesn't leak.

E.g. providing access to the `current-global-map` function would already
end up giving access directly or indirectly to a vast array of functions
from the main obarray.

Something along these lines might be appropriate for insecure
containers, designed to avoid accidentally stepping on each other's toes
(maybe for concurrency purposes, for example), but if the purpose is to
run potentially dangerous code, I wouldn't ... trust it.


        Stefan




      parent reply	other threads:[~2022-02-19 21:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16 23:09 Prototype of object capability in Emacs Qiantan Hong
2021-09-17  1:14 ` dick
2022-02-19 21:55 ` Stefan Monnier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv1qzyttv4.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=mattiase@acm.org \
    --cc=qhong@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).