Re: [gentoo-user] [poll] What is your session state?
because you wrote poll: $ loginctl show-session 1 Id=1 Timestamp=Mo 2014-02-10 08:45:40 CET TimestampMonotonic=28555352 VTNr=7 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=1352 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=sgw --- this is with gnome-3.10 and the session is started with gdm-3.10.0.1 (systemd-208-r3) Mounting USB-stuff works without root-pw ... the only feature needing this is when I start the virtual machine manager (for administration of the VMs on the various QEMU/KVM-hosts I run). But this is maybe by design and OK in a way. Stefan
Re: [gentoo-user] [poll] What is your session state?
On 10 February 2014 09:13:37 CET, Stefan G. Weichinger li...@xunil.at wrote: because you wrote poll: $ loginctl show-session 1 Id=1 Timestamp=Mo 2014-02-10 08:45:40 CET TimestampMonotonic=28555352 VTNr=7 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=1352 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=sgw --- this is with gnome-3.10 and the session is started with gdm-3.10.0.1 (systemd-208-r3) Mounting USB-stuff works without root-pw ... the only feature needing this is when I start the virtual machine manager (for administration of the VMs on the various QEMU/KVM-hosts I run). But this is maybe by design and OK in a way. Stefan I would not expect to have to type I the local root password when administering something on a remote host. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] [poll] What is your session state?
On 10/02/14 00:43, walt wrote:
Recent threads about consolekit vs logind(systemd) have made me curious, so
I've been studying...
A few of us have had recent problems with things like plugging USB sticks,
which once worked transparently but now require root privileges.
I've discovered that my own such problems are caused by this:
$loginctl show-session 1 (I have only one session, cleverly named '1')
Id=1
Timestamp=Sun 2014-02-09 07:18:32 PST
TimestampMonotonic=389744251
VTNr=1
TTY=/dev/tty1
Remote=no
Service=login
Scope=session-1.scope
Leader=426
Audit=1
Type=tty
Class=user
Active=no = should be 'yes'
State=online === should be 'active'
Users of consolekit, don't feel neglected. You should try this instead:
$ck-list-sessions
Session1:
unix-user = '1001'
realname = '(null)'
seat = 'Seat2'
session-type = ''
active = FALSE(correct because I'm ssh'd into a remote box)
x11-display = ':0'
x11-display-device = '/dev/tty2'
display-device = '/dev/tty1'
remote-host-name = ''
is-local = FALSE
on-since = '2014-02-09T22:00:10.750312Z'
login-session-id = '1'
Canek explained that the reason my session is not 'active' is that I'm
not using a Display Manager (gdm kdm lightdm), which talks to logind or
consolekit and vouches for my physical presence at the local keyboard.
However, when I do the same thing on arch linux (as a virtualbox guest)
I see that my session (running gnome) is 'active' and I have no trouble
powering off the virtual machine as an unprivileged user.
Any ideas how I can fix it?
BTW, this helped me to understand some of the buzzwords I used above:
http://www.freedesktop.org/wiki/Software/systemd/multiseat/
sys-auth/pambase with USE=consolekit or USE=systemd brings in
pam_ck_connector.so (ConsoleKit) or pam_systemd.so (systemd)
is required in login to get the initial active session:
ConsoleKit or systemd-logind starts during boot - user logins to tty1
- PAM triggers pam_ck_connector.so or pam_systemd.so - and now you
have one
initial session, second one is started after 'startx' and the
login-session-id is the key knowing it's the same user now in X11,
instead of console since
it changes the first session inactive (since it knows you now started
X11 and are no longer in console) and activates the newly started one in X11
however display managers with *built-in* CK or logind support are
special, and more straightforward and directly talk to CK or logind, and
thus, work
somewhat more easily by skipping many possible problems
maybe you can somehow do it with GDM so that remote session shows
active, i don't know about that, but what you can do is write your own
polkit
rules like:
Put the following content to file: /etc/polkit-1/rules.d/51-local.rules
polkit.addAdminRule(function(action, subject) {
return [unix-group:wheel];
});
Now users in group wheel should be able to do anything, this is also
in man 8 polkit
[gentoo-user] Re: module woes
William Kenworthy billk at iinet.net.au writes: I had this problem back a few months and I had made a typo in grub so the kernels were not loading the correct initrd. BillK I'm using grub2. Can you be a bit more specific? James
[gentoo-user] Re: module woes
Mick michaelkintzios at gmail.com writes: What is stumping me is why all three kernels boot, but the modules only point to 3.10.25, even when boot either the second (kernel-3.13.0-gentoo-r1) kernel or the third (config-3.13.1-gentoo) kernel. I apologise if what I suggest has already been covered, but have you edited your /etc/conf.d/modules to include your latest kernels' modules? Yes, this was a problem. I'm testing now and will post back after I can reboot James
[gentoo-user] Re: module woes
walt w41ter at gmail.com writes: Baffling things happen to me when I compile modules with /usr/src/linux pointing to the wrong sources. Worth a quick look. -rw-r--r-- 1 root0 Dec 25 21:19 .keep lrwxrwxrwx 1 root 20 Feb 2 04:01 linux - linux-3.13.1-gentoo/ nope.it's fine. thx, James
Re: [gentoo-user] [poll] What is your session state?
On Mon, Feb 10, 2014 at 2:36 AM, J. Roeleveld jo...@antarean.org wrote: On 10 February 2014 09:13:37 CET, Stefan G. Weichinger li...@xunil.at wrote: because you wrote poll: $ loginctl show-session 1 Id=1 Timestamp=Mo 2014-02-10 08:45:40 CET TimestampMonotonic=28555352 VTNr=7 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=1352 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=sgw --- this is with gnome-3.10 and the session is started with gdm-3.10.0.1 (systemd-208-r3) Mounting USB-stuff works without root-pw ... the only feature needing this is when I start the virtual machine manager (for administration of the VMs on the various QEMU/KVM-hosts I run). But this is maybe by design and OK in a way. Stefan I would not expect to have to type I the local root password when administering something on a remote host. And you don't need to with logind. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [poll] What is your session state?
On Mon, Feb 10, 2014 at 2:13 AM, Stefan G. Weichinger li...@xunil.at wrote: because you wrote poll: Sorry? Who wrote poll where? $ loginctl show-session 1 Id=1 Timestamp=Mo 2014-02-10 08:45:40 CET TimestampMonotonic=28555352 VTNr=7 Display=:0 Remote=no Service=gdm-password Scope=session-1.scope Leader=1352 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=sgw --- this is with gnome-3.10 and the session is started with gdm-3.10.0.1 (systemd-208-r3) Mounting USB-stuff works without root-pw ... the only feature needing this is when I start the virtual machine manager (for administration of the VMs on the various QEMU/KVM-hosts I run). But this is maybe by design and OK in a way. As I explained in the other thread (and my answer to Walt), this works with a DM. But Walt is not using a DM. Passing vt01 (or whatever) to Xorg fixes Walt's problem, without using a DM. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [poll] What is your session state?
On Mon, Feb 10, 2014 at 4:52 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
On 10/02/14 00:43, walt wrote:
Recent threads about consolekit vs logind(systemd) have made me curious, so
I've been studying...
A few of us have had recent problems with things like plugging USB sticks,
which once worked transparently but now require root privileges.
I've discovered that my own such problems are caused by this:
$loginctl show-session 1 (I have only one session, cleverly named '1')
Id=1
Timestamp=Sun 2014-02-09 07:18:32 PST
TimestampMonotonic=389744251
VTNr=1
TTY=/dev/tty1
Remote=no
Service=login
Scope=session-1.scope
Leader=426
Audit=1
Type=tty
Class=user
Active=no = should be 'yes'
State=online === should be 'active'
Users of consolekit, don't feel neglected. You should try this instead:
$ck-list-sessions
Session1:
unix-user = '1001'
realname = '(null)'
seat = 'Seat2'
session-type = ''
active = FALSE(correct because I'm ssh'd into a remote box)
x11-display = ':0'
x11-display-device = '/dev/tty2'
display-device = '/dev/tty1'
remote-host-name = ''
is-local = FALSE
on-since = '2014-02-09T22:00:10.750312Z'
login-session-id = '1'
Canek explained that the reason my session is not 'active' is that I'm
not using a Display Manager (gdm kdm lightdm), which talks to logind or
consolekit and vouches for my physical presence at the local keyboard.
However, when I do the same thing on arch linux (as a virtualbox guest)
I see that my session (running gnome) is 'active' and I have no trouble
powering off the virtual machine as an unprivileged user.
Any ideas how I can fix it?
BTW, this helped me to understand some of the buzzwords I used above:
http://www.freedesktop.org/wiki/Software/systemd/multiseat/
sys-auth/pambase with USE=consolekit or USE=systemd brings in
pam_ck_connector.so (ConsoleKit) or pam_systemd.so (systemd)
is required in login to get the initial active session:
ConsoleKit or systemd-logind starts during boot - user logins to tty1
- PAM triggers pam_ck_connector.so or pam_systemd.so - and now you
have one
initial session, second one is started after 'startx' and the
login-session-id is the key knowing it's the same user now in X11,
instead of console since
it changes the first session inactive (since it knows you now started
X11 and are no longer in console) and activates the newly started one in X11
Exactly.
however display managers with *built-in* CK or logind support are
special, and more straightforward and directly talk to CK or logind, and
thus, work
somewhat more easily by skipping many possible problems
Again, exactly.
maybe you can somehow do it with GDM
Yes, you can, but you can also do it via startx passing vt01 (or
whatever) to Xorg.
so that remote session shows
active, i don't know about that, but what you can do is write your own
polkit
rules like:
Put the following content to file: /etc/polkit-1/rules.d/51-local.rules
polkit.addAdminRule(function(action, subject) {
return [unix-group:wheel];
});
Now users in group wheel should be able to do anything, this is also
in man 8 polkit
I don't think that's a good idea. It's going to work, but it's like
killing flies with cannons, and perhaps a security risk.
More importantly, it's not necessary since X.org has built in support
for logind; you just need to pass to it the virtual terminal to use so
the user session it's shared in X11.
No need to configure anything, works out-of-the-box, and you don't
even need the root password. You just need to use startx this way:
startx -- vt01
(Or vt02, or vt03, etc.) And that's it. By the way, you can also
specify the seat for X.org with -seat seatX or whatever.
And that's the beauty of logind; it's getting support everywhere
(GNOME, polkit, KDE, Xfce, barebones X), and it frees us from
modifying permissions, or adding/joining groups, or creating policykit
rules, since it does the Right Thing™.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] [poll] What is your session state?
Am 10.02.2014 16:12, schrieb Canek Peláez Valdés: On Mon, Feb 10, 2014 at 2:13 AM, Stefan G. Weichinger li...@xunil.at wrote: because you wrote poll: Sorry? Who wrote poll where? Subject of mail ... afai see. S
Re: [gentoo-user] [poll] What is your session state?
Am 10.02.2014 16:13, schrieb Canek Peláez Valdés: I would not expect to have to type I the local root password when administering something on a remote host. And you don't need to with logind. logind runs here as well. What to change? Wher to put that startx -- vt01 in my case (systemd, logind, gdm ...) I still wonder about that pam_systemd ... do I need it or not ... Maybe we can find a nice howto here ... Stefan
Re: [gentoo-user] [poll] What is your session state?
On Mon, Feb 10, 2014 at 9:50 AM, Stefan G. Weichinger li...@xunil.at wrote: Am 10.02.2014 16:12, schrieb Canek Peláez Valdés: On Mon, Feb 10, 2014 at 2:13 AM, Stefan G. Weichinger li...@xunil.at wrote: because you wrote poll: Sorry? Who wrote poll where? Subject of mail ... afai see. Yeah, I totally missed that. Sorry. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [poll] What is your session state?
On Mon, Feb 10, 2014 at 9:52 AM, Stefan G. Weichinger li...@xunil.at wrote: Am 10.02.2014 16:13, schrieb Canek Peláez Valdés: I would not expect to have to type I the local root password when administering something on a remote host. And you don't need to with logind. logind runs here as well. What to change? Wher to put that startx -- vt01 in my case (systemd, logind, gdm ...) I still wonder about that pam_systemd ... do I need it or not ... Maybe we can find a nice howto here ... Stefan, I'm not following you. Do you have the same problem that Walt has? In your DE you are being asked for your root password when you insert a USB stick or when you power off the machine from the menu? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] [poll] What is your session state?
Am 10.02.2014 16:55, schrieb Canek Peláez Valdés: Stefan, I'm not following you. Do you have the same problem that Walt has? In your DE you are being asked for your root password when you insert a USB stick or when you power off the machine from the menu? Only when I start virtual machine manager (VMM, app-emulation/virt-manager) it says something like system policy prevents management of local virtualized systems and wants the root password. I already saw it asking when powering off but this has changed in the past ... dunno when. USB-sticks work as well. Stefan
[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] [poll] What is your session state?
On Mon, Feb 10, 2014 at 9:58 AM, Stefan G. Weichinger li...@xunil.at wrote: Am 10.02.2014 16:55, schrieb Canek Peláez Valdés: Stefan, I'm not following you. Do you have the same problem that Walt has? In your DE you are being asked for your root password when you insert a USB stick or when you power off the machine from the menu? Only when I start virtual machine manager (VMM, app-emulation/virt-manager) it says something like system policy prevents management of local virtualized systems and wants the root password. I already saw it asking when powering off but this has changed in the past ... dunno when. USB-sticks work as well. I remeber something similar when I was running gnome-boxes. However, nowadays I use qemu directly; it never asks for my root password. I run it as a normal user, obviously. I don't know if this is related to logind. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
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
[gentoo-user] Re: User eix-sync permissions problem
On Mon, 10 Feb 2014 14:03:44 -0500, Walter Dnes waltd...@waltdnes.org 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)... * 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/portage0 2014-02-10 01:31 portage/sec-policy/ drwxr-xr-x portage/portage0 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-.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 signature.asc Description: PGP signature
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] [poll] What is your session state?
Am 10.02.2014 17:11, schrieb Canek Peláez Valdés: I remeber something similar when I was running gnome-boxes. However, nowadays I use qemu directly; it never asks for my root password. I run it as a normal user, obviously. I don't know if this is related to logind. looked through the files installed by VMM ... didn't spot it. It's ok with me so far. Stefan
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
[gentoo-user] Re: [poll] What is your session state?
On 02/09/2014 06:06 PM, Canek Peláez Valdés wrote: On Sun, Feb 9, 2014 at 4:43 PM, walt w41...@gmail.com wrote: Recent threads about consolekit vs logind(systemd) have made me curious, so I've been studying... A few of us have had recent problems with things like plugging USB sticks, which once worked transparently but now require root privileges. I've discovered that my own such problems are caused by this: $loginctl show-session 1 (I have only one session, cleverly named '1') Id=1 Timestamp=Sun 2014-02-09 07:18:32 PST TimestampMonotonic=389744251 VTNr=1 TTY=/dev/tty1 Remote=no Service=login Scope=session-1.scope Leader=426 Audit=1 Type=tty Class=user Active=no = should be 'yes' State=online === should be 'active' Users of consolekit, don't feel neglected. You should try this instead: $ck-list-sessions Session1: unix-user = '1001' realname = '(null)' seat = 'Seat2' session-type = '' active = FALSE(correct because I'm ssh'd into a remote box) x11-display = ':0' x11-display-device = '/dev/tty2' display-device = '/dev/tty1' remote-host-name = '' is-local = FALSE on-since = '2014-02-09T22:00:10.750312Z' login-session-id = '1' Canek explained that the reason my session is not 'active' is that I'm not using a Display Manager (gdm kdm lightdm), which talks to logind or consolekit and vouches for my physical presence at the local keyboard. However, when I do the same thing on arch linux (as a virtualbox guest) I see that my session (running gnome) is 'active' and I have no trouble powering off the virtual machine as an unprivileged user. Hi Walt; since I already have GNOME 3+systemd, I decided to install Xfce. Given that all the plumbing is essentially the same for both desktops, it took less than 15 minutes for portage to emerge it (13 small packages). I started it like you, with exec startxcfe4 in my $HOME/.xinitrc. Boy, I had forgotten how desktops looked at the start of the century. Which century? :p Anyway, I had exactly the same problem as you; I needed my root password to mount USB sticks or shutdown the machine. My session was Active=no, State=online. As I suspected, if I started Xfce through gdm, everything worked without any issue; session was Active=yes, State=active, and my root password was not required for anything. So one workaround is to install gdm, but that is ugly (and unnecessary, see below). Any ideas how I can fix it? Yeah, I found the solution on the net: http://blog.falconindy.com/articles/back-to-basics-with-x-and-systemd.html Thank you! Basically, invoke startx passing Xorg the option of which VT you want to transfer for your X11 session: startx -- vt01 Obviously, that only works if you are in VT 1 (Alt-F1). What an obvious fix, once you understand the underlying problem. BTW (thinking seat0) I typed startx --vt0 That was interesting. (But not recommended :) I owe you an apology Walter; I just assumed you had configured something wrong. I'm just getting used to the fact that with GNOME 3+systemd everything kinda works immediately. Sorry. No problem Canek. I'd never have got this far without your suggestions and hints. I really don't understand how could I get any work done before using GNOME Shell. Hmm. I think by 3.12 I'll be ready to give it another try. Meanwhile I'll stick to an earlier century :)
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
