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 EB2D6138D01 for ; Tue, 11 Feb 2014 00:28:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0DD2E0D58; Tue, 11 Feb 2014 00:28:48 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AFF00E0D4C for ; Tue, 11 Feb 2014 00:28:47 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 49C1820C2A for ; Mon, 10 Feb 2014 19:28:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 10 Feb 2014 19:28:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=ecAAt16jRxb0AZ9BSSyaYgwSfXY=; b=IcgSnBzf+0mq95zz1lSDuu4TLF2o gfDa65bLHLPBv881TCQfZCNJJ6Whwi9N0pFeQHHUshSp3OSELkcs1hzhnrzafPXF mAdDV4svrleGTdusVu+G2MaFIJs2b/5n5LQxrAJO6Wjv11s56eu1dWsL+6teqCMG G95DkgWd1SgTxRU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=ecAAt16jRxb0AZ9BSSyaYg wSfXY=; b=qwRqJcN2+pNLyPRC5nb9QgIfq/lz2T/LYSjeqObb/e6koVsRDq/Xuw nsfLTZKLbbQxomk6DptY9al7TfIwv6khucvCAUxIFGcIp/huBwmQqHUhniAWb6HF delCJd5/OU82Fd9Puu6iY6G2cxZqzfM7OYAFl4iwS4soS5HSqQHlU= X-Sasl-enc: bCGQlRlYRvinCvlAMwcp+/6t1/v7iYeegxbhdvFdsv0L 1392078526 Received: from [192.168.1.100] (unknown [77.101.146.254]) by mail.messagingengine.com (Postfix) with ESMTPA id DAF87C007B1 for ; Mon, 10 Feb 2014 19:28:46 -0500 (EST) Message-ID: <52F96EBB.2060703@fastmail.co.uk> Date: Tue, 11 Feb 2014 00:28:43 +0000 From: Kerin Millar User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] User eix-sync permissions problem 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> In-Reply-To: <20140210235755.GA19782@waltdnes.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 413d5bb3-c03d-40c8-a243-e3a6336485ca X-Archives-Hash: 44b5327a44d12b00fedd9b5ebbbdcbc9 On 10/02/2014 23:57, Walter Dnes wrote: > On Mon, Feb 10, 2014 at 11:10:50PM +0000, Kerin Millar wrote > >> As mentioned in a few other posts, recent snapshots are portage:portage >> throughout so it's a done deal for new installations. > > How "recent"? Looking back into ~/Maildir/spam/cur/ I see that the > email file suffix changed from ".d531:2,S" to ".i660:2,S" on May 14th, > 2013 (i.e. the current machine "i660" was installed and pulling mail as > of that date). I do not know but I would assume that the snapshots have been constructed in this fashion since (at least) the point where usersync became a default feature, which was in portage-2.1.13. > >> Those who still have it owned by root can benefit from usersync >> simply by running: >> >> # chown -R portage:portage "$(portageq envvar PORTDIR)" >> >> There is no subsequent requirement not to invoke emerge --sync as root. > > 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. --Kerin