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
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 a
chroot
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 (Zumastor)
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
easy and
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
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 *
rinse
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
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
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
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.
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
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
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
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?
14 matches
Mail list logo
