Re: [Ksummit-discuss] [TOPIC] Services needed from kernel.org

[Andy Lutomirski <luto@amacapital.net>]

On Wed, May 21, 2014 at 10:17 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/20/2014 05:40 PM, Konstantin Ryabitsev wrote:
>> On 20/05/14 06:53 PM, josh@joshtriplett.org wrote:
>>> How feasible is it to support git hooks that want to construct
>>> and send (significant volumes of) email, while retaining the
>>> security and sandboxing currently being applied to git
>>> repositories?
>>
>> It's feasible, but I can't make this a free-for-all, for obvious
>> reasons. :) With gitolite, hooks execute as the same user "git"
>> and therefore any code running inside a hook has unfettered access
>> to all git repositories regardless of in-gitolite repository
>> permissions.
>>
>> What we can do is have a peer-reviewed collection of "blessed"
>> hooks available to developers. Not being a kernel dev myself, I'm
>> not the one to put such a collection together, though -- I'm not
>> even sure if such a cookie-cutter approach would be suitable.
>>
>> I guess what I'm really trying to say is that I'd rather avoid
>> having to continuously review code written by people to whom "you
>> write perl like it's C" is a compliment. ;) If we can get by with a
>> handful of standard hooks, I'm for it, though.
>>
>
> Hmm... I resemble that remark.
>
> That being said, there is no fundamental reason that email generator
> have to be run on the master copy.  It can be run on an entirely
> different box, which doesn't even need any kind of privileged access
> to the machinery; this is how the tip-bot runs: it is just a "regular
> puller" of the tip tree, using the publicly accessible git port.  This
> does add some latency, but has the advantage that it sends out the
> emails once the commits are actually visible to general users upstream.
>
> Generalizing the tip-bot is probably not that hard.  I already use
> variants of it for multiple projects.  It does have a *lot* of
> configuration options, though, some of which are in the form of
> scripts.  This pretty much means that in its current form it is
> equivalent to a shell account and would have to be sandboxed accordingly.
>

There *must* be a sensible way to construct a sandbox these days.
Some combination of user namespaces, seccomp, and maybe even a VM
should be quite secure and even fairly easy to use.  Not to mention
that various scripting languages should have viable sandbox modes.

I'm sort of working on a userns-based general-purpose sandbox.  Maybe
I'll have something usable to play with at the kernel summit.

--Andy