[Webkit-unassigned] [Bug 188568] [GTK][WPE] Implement subprocess sandboxing

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 18 06:31:49 PDT 2018


--- Comment #52 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Carlos Garcia Campos from comment #47)
> so writeArgumentsToMemory() is what the function does, right?

Certainly not. It's a file descriptor. I would say either writeArgumentsToFileDescriptor() or writeArgumentsToMemfd().

(In reply to Carlos Garcia Campos from comment #49)
> The web processes all have the same permissions so always share the same
> proxy, I don't *think* that is a problem.

It's not a problem. We don't want a proxy process running for every web process.

> > Source/WebKit/UIProcess/Launcher/glib/ProcessLauncherGLib.cpp:66
> > +    return syscall(__NR_memfd_create, name, flags);
> Is this always available? doesn't it depend on a kernel version or libc?

It's added in glibc 2.27, which too recent. That's why it's better to call syscall() than to use it via glibc.

It occurs to me that Red Hat will probably be running this code with the 3.10 kernel, but you handle that by calling g_error() if memfd_create() fails, which seems fine to me. People using ancient kernels should just disable the sandbox.

(In reply to Patrick Griffis from comment #50)
> Yes it is a runtime dep. The value of it being a build time check is we get
> an absolute path and we get to check the version (0.3.1 isn't released, so
> it would commonly fail atm).

The risk is that we need to make sure cross-compiling works. I guess the check is fine, since bwrap will probably be installed in the same place on both host and target?

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180918/5b8b4faa/attachment.html>

More information about the webkit-unassigned mailing list