[gentoo-user] User eix-sync permissions problem

[gentoo-user] User eix-sync permissions problem

[Stroller]

[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]

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,

Stroller.




[-- Attachment #2: emerge_sync_perms_prob.txt --]
[-- Type: text/plain, Size: 16854 bytes --]

$ 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 ...
Welcome to boobie.gentoo.org / rsync.gentoo.org

Server Address : 91.186.30.235
Contact Name   : mirror-admin@gentoo.org
Hardware       : 2 x Intel(R) Xeon(R) CPU 3050 @ 2.13GHz, 3958MB RAM
Sponsor        : EUKhost, Maidenhead, England

Please note: common gentoo-netiquette says you should not sync more
than once a day.  Users who abuse the rsync.gentoo.org rotation
may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Sun Apr  1 01:05:34 UTC 2012

receiving incremental file list
timestamp.chk

Number of files: 1
Number of files transferred: 1
Total file size: 32 bytes
Total transferred file size: 32 bytes
Literal data: 32 bytes
Matched data: 0 bytes
File list size: 27
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 98
Total bytes received: 620

sent 98 bytes  received 620 bytes  46.32 bytes/sec
total size is 32  speedup is 0.04
Welcome to boobie.gentoo.org / rsync.gentoo.org

Server Address : 91.186.30.235
Contact Name   : mirror-admin@gentoo.org
Hardware       : 2 x Intel(R) Xeon(R) CPU 3050 @ 2.13GHz, 3958MB RAM
Sponsor        : EUKhost, Maidenhead, England

Please note: common gentoo-netiquette says you should not sync more
than once a day.  Users who abuse the rsync.gentoo.org rotation
may be added to a temporary ban list.

MOTD autogenerated by update-rsync-motd on Sun Apr  1 01:05:34 UTC 2012

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)
cannot delete non-empty directory: app-accessibility/emacspeak/files
rsync: delete_file: unlink(app-accessibility/emacspeak/emacspeak-38.0.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-accessibility/emacspeak/emacspeak-33.0.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-accessibility/emacspeak/emacspeak-31.0.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-accessibility/emacspeak/emacspeak-30.0.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-accessibility/espeak/espeak-1.45.04.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/.ChangeLog.mxynAI" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/.Manifest.hctmMW" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/.brltty-5.0.ebuild.JRPnYa" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/files/.brltty-5.0-fix-ldflags.patch.eGZNap" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/files/.brltty-5.0-respect-AR.patch.eBEhnD" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/brltty/files/.brltty-5.0-udev.patch.VzyNzR" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/caribou/.ChangeLog.vY6oM5" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/caribou/.Manifest.9YpfZj" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/emacspeak/.ChangeLog.lKE8by" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/emacspeak/.Manifest.StEmpM" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/espeak/.ChangeLog.qnh7C0" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/espeak/.Manifest.5l0HRe" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-accessibility/espeak/.espeak-1.47.11-r1.ebuild.l9io6s" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-opencl/.ChangeLog.gdKSuH" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-opencl/.Manifest.zoXnTV" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-opencl/.eselect-opencl-1.1.0-r1.ebuild.dFMTha" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-php/.ChangeLog.A4KqGo" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-php/.Manifest.zlg14C" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-php/.eselect-php-0.7.1-r3.ebuild.9lsCtR" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-python/.ChangeLog.OEBeS5" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-python/.Manifest.9uBTgk" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-python/.eselect-python-20140125.ebuild.cP8AFy" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect-python/.eselect-python-99999999.ebuild.xqJl4M" failed: Permission denied (13)
rsync: delete_file: unlink(app-admin/sysstat/sysstat-10.2.1.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect/.ChangeLog.kRl3t1" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect/.Manifest.5mCXVf" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/eselect/.eselect-1.4.ebuild.OGD5nu" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/logcheck/.ChangeLog.I4JqQI" failed: Permission denied (13)
rsync: recv_generator: mkdir "/usr/portage/app-arch/bloscpack" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: mkstemp "/usr/portage/app-admin/logcheck/.Manifest.ZUw7iX" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/logcheck/.logcheck-1.3.16.ebuild.KjGPLb" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/mktwpol/.ChangeLog.Mtg1eq" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/mktwpol/.Manifest.8Z1gIE" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/mktwpol/.mktwpol-0.2.2.ebuild.Z2GybT" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/r10k/.ChangeLog.urRgG7" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/r10k/.Manifest.UJe2am" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/r10k/.r10k-1.1.3.ebuild.jIHPFA" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/setools/.ChangeLog.YnEHaP" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/setools/.Manifest.zSuAF3" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/setools/.setools-3.3.8-r4.ebuild.mYv1ai" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/sysstat/.ChangeLog.pQa1Gw" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/sysstat/.Manifest.0D8AeL" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/sysstat/.sysstat-10.2.1-r1.ebuild.hc8bMZ" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/webalizer/.ChangeLog.ePK3je" failed: Permission denied (13)
rsync: delete_file: unlink(app-backup/bacula/bacula-5.2.13-r1.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/webalizer/.Manifest.Wq2eTs" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-admin/webalizer/.webalizer-2.23.08.ebuild.mLnrsH" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/alien/.ChangeLog.5E4S1V" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/alien/.Manifest.aDuzBa" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/alien/.alien-8.89.ebuild.ze0Lbp" failed: Permission denied (13)
app-arch/bloscpack/
rsync: mkstemp "/usr/portage/app-arch/cpio/.ChangeLog.Qn71LD" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/cpio/.Manifest.YRg1mS" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/cpio/.cpio-2.11-r1.ebuild.CYR7X6" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/lz4/.ChangeLog.difwzl" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/lz4/.Manifest.SmhVaA" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/lz4/.lz4-0_p106-r1.ebuild.knGwMO" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/lz4/files/.lz4-0_p106-cflags.patch.1q68n3" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/tar/.ChangeLog.AnfA0h" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/tar/.Manifest.8jA2Dw" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/tar/.tar-1.27.1-r1.ebuild.wF6whL" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/unrar/.ChangeLog.AlIuVZ" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/unrar/.Manifest.ZPygAe" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-arch/unrar/.unrar-5.0.14.ebuild.yO9hft" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-backup/bacula/.ChangeLog.zeAEUH" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-backup/bacula/.Manifest.elusCW" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-backup/bacula/.bacula-5.2.13-r2.ebuild.fEFQkb" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-cdr/qpxtool/.ChangeLog.0PKn6p" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-cdr/qpxtool/.Manifest.FoLYRE" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-cdr/qpxtool/.qpxtool-0.7.2.ebuild.gptBDT" failed: Permission denied (13)
rsync: recv_generator: mkdir "/usr/portage/app-crypt/ssdeep" failed: Permission denied (13)
*** Skipping any contents from this failed directory ***
rsync: mkstemp "/usr/portage/app-crypt/gnupg/.ChangeLog.qxmhr8" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/gnupg/.Manifest.YAcvin" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/gnupg/.gnupg-1.4.16.ebuild.PxVX9B" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/scrypt/.ChangeLog.FMsg2Q" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/scrypt/.Manifest.xkHzU5" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/scrypt/.metadata.xml.tjiTMk" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/seahorse/.ChangeLog.3uVdFz" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/seahorse/.Manifest.Pru7xO" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/seahorse/.seahorse-3.10.2.ebuild.rLe9q3" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/signing-party/.ChangeLog.KB1pki" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/signing-party/.Manifest.QhwOdx" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-crypt/signing-party/.signing-party-1.1.5.ebuild.25mq7L" failed: Permission denied (13)
app-crypt/ssdeep/
rsync: mkstemp "/usr/portage/app-dicts/myspell-de-alt/.ChangeLog.Mned50" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/myspell-de-alt/.Manifest.Rq502f" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/myspell-de-alt/.myspell-de-alt-20120929.ebuild.QolP0u" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/myspell-pt/.ChangeLog.YILGYJ" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/myspell-pt/.Manifest.kuGyWY" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/myspell-pt/.myspell-pt-20120420.ebuild.5x2qUd" failed: Permission denied (13)
rsync: delete_file: unlink(app-doc/gnucash-docs/gnucash-docs-2.4.1.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/verbiste/.ChangeLog.rr3yXs" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/verbiste/.Manifest.mtyI0H" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-dicts/verbiste/.verbiste-0.1.38.ebuild.y1sS3W" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/csound-manual/.ChangeLog.Su556b" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/csound-manual/.Manifest.b3Vjar" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/csound-manual/.csound-manual-6.01.ebuild.buSCeG" failed: Permission denied (13)
rsync: delete_file: unlink(app-editors/latexila/latexila-2.8.1.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-editors/latexila/latexila-2.6.2.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/gnucash-docs/.ChangeLog.hNGIjV" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/gnucash-docs/.Manifest.Q8zPoa" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/gnucash-docs/.gnucash-docs-2.6.1.ebuild.YfNWtp" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/linuxfromscratch/.ChangeLog.yxNbzE" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/linuxfromscratch/.Manifest.pNURET" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/linuxfromscratch/.linuxfromscratch-7.2.ebuild.Uz2yK8" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-doc/linuxfromscratch/.linuxfromscratch-7.4.ebuild.PItgQn" failed: Permission denied (13)
rsync: delete_file: unlink(app-editors/scite/scite-3.3.6.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-editors/scite/scite-3.3.4.ebuild) failed: Permission denied (13)
rsync: delete_file: unlink(app-editors/scite/scite-3.3.3.ebuild) failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/emacs-vcs/.ChangeLog.abGkZC" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/emacs-vcs/.Manifest.Dy6r9R" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/emacs-vcs/.emacs-vcs-24.3.50_pre20140131.ebuild.P3mPj7" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/focuswriter/.ChangeLog.pFnoum" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/focuswriter/.Manifest.lKYlFB" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/focuswriter/.focuswriter-1.4.4.ebuild.xErkQQ" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gedit/.ChangeLog.XHxn15" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gedit/.Manifest.IIHzel" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gedit/.gedit-2.30.4.ebuild.jaIZrA" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gedit/.gedit-3.10.4.ebuild.goiuFP" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gvim/.ChangeLog.oCj4S4" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gvim/.Manifest.FUBf9j" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gvim/.gvim-7.4.169.ebuild.5VYSpz" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/gvim/.gvim-9999.ebuild.SQ5BHO" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/latexila/.ChangeLog.3sM8Z3" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/latexila/.Manifest.W4OKij" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/latexila/.latexila-2.10.0.ebuild.7lOnBy" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/scite/.ChangeLog.VcQjUN" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/scite/.Manifest.2luZd3" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/scite/.scite-3.3.9.ebuild.A0IUxi" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/vim-core/.ChangeLog.HqPYRx" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/vim-core/.Manifest.7qujeN" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/vim-core/.vim-core-7.4.169.ebuild.G6y0A2" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/vim-core/.vim-core-9999.ebuild.5pGwYh" failed: Permission denied (13)
rsync: mkstemp "/usr/portage/app-editors/vim/.ChangeLog.mS45lx" failed: Permission denied (13)
^C

Exiting on signal 2
 * Time statistics:
    34 seconds total
$ rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(549) [generator=3.0.9]
rsync error: received SIGUSR1 (code 19) at main.c(1298) [receiver=3.0.9]
^C
$

[-- Attachment #3: emerge_info.txt --]
[-- Type: text/plain, Size: 4835 bytes --]

Portage 2.2.7 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.14.1-r3, 3.0.3 x86_64)
=================================================================
System uname: Linux-3.0.3-x86_64-AMD_Athlon-tm-_II_Neo_K325_Dual-Core_Processor-with-gentoo-2.2
KiB Mem:     1793528 total,     99192 free
KiB Swap:    2000088 total,   1996516 free
Timestamp of tree: Fri, 31 Jan 2014 22:30:01 +0000
ld GNU ld (GNU Binutils) 2.23.2
app-shells/bash:          4.2_p45
dev-lang/python:          2.7.5-r3, 3.2.3-r1, 3.3.2-r2
dev-util/cmake:           2.8.11.2
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.12.4
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13, 2.69
sys-devel/automake:       1.11.1, 1.12.1, 1.13.4
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.5.3-r2, 4.6.3, 4.7.3-r1
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.4 (virtual/os-headers)
sys-libs/glibc:           2.14.1-r3
Repositories: gentoo x-portage
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.virginmedia.com/ http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://mirror.bytemark.co.uk/gentoo/ http://mirror.qubenet.net/mirror/gentoo/"
LANG="en_GB.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
USE="3dnow 3dnowext X aac aacplus acl alsa amd64 berkdb bluray bzip2 cddb cdparanoia cli cracklib crypt css cxx dbus dga directfb dri faac fbcon flac fortran gdbm ggi gif iconv jpeg libmpeg2 lzo mad md5sum mmx mmxext modules mp3 mpeg mpg123 multilib ncurses network-cron nls nptl ntfs offensive ogg opengl openmp optimization pam pch pcre png quvi rar raw readline reiserfs rtmp schroedinger session sse sse2 ssl tcpd theora tiff truetype udev unicode vaapi vdpau vim-syntax vorbis vpx webserver x264 xv xvid xvmc zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="dummy fbdev nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON

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

[Gleb Klochkov]

[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]

Hi. Try to use sudo with no password for eix-sync.
10.02.2014 20:07 пользователь "Stroller" <stroller@stellar.eclipse.co.uk>
написал:

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

[-- Attachment #2: Type: text/html, Size: 3412 bytes --]

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

[Stroller]

On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov <glebiuskv@gmail.com> wrote:

> Hi. Try to use sudo with no password for eix-sync.

I'd really rather not. Thanks, though.

Stroller.

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@gmail.com

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

[Walter Dnes]

On Mon, Feb 10, 2014 at 05:09:55PM +0000, Stroller wrote
> 
> On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov <glebiuskv@gmail.com> wrote:
> 
> > Hi. Try to use sudo with no password for eix-sync.
> 
> I'd really rather not. Thanks, though.

  Being in group "portage" is not enough.  That merely lets you do
emerges with "--pretend".  "emerge --sync" modifies files in
/usr/portage.  Files and directories in /usr/portage/ are user:group
root:root.  Therefore you *NEED* root-level permission to modify them.
No ifs/ands/ors/buts.  The overall easiest method is to (as root)...
* "emerge sudoers" if it's not installed
* "visudo -f /etc/sudoers.d/001" (or whatever you want to call the file)
* set up the file.  Here's a fragment from my system, with user
  "waltdnes" and machine name "i660"
waltdnes  i660 = (root) NOPASSWD: /usr/sbin/hibernate
waltdnes  i660 = (root) NOPASSWD: /sbin/fdisk -l

  I could manually type the command with sudo, but I'm lazy.  In my
/home/waltdnes/bin directory, I have a file "hb"

#!/bin/bash
sync
sleep 15
sudo /usr/sbin/hibernate

and file "fdl"

#!/bin/bash
sudo /sbin/fdisk -l

  To sync the machine, I could add to /etc/sudoers.d/001

waltdnes  i660 = (root) NOPASSWD: /usr/bin/emerge --sync

  and create (as waltdnes) /home/waltdnes/emsy

#!/bin/bash
/usr/bin/emerge --sync

  For security, I strongly recommend that the full path of the
executable be specified, as well as any options.  Do not use the $*
commandline parameter in the sudoers file.  It probably works, but is
too wide open.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Alan McKinnon]

On 10/02/2014 21:03, Walter Dnes wrote:
> On Mon, Feb 10, 2014 at 05:09:55PM +0000, Stroller wrote
>>
>> On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov <glebiuskv@gmail.com> wrote:
>>
>>> Hi. Try to use sudo with no password for eix-sync.
>>
>> I'd really rather not. Thanks, though.
> 
>   Being in group "portage" is not enough.  That merely lets you do
> emerges with "--pretend".  "emerge --sync" modifies files in
> /usr/portage.  Files and directories in /usr/portage/ are user:group
> root:root.  Therefore you *NEED* root-level permission to modify them.

Not quite, it's not a cut and dried as that. If root chowns the files to
a regular user, and that user then syncs, ownership remains with the
user (as a regular user can't chown stuff and the owner must remain the
user regardless of what the master tree reckons the owning uid is).

If the tree is then synced by root, well then all the problems come back :-)




> No ifs/ands/ors/buts.  The overall easiest method is to (as root)...
> * "emerge sudoers" if it's not installed
> * "visudo -f /etc/sudoers.d/001" (or whatever you want to call the file)
> * set up the file.  Here's a fragment from my system, with user
>   "waltdnes" and machine name "i660"
> waltdnes  i660 = (root) NOPASSWD: /usr/sbin/hibernate
> waltdnes  i660 = (root) NOPASSWD: /sbin/fdisk -l
> 
>   I could manually type the command with sudo, but I'm lazy.  In my
> /home/waltdnes/bin directory, I have a file "hb"
> 
> #!/bin/bash
> sync
> sleep 15
> sudo /usr/sbin/hibernate
> 
> and file "fdl"
> 
> #!/bin/bash
> sudo /sbin/fdisk -l
> 
>   To sync the machine, I could add to /etc/sudoers.d/001
> 
> waltdnes  i660 = (root) NOPASSWD: /usr/bin/emerge --sync
> 
>   and create (as waltdnes) /home/waltdnes/emsy
> 
> #!/bin/bash
> /usr/bin/emerge --sync
> 
>   For security, I strongly recommend that the full path of the
> executable be specified, as well as any options.  Do not use the $*
> commandline parameter in the sudoers file.  It probably works, but is
> too wide open.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Kerin Millar]

On 10/02/2014 19:03, Walter Dnes wrote:
> On Mon, Feb 10, 2014 at 05:09:55PM +0000, Stroller wrote
>>
>> On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov <glebiuskv@gmail.com> wrote:
>>
>>> Hi. Try to use sudo with no password for eix-sync.
>>
>> I'd really rather not. Thanks, though.
>
>    Being in group "portage" is not enough.  That merely lets you do
> emerges with "--pretend".  "emerge --sync" modifies files in
> /usr/portage.  Files and directories in /usr/portage/ are user:group
> root:root.  Therefore you *NEED* root-level permission to modify them.
> No ifs/ands/ors/buts.  The overall easiest method is to (as root)...

Your are mistaken. The "usersync" FEATURE is a default. You can rename 
your make.conf file and invoke portageq envvar FEATURES to verify this. 
The consequence of this feature being enabled is that portage assumes 
the privileges of the owner of /usr/portage. The entire point of this is 
that portage doesn't have to exec rsync as root. Doing so is both 
needless and dangerous.

Ergo, recursively setting the permissions of /usr/portage to 
portage:portage is actually a really good idea. Indeed, you should find 
that recent portage snapshot tarballs extract in such a way that portage 
is both the owner and associated group.

The problem the OP is having concerns only the file modes, which is a 
separate matter altogether.

--Kerin

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

[eroen]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

On Mon, 10 Feb 2014 14:03:44 -0500, "Walter Dnes"
<waltdnes@waltdnes.org> wrote:
> On Mon, Feb 10, 2014 at 05:09:55PM +0000, Stroller wrote
> > 
> > On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov
> > <glebiuskv@gmail.com> wrote:
> > 
> > > Hi. Try to use sudo with no password for eix-sync.
> > 
> > I'd really rather not. Thanks, though.
> 
>   Being in group "portage" is not enough.  That merely lets you do
> emerges with "--pretend".  "emerge --sync" modifies files in
> /usr/portage.  Files and directories in /usr/portage/ are user:group
> root:root.  Therefore you *NEED* root-level permission to modify them.
> No ifs/ands/ors/buts.  The overall easiest method is to (as root)...
> * "emerge sudoers" if it's not installed
> * "visudo -f /etc/sudoers.d/001" (or whatever you want to call the
> file)
> * set up the file.  Here's a fragment from my system, with user
>   "waltdnes" and machine name "i660"
> waltdnes  i660 = (root) NOPASSWD: /usr/sbin/hibernate
> waltdnes  i660 = (root) NOPASSWD: /sbin/fdisk -l
> 
>   I could manually type the command with sudo, but I'm lazy.  In my
> /home/waltdnes/bin directory, I have a file "hb"
> 
> #!/bin/bash
> sync
> sleep 15
> sudo /usr/sbin/hibernate
> 
> and file "fdl"
> 
> #!/bin/bash
> sudo /sbin/fdisk -l
> 
>   To sync the machine, I could add to /etc/sudoers.d/001
> 
> waltdnes  i660 = (root) NOPASSWD: /usr/bin/emerge --sync
> 
>   and create (as waltdnes) /home/waltdnes/emsy
> 
> #!/bin/bash
> /usr/bin/emerge --sync
> 
>   For security, I strongly recommend that the full path of the
> executable be specified, as well as any options.  Do not use the $*
> commandline parameter in the sudoers file.  It probably works, but is
> too wide open.
> 

eroen@falcon ~ $ wget -O - 'http://mirrors.eu.kernel.org/gentoo/snapshots/portage-20140209.tar.xz' 2>/dev/null | tar tvJ | head -n 10                                                                                                     
drwxr-xr-x portage/portage   0 2014-02-10 01:31 portage/                                                             
-rw-r--r-- portage/portage 1232 2013-03-05 22:31 portage/skel.metadata.xml                                           
drwxr-xr-x portage/portage    0 2014-02-10 01:31 portage/sec-policy/                                                 
drwxr-xr-x portage/portage    0 2014-01-12 21:31 portage/sec-policy/selinux-thunderbird/
-rw-r--r-- portage/portage  448 2012-10-13 18:31 portage/sec-policy/selinux-thunderbird/selinux-thunderbird-9999.ebuild
-rw-r--r-- portage/portage 10496 2014-01-12 21:31 portage/sec-policy/selinux-thunderbird/Manifest
-rw-r--r-- portage/portage   476 2013-02-23 18:31 portage/sec-policy/selinux-thunderbird/selinux-thunderbird-2.20120725-r11.ebuild
-rw-r--r-- portage/portage   475 2012-12-13 11:31 portage/sec-policy/selinux-thunderbird/selinux-thunderbird-2.20120725-r8.ebuild
-rw-r--r-- portage/portage   475 2013-08-15 09:01 portage/sec-policy/selinux-thunderbird/selinux-thunderbird-2.20130424-r2.ebuild
-rw-r--r-- portage/portage   475 2012-10-04 20:31
portage/sec-policy/selinux-thunderbird/selinux-thunderbird-2.20120725-r5.ebuild

For portage's (default-enabled) FEATURES="usersync" to work (dropping
privileges when syncing as root), /usr/portage must be writeable by
portage:portage. The tree snapshots have not always had this
permissions setup, so mature installs would require manual intervention
at some point, either updating the permissions or disabling usersync.

Still, the files are not group-writeable by default, so portage group
membership would not be sufficient. I would suggest a solution based on
su/sudo, as merely changing the permissions would need to be re-done if
the tree is ever synced as root later.

-- 
eroen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Kerin Millar]

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"

--Kerin

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

[Kerin Millar]

On 10/02/2014 19:29, Alan McKinnon wrote:
> On 10/02/2014 21:03, Walter Dnes wrote:
>> >On Mon, Feb 10, 2014 at 05:09:55PM +0000, Stroller wrote
>>> >>
>>> >>On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov<glebiuskv@gmail.com>  wrote:
>>> >>
>>>> >>>Hi. Try to use sudo with no password for eix-sync.
>>> >>
>>> >>I'd really rather not. Thanks, though.
>> >
>> >   Being in group "portage" is not enough.  That merely lets you do
>> >emerges with "--pretend".  "emerge --sync" modifies files in
>> >/usr/portage.  Files and directories in /usr/portage/  are user:group
>> >root:root.  Therefore you*NEED*  root-level permission to modify them.
> Not quite, it's not a cut and dried as that. If root chowns the files to
> a regular user, and that user then syncs, ownership remains with the
> user (as a regular user can't chown stuff and the owner must remain the
> user regardless of what the master tree reckons the owning uid is).
>
> If the tree is then synced by root, well then all the problems come back

It won't cause any problems. The effect of usersync is defined as thus:

"Drop privileges to the owner of PORTDIR for emerge(1)."

Hence, emerge --sync run as root will execute rsync as the portage user, 
assuming that PORTDIR is owned by that very same user.

It can only be problematic if all of these conditions hold true:

* usersync is enabled (as it is by default)
* PORTDIR is owned by a non-root user
* The ownership is not consistent across PORTDIR and its children

As mentioned in a few other posts, recent snapshots are portage:portage 
throughout so it's a done deal for new installations. 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.

--Kerin

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

[Walter Dnes]

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

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

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Stroller]

