From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DATE_IN_PAST_12_24, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from janus.prosalg.no ([213.236.139.1] helo=io.adm.prosalg.no) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15zfwb-0005r4-00 for gentoo-dev@gentoo.org; Fri, 02 Nov 2001 08:09:17 -0700 Received: from b223a.studby.ntnu.no ([129.241.126.223] helo=motvind) by io.adm.prosalg.no with asmtp (Exim 3.33 #1 (Debian)) id 15zfnC-0002Ir-00 for ; Fri, 02 Nov 2001 15:59:34 +0100 From: Karl Trygve Kalleberg To: gentoo-dev@gentoo.org Message-Id: <20011102170755.434fbea8.karltk@prosalg.no> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [gentoo-dev] Braindump wrt fakeroot and path sandboxing Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org X-Reply-To: karltk@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Fri Nov 2 08:10:02 2001 X-Original-Date: Fri, 2 Nov 2001 17:07:55 +0100 X-Archives-Salt: fcaa1ece-4735-41b4-9b20-48002a5c5fa3 X-Archives-Hash: 42fd81ca6dadb8a4b091b634ff88a7f8 Hi gang. I have looked into the innards of Subterfugue, and hacked together a short C program that captures syscalls from a child. While the program does not do anything with the captured arguments (attached), I do not think there will be a significant overhead associated with path sandboxing at all. The reason for this postulation is that a traced child running "find /" completes at the same time as a non-traced "find /". Only for installations that do extreme amounts of syscalls might we notice an overhead, and I really think "find /" is as syscall-intensive as we'll get during compilation and installation. If anybody else can prove me wrong on that one, now's the time. After adding the path sandboxing code, I will integrate the cut-down fakeroot that chouser (might have) finished, so we have a fairly secure and lean sandbox overall in which build processes can work happily. For those who're not up to date on this subject, the reason why we want a combination of subterfugue's SimplePathSandbox and fakeroot is that 1) We don't want ebuilds to write outside of ${S}, /tmp or ${D} 2) We really don't want to run the ebuilds as the real root, if we can fake it, hence fakeroot. (Fakeroot lets the ebuild think it runs as root; in practice this infers chown-privileges to a regular user). 3) We do not want to use subterfugue since it's too slow. Fakeroot seems to have some features that are overkill for this project, and at any rate, we really only want to do syscall tracing once. (The alternative would be a sandbox process that contained fakeroot that contained the ebuild...) Interested parties, please do some thinking on this. Oh, I will be away until Thursday, so you have plenty of time ;p Kind regards, Karl T