Ambroz wrote:
> The problem with your design right now is that you want to run the slave in
> some isolated environment and expect it to be secure. The build slave itself
> is a mission-critical process and putting it in a quarantine to run together
> with untrusted code allows malicious patches to
Dan Kegel wrote:
> So the slave can be in another real machine, another virtual machine, or
running as another user; anything as long as it can get read/write access to
its subdirectory of the shared directory.
The problem with your design right now is that you want to run the slave in
some iso
Ambroz wrote:
> I think I'll try getting a small Gentoo system to run in UML with a
> read-only root fs and make it boot as fast as possible. To try a patch, I
> would give it read access to the master Wine tree on the host, it would
> copy it to a writable temp folder and try it out. After it's fi
Francois Gouget wrote:
> This seems like an almost perfect task for a virtual machine:
> * set up you virtual machine to taste
> * take a snapshot
> * to test a patch, fire up the virtual machine
> * have it test the patch
> * after the test or when it times out, revert it to the snapshot *
ri
On Wed, Sep 10, 2008 at 5:02 AM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 10, 2008 at 4:37 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
>> This seems like an almost perfect task for a virtual machine:
Incidentally, I documented how to produce a really small vmware image
for Ubuntu at
h
On Wed, Sep 10, 2008 at 5:06 AM, Vit Hrachovy <[EMAIL PROTECTED]> wrote:
> I can see the way how to use pbuilder/pdebuild toolchain on dedicated user
> account in Debian to automate this in pretty safe and easy way.
>
> pbuilder uses fakeroot/chroot for this and its use is a nobrainer, hellish
> ea
On Wed, Sep 10, 2008 at 4:37 AM, Francois Gouget <[EMAIL PROTECTED]> wrote:
> This seems like an almost perfect task for a virtual machine:
> ... The main issue I see with
> this is that the OpenGL / DirectSound tests will not run on the real
> hardware (as usual)
I just came off a project (Zumast
Francois Gouget wrote:
> On Mon, 8 Sep 2008, Ambroz Bizjak wrote:
>
>> Hi,
>>
>> I've abandoned my chroot aproach to improving security in patchwatcher.
>> Instead I've implemented the ability to run untrusted code as a user
>> different than the one running patchwatcher. This is because creating
On Mon, 8 Sep 2008, Ambroz Bizjak wrote:
> Hi,
>
> I've abandoned my chroot aproach to improving security in patchwatcher.
> Instead I've implemented the ability to run untrusted code as a user
> different than the one running patchwatcher. This is because creating a
> chroot where Wine could be
On Mon, Sep 8, 2008 at 9:01 PM, Austin English <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 8, 2008 at 6:06 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
>> Interesting.One of my goals is to support Solaris and BSD;
>> have you tried your stuff there?
>
> What about OS X?
Yes, of course.
On Mon, Sep 8, 2008 at 6:06 PM, Dan Kegel <[EMAIL PROTECTED]> wrote:
> Interesting.One of my goals is to support Solaris and BSD;
> have you tried your stuff there?
>
What about OS X?
> Also, it's possible some of your changes won't be needed
> after the refactoring... I plan to run wine-slave as a different
> user anyway...
That doesn't solve much; although in may look clean, it is not secure. The
user should have a limited amount of resources to work with. Your way, for
exam
> Interesting.One of my goals is to support Solaris and BSD;
> have you tried your stuff there?
Not yet, but that stuff is pretty generic, so it shouldn't be hard to get
it to work.
> I'm surprised you had to give up on the chroot...
> I was planning on trying to run just wine-slave.sh in
> a
Interesting.One of my goals is to support Solaris and BSD;
have you tried your stuff there?
I'm currently refactoring patchwatcher.sh; I've pulled
the generic stuff out into libpatchwatcher.sh and
the wine-specific stuff into wine-slave.sh.
Your changes will fit nicely into wine-slave.sh, I ho
14 matches
Mail list logo
