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

[Alan McKinnon]

On 10/02/2014 18: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.

I don't sync as user alan, I let root start it then drop provs to user
portage. But the necessary permissions must work the same way regardless

>
> User is in the portage group:
>
> $ whoami
> stroller
> $ groups stroller
> wheel audio video portage cron users
> $

that's correct

>
> 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/
> $

<sigh>

Once again clueless morons on the forums throwing shit at the wall and
hoping some sticks. You correctly spotted this has nothing whatsoever to
do with /var/tmp (where emerge builds stuff) but with the tree itself,
rsync modifies the local copy of the tree directly.

>
>
> 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.

Those features are correct, that's what I have.

All files and dirs in my tree are set to portage:portage
All dirs have permissions 2775
All files have permissions 664

It's been this way for me for years without touching any settings; I
just searched for some config or a cron that runs chmod/chown on the
whole tree and found nothing. So I assume emerge is setting the
permissions itself.

However, a normal user can't chown a file, so you'll have to do these
first steps as root:

chown -R stroller:portage /usr/portage
find /usr/portage -type d -exec chmod 2775 {} \;
find /usr/portage -type f -exec chmod 664 {} \;

Thereafter sync as yourself, and the state should be maintained. rsync
will create new files in the tree as owned by you and you have
permission to chmod things so the group w perm should persist on everything.

If permissions don't persist then I'll have to hunt deeper here to find
my magic from years ago :-)


That *should* take care of emerge --sync.
I'm not too sure about eix-update though, we might have to do some more
fiddling in eix's data dir. make that phase 2 :-)


-- 
Alan McKinnon
alan.mckinnon@×××××.com