Re: [gentoo-user] User eix-sync permissions problem

[Kerin Millar <kerframil@fastmail.co.uk>]

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