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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188568

--- Comment #53 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #52)
> (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().

Arguments are written to memory and the file descriptor to read that memory is returned, or am I wrong?

> (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.

Ok, go it. Should we use NeverDestroyed then?

> > > 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.

But I guess __NR_memfd_create needs to be defined somewhere?

> 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?

I don't know.

-- 
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/659526cd/attachment.html>