On Mon, 10 February 2014, at 11:57 pm, Walter Dnes <waltdnes@waltdnes.org> wrote:
>> ...
>> 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?

To reduce the number of times the user has to enter an admin password.

I was going to write "not only is it a hassle, but it's also a security risk", but I'm suddenly doubting myself, considering the consequences of allowing user write-access to the portage tree.

Stroller.

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

[Stroller]

On Tue, 11 February 2014, at 12:05 am, Stroller <stroller@stellar.eclipse.co.uk> wrote:
> On Mon, 10 February 2014, at 11:57 pm, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>> ...
>>> 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?
> 
> To reduce the number of times the user has to enter an admin password.

Whups, please excuse me. I misunderstood.

I am still processing this thread, or at least I was when I hit reply 5 minutes ago.

Stroller.

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

[Kerin Millar]

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

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

[Kerin Millar]

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

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

[Walter Dnes]

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.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Kerin Millar]

On 11/02/2014 01:23, 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.

Yes, but only if the group write bit is set throughout PORTDIR. By 
default, rsync - as invoked by portage - preserves the permission bits 
from the remote and the files stored by the mirrors do not have this bit 
set.

What I have described elsewhere is a method for ensuring that the group 
write bit is set. In that case, your concern is justified; you would 
definitely not want to grant membership of the portage group to anyone 
that you couldn't trust in this context.

