bug#45198: 28.0.50; Sandbox mode

["Mattias Engdegård" <mattiase@acm.org>]

17 apr. 2021 kl. 17.44 skrev Philipp <p.stephani2@gmail.com>:

> I think it would be better to first implement the mechanism and not the high-level `sandbox-enter' function

Sorry, there's a misunderstanding here -- it's just a name (and not meant to be a high-level function). I've given it a more platform-specific name. It is not meant to be a general interface to which any thing else has to conform.

Whether it should use --darwin-sandbox instead of --eval "(darwin-sandbox '(\"DIR\"))" is not very important at this point. It's not intended for general use in any case (and the doc strings now make this clear).

In particular, we do not benefit from artificially restricting the macOS sandboxing until we know what is needed. Nothing like a Lisp interface for experimentation!

> As we gain more experience with these sandboxing mechanisms, we can look at relaxing these restrictions, but I think initially we should be conservative.

I take the opposite view, but our goals are the same and we will converge.

> Is there any documentation you could refer to, even only an unofficial one?

Well, I dug up some web links that will be gone tomorrow...

> This needs to somehow document what PROFILE is.

You are right; elaborated.

>> +Already open descriptors can be used freely. */)
> 
> What does this mean?  Emacs doesn't really expose file descriptors to users.

It sort of does (in the form of processes), but there could also be descriptors not directly exposed. It would be incomplete not to mention the possibility. It looks like the seccomp filter generator uses the same policy, treating descriptors as capabilities.

> Missing CHECK_STRING (profile).

Thanks! Fixed.