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 85291138CF8 for ; Tue, 11 Feb 2014 01:04:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B9FDCE0D7F; Tue, 11 Feb 2014 01:03:58 +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 A92AAE0D59 for ; Tue, 11 Feb 2014 01:03:57 +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 B09D72102C for ; Mon, 10 Feb 2014 20:03:49 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 10 Feb 2014 20:03:49 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.co.uk; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=BaFaVT+mQPvsf47XqiG7TzdpKBE=; b=g5bCW/I8UM697fGszblV0UADlZa6 RcSuWNSeaTKhgDpz6ovLVd2mY3x6DHQEw6lM6jDrTMs57YZ5uDw5vn38tAR2JoJC p6jHw/H7yB+keXllf27pGggXU+0wPFDI71VRvi9XnRpx5FyaJHiskOhLYuLxsiXj sZ7nBVUpgRU7Hno= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=BaFaVT+mQPvsf47XqiG7Tz dpKBE=; b=FCpOIkVWeVwhXWr6ArYVFE/yOaAVQpDNaDgckefviBp9e1VHVInTBX sw6Br+kvKawUO/RxkobKu0Wtwo4zw4maoE+9ZBaKa/O+VTzb5/kjlBVfYfyPxwlf JZtf+YeFnE0Sy+lqZwvELnxik7H/CNKffHE3WFYsvU05vJPLuOV3M= X-Sasl-enc: DmeCRygOTxmSjRbm5u9d8meeS8QKII9I6G5/C9n0P/gc 1392080628 Received: from [192.168.1.100] (unknown [77.101.146.254]) by mail.messagingengine.com (Postfix) with ESMTPA id D1B06C00005 for ; Mon, 10 Feb 2014 20:03:48 -0500 (EST) Message-ID: <52F976F1.1080201@fastmail.co.uk> Date: Tue, 11 Feb 2014 01:03:45 +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> <52F936CF.4060808@fastmail.co.uk> In-Reply-To: <52F936CF.4060808@fastmail.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 028b41c4-5bf8-4451-90ce-e2ffdb1ee622 X-Archives-Hash: 164a4361536f7a13d8ad2b996777d92a On 10/02/2014 20:30, Kerin Millar wrote: > On 10/02/2014 16:05, Stroller wrote: >> Hello all, >> >> I'm a little bit rusty, but my recollection is that I should be able >> to perform `eix-sync` (or `emerge --sync`?) as a user to synchronise >> my local copy of the portage tree with Gentoo's master portage tree. >> >> User is in the portage group: >> >> $ whoami >> stroller >> $ groups stroller >> wheel audio video portage cron users >> $ >> >> Yet I get these permissons denied errors: >> >> $ eix-sync >> * Running emerge --sync >>>>> Synchronization of repository 'gentoo' located in '/usr/portage'... >>>>> Starting rsync with rsync://91.186.30.235/gentoo-portage... >>>>> Checking server timestamp … >> … >> receiving incremental file list >> rsync: delete_file: >> unlink(app-accessibility/caribou/caribou-0.4.12.ebuild) failed: >> Permission denied (13) >> rsync: delete_file: >> unlink(app-accessibility/emacspeak/files/emacspeak-33.0-respect-ldflags.patch) >> failed: Permission denied (13) >> rsync: delete_file: >> unlink(app-accessibility/emacspeak/files/emacspeak-33.0-greader-garbage.patch) >> failed: Permission denied (13) >> >> (full output attached) >> >> >> Googling the problem I see a bunch of Gentoo Forums posts talking >> about changing at random the permissions of /var/tmp/ or >> /var/tmp/portage/, but no rationale is given, and I don't think this >> is the cause: >> >> $ emerge --info | grep -i tmpdir >> PORTAGE_TMPDIR="/var/tmp" >> $ ls -ld /var/tmp/ >> drwxrwxrwt 3 root root 4096 Feb 5 13:47 /var/tmp/ >> $ ls -ld /var/tmp/portage/ >> drwxrwxr-x 5 portage portage 4096 Feb 5 12:32 /var/tmp/portage/ >> $ >> >> >> More likely seems to be the permissions of /usr/portage/: >> >> $ ls -ld /usr/portage/ >> drwxr-xr-x 167 portage portage 4096 Jan 5 02:31 /usr/portage/ >> $ ls -ld /usr/portage/app-accessibility/caribou/caribou*.ebuild >> -rw-r--r-- 1 portage portage 2432 Aug 25 23:11 >> /usr/portage/app-accessibility/caribou/caribou-0.4.12.ebuild >> -rw-r--r-- 1 portage portage 2431 Dec 8 18:01 >> /usr/portage/app-accessibility/caribou/caribou-0.4.13.ebuild >> $ >> >> This would seem to allow portage itself to synchronise the Portage >> tree, but not members of the portage group. >> >> >> I am able to run `emerge --sync` as root, but it doesn't solve the >> solve the problem - next time I run `eix-sync` as user, I'm >> permissions denied, again. >> >> Shouldn't a sync reset the permissions of the portage tree to be correct? >> >> >> `emerge --info | grep -i feature` shows that FEATURES="userfetch >> userpriv usersandbox usersync" (and some others - see attached) are set. >> >> I can reproduce this on a second AMD64 machine, both are running >> portage-2.2.7. >> >> Thanks in advance for any help, advice or suggestions you can offer, > > This should work:- > > PORTAGE_RSYNC_EXTRA_OPTS="--chmod=g+w" > Please excuse the reply-to-self but this issue piqued my interest and I think that I now have a better answer. 1) chown -R portage:portage "$(portageq envvar PORTDIR)" 2) find "$(portageq envvar PORTDIR)" -type f -exec chmod 0664 {} + 3) find "$(portageq envvar PORTDIR)" -type d -exec chmod 2775 {} + 4) Add to make.conf: PORTAGE_RSYNC_EXTRA_OPTS="--no-p --chmod=g+w" 5) Sync as yourself thereafter (as root should work equally well!) The reason for using --no-p is to prevent rsync from spewing errors about not being able to set the file modes when you sync as a regular user. These errors don't necessarily indicate that a file cannot be written - merely that the mode couldn't be set. Such errors would occur because, though you are in the portage group, you are not necessarily the owner of the files that rsync is in the course of modifying. However, as long as the g+w bit is set for all newly created files/directories, I would posit that it doesn't actually matter. Instead, you can simply avoid synchronizing the permissions with the remote. Finally, having the setgid bit set on directories ensures that files written out by your user beneath PORTDIR will always inherit the portage group rather than whatever your primary group happens to be. I am still in the course of testing this out but I am fairly certain that it will work. --Kerin