--Kerin

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

[Mike Gilbert]

On Mon, Feb 10, 2014 at 8:23 PM, Walter Dnes <waltdnes@waltdnes.org> 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.

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

[Alan McKinnon]

On 11/02/2014 01: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).
> 
>>  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?
> 


emerge --sync X number of times daily in a cron

emerge -avuND world deliberately and manually as the sysadmin at your
leisure.

Two different actions in time.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Alan McKinnon]

On 11/02/2014 03:23, 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.
> 

Yes, you can do that. You can also rm with gainful abandon all over the
place and wreak havoc like that. There are many attack vectors involving
user doing dumb things, and no software is ever going to deal fully with
user stupidity or mischief. Modifying an ebuild is no difference
attack-wise to putting it in a local overlay, and you can already do that.

What software security attempts to provide you is protection against
unexpected side-effects like a malformed path (eg unquoted spaces) in an
rm statement run as root, or bad guys out there banging on the door.

Once an attacker can run yoru shell, it's basically game over at that
point wrt security and just a matter of time. So you have a choice
between syncing as a regular user or syncing as root, there are pros and
cons to each. Experience shows that in the general case the former
offers more and better protection. But, if the latter really does suit
your specific needs, then you have the choice to do it that way.

You don't *have* to follow recommendations in man pages at all, but it's
highly recommended you be well informed when making your personal choice.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

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

