Re: [gentoo-user] User eix-sync permissions problem
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 waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] User eix-sync permissions problem
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. signature.asc Description: PGP signature
Re: [gentoo-user] User eix-sync permissions problem
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.mckin...@gmail.com
[gentoo-user] User eix-sync permissions problem
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. $ 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-ad...@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-ad...@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)
Re: [gentoo-user] User eix-sync permissions problem
Hi. Try to use sudo with no password for eix-sync. 10.02.2014 20:07 пользователь Stroller strol...@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.
Re: [gentoo-user] User eix-sync permissions problem
On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov glebiu...@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
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.mckin...@gmail.com
Re: [gentoo-user] User eix-sync permissions problem
On Mon, Feb 10, 2014 at 05:09:55PM +, Stroller wrote On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov glebiu...@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 waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] User eix-sync permissions problem
On 10/02/2014 21:03, Walter Dnes wrote: On Mon, Feb 10, 2014 at 05:09:55PM +, Stroller wrote On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov glebiu...@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.mckin...@gmail.com
Re: [gentoo-user] User eix-sync permissions problem
On 10/02/2014 19:03, Walter Dnes wrote: On Mon, Feb 10, 2014 at 05:09:55PM +, Stroller wrote On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkov glebiu...@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
Re: [gentoo-user] User eix-sync permissions problem
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
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 +, Stroller wrote On Mon, 10 February 2014, at 4:55 pm, Gleb Klochkovglebiu...@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
On Mon, Feb 10, 2014 at 11:10:50PM +, 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 waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] User eix-sync permissions problem
On Mon, 10 February 2014, at 11:57 pm, Walter Dnes waltd...@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
On Tue, 11 February 2014, at 12:05 am, Stroller strol...@stellar.eclipse.co.uk wrote: On Mon, 10 February 2014, at 11:57 pm, Walter Dnes waltd...@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
On 10/02/2014 23:57, Walter Dnes wrote: On Mon, Feb 10, 2014 at 11:10:50PM +, 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
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
On Tue, Feb 11, 2014 at 12:28:43AM +, 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 waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] User eix-sync permissions problem
On 11/02/2014 01:23, Walter Dnes wrote: On Tue, Feb 11, 2014 at 12:28:43AM +, 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
On Mon, Feb 10, 2014 at 8:23 PM, Walter Dnes waltd...@waltdnes.org wrote: On Tue, Feb 11, 2014 at 12:28:43AM +, 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
On 11/02/2014 01:57, Walter Dnes wrote: On Mon, Feb 10, 2014 at 11:10:50PM +, 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.mckin...@gmail.com
Re: [gentoo-user] User eix-sync permissions problem
On 11/02/2014 03:23, Walter Dnes wrote: On Tue, Feb 11, 2014 at 12:28:43AM +, 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.mckin...@gmail.com
