From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 43057138CF8 for ; Tue, 11 Feb 2014 02:50:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9671DE0DC5; Tue, 11 Feb 2014 02:50:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 88A02E0D80 for ; Tue, 11 Feb 2014 02:50:32 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 5148D33F8FD for ; Tue, 11 Feb 2014 02:50:31 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so3553507wib.11 for ; Mon, 10 Feb 2014 18:50:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Sd5O6Z5qQ520cgCXvwVy1FUDngLtDFHnQrwPLzDQAQ8=; b=OTcpXMWefuMjM55mzjTvDAExZL4jNotmmjhDSO2XYNai/aQc6CiC/pV2BMePy5MII/ 58wzD+EY+c92axT2llQonTuGXozRnqtzYdby5V0WN0hT9d/9nBxoq91LC3HJ4WVMkt09 bVdu7QH2dOx4iBuBXbPFIH772yYRa0PcV27jY6tQI5wdtw3jf1nzpuA9nrP48dPRWEfD VvWLdUdjGPMaY4ViuYoQ/Kb0TbnyGK4jCY1peJ7OvRz/Pv3b92Mb3ZNnmjF10RjW98cj 33Lt5zX1SbWB86h6aD/JYweyLxt0aBwt2tD2KvRzG31s+fRQ1c2SYOG5iYQo5SByCoto qT3A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.194.6.8 with SMTP id w8mr24732025wjw.16.1392087028636; Mon, 10 Feb 2014 18:50:28 -0800 (PST) Received: by 10.194.162.229 with HTTP; Mon, 10 Feb 2014 18:50:28 -0800 (PST) In-Reply-To: <20140211012302.GA20423@waltdnes.org> References: <197AEEF5-2BA3-43BF-944E-A5C4230D4CFB@stellar.eclipse.co.uk> <20140210190344.GB17128@waltdnes.org> <52F92894.2050809@gmail.com> <52F95C7A.6010903@fastmail.co.uk> <20140210235755.GA19782@waltdnes.org> <52F96EBB.2060703@fastmail.co.uk> <20140211012302.GA20423@waltdnes.org> Date: Mon, 10 Feb 2014 21:50:28 -0500 Message-ID: Subject: Re: [gentoo-user] User eix-sync permissions problem From: Mike Gilbert To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 455a4ce3-4219-4406-8bd2-099a002ba9be X-Archives-Hash: be3aea110ef5bab0ce61a81f36610b49 On Mon, Feb 10, 2014 at 8:23 PM, Walter Dnes wrote: > On Tue, Feb 11, 2014 at 12:28:43AM +0000, Kerin Millar wrote >> On 10/02/2014 23:57, Walter Dnes wrote: >> > >> > What's the point, if you still have to run as root (or su or sudo) for >> > the emerge update process? >> >> It's the principle of least privilege. Is there any specific reason for >> portage to fork and exec rsync as root? Is rsync sandboxed? Should rsync >> have unfettered read/write access to all mounted filesystems? Can it be >> guaranteed that rsync hasn't been compromised? Can it be guaranteed that >> PORTAGE_RSYNC_OPTS will contain safe options at all times? >> >> The answer to all of these questions is "no". Basically, the combination >> of usersync and non-root ownership of PORTDIR hardens the process in a >> sensible way while conferring no disadvantage. > > If /usr/portage is owned by portage:portage, then wouldn't a user > (member of portage) be able to do mischief by tweaking ebuilds? E.g. > modify an ebuild to point to a tarball located on a usb stick, at > http://127.0.0.1/media/sdc1/my_tarball.tgz. This would allow a local > user to supply code that gets built and then installed in /usr/bin, or > /sbin, etc. > Don't add untrusted users to the portage group.