[Walter Dnes]

On Tue, Feb 11, 2014 at 07:32:46AM +0200, Alan McKinnon wrote

> emerge --sync X number of times daily in a cron
> 
> emerge -avuND world deliberately and manually as the sysadmin at your
> leisure.
> 
> Two different actions in time.

  Assume you sync once a day, and update once a week, the first 6 syncs
would be mostly wasted.  Yes, your final sync would be smaller.  But
your machine and the server would have to go through the file-comparison
process 7 times, instead of once. 

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Tue, 11 Feb 2014 06:07:10 -0500, Walter Dnes wrote:

> > emerge --sync X number of times daily in a cron
> > 
> > emerge -avuND world deliberately and manually as the sysadmin at your
> > leisure.
> > 
> > Two different actions in time.  
> 
>   Assume you sync once a day, and update once a week, the first 6 syncs
> would be mostly wasted.

They wouldn't because eix-sync would inform you of any updates that you
may not ant to wait for. More importantly, if your cron script also runs
glsa-check, you would know about any potential vulnerabilities on your
machine the day they are announced rather than leaving yourself wide open
for up to a week.


-- 
Neil Bothwick

If man ruled the world:
Daisy Duke shorts would never go out of fashion.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alan McKinnon]

On 11/02/2014 13:07, Walter Dnes wrote:
> On Tue, Feb 11, 2014 at 07:32:46AM +0200, Alan McKinnon wrote
> 
>> emerge --sync X number of times daily in a cron
>>
>> emerge -avuND world deliberately and manually as the sysadmin at your
>> leisure.
>>
>> Two different actions in time.
> 
>   Assume you sync once a day, and update once a week, the first 6 syncs
> would be mostly wasted.  Yes, your final sync would be smaller.  But
> your machine and the server would have to go through the file-comparison
> process 7 times, instead of once. 
> 

So what? rsync is cheap and doesn't stress the server unduly.

It doesn't check every object in the directory tree and stat 179680
files/dirs every time, the whole thing is hashed and it's the hash
values that are compared. To compare a directory, rsync only needs to
look at the directory inode, if they match on both ends then it's a
certainty the files match. It's a *very* efficient system, all done
in-memory, your average server can deal with many connections and not
even break a sweat.

If you want to minimize load, concentrate on making emerge world more
efficient so that it takes less than 3 minutes to depgraph on a fast cpu
and up to 40 on a slow one. Coupled with overlays, more often than not
the portage cache is invalidated so emerge ends up sourcing almost every
ebuild file in the tree.

--sync is not something worth optimizing if done once a day. At that
frequency you are well below the noise floor


-- 
Alan McKinnon
alan.mckinnon@gmail.com