[gentoo-user-fr] ACCESS DENIED pendant un emerge alors que je suis root

Le
Stephane Bortzmeyer
Je n'arrive pas à faire des emerge :

% sudo emerge screen

Calculating dependencies done!
>>> emerge (1 of 6) sys-devel/automake-wrapper-3-r1 to /
>>> md5 files ;-) automake-wrapper-1-r1.ebuild
>>> md5 files ;-) automake-wrapper-2-r1.ebuild
>>> md5 files ;-) automake-wrapper-3-r1.ebuild
>>> md5 files ;-) files/am-wrapper-1.sh
>>> md5 files ;-) files/digest-automake-wrapper-1-r1
>>> md5 files ;-) files/am-wrapper-2.sh
>>> md5 files ;-) files/am-wrapper-3.sh
>>> md5 files ;-) files/digest-automake-wrapper-2-r1
>>> md5 files ;-) files/digest-automake-wrapper-3-r1
ACCESS DENIED open_wr: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log
/usr/lib/portage/bin/ebuild.sh: line 1445: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log: Permission denied
ACCESS DENIED mkdir: /var/portage-extra/tmp/automake-wrapper-3-r1/work
install: cannot create directory `/var/tmp/portage/automake-wrapper-3-r1/work': Permission denied

!!! ERROR: sys-devel/automake-wrapper-3-r1 failed.
!!! Function dyn_unpack, Line 669, Exitcode 1
!!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work'
!!! If you need support, post the topmost build error, NOT this status message.

ACCESS VIOLATION SUMMARY
LOG FILE = "/var/log/sandbox/sandbox-sys-devel_-_automake-wrapper-3-r1-6949.log"

open_wr: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log (symlink to /var/portage-extra/tmp/automake-wrapper-3-r1/temp/eclass-debug.log)
chmod: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log (symlink to /var/portage-extra/tmp/automake-wrapper-3-r1/temp/eclass-debug.log)
mkdir: /var/portage-extra/tmp/automake-wrapper-3-r1/work

Or, je suis root, et, si je tente de créer ces répertoires à la main,
ça marche :

digory:~ % sudo -u portage mkdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo -u portage rmdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo mkdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo rmdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo -u portage mkdir /var/tmp/portage/automake-wrapper-3-r1/work
digory:~ % sudo -u portage rmdir /var/tmp/portage/automake-wrapper-3-r1/work

Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et
que /var/portage-extra est servi en NFS (par une machine NetBSD). Le
problème est sans doute là mais je ne vois pas où puisque la machine
NetBSD exporte avec :

/home/exports/gentoo -network 172.19.1.0/24 -maproot=root

Et que, je l'ai montré, root sur la machine gentoo peut bien créer les
répertoires qu'il veut.
--
gentoo-user-fr@gentoo.org mailing list
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Boris Fersing
Le #7825281
Le 15/02/07, Stephane Bortzmeyer
Je n'arrive pas à faire des emerge :

% sudo emerge screen
...
Calculating dependencies ...done!
>>> emerge (1 of 6) sys-devel/automake-wrapper-3-r1 to /
>>> md5 files ;-) automake-wrapper-1-r1.ebuild
>>> md5 files ;-) automake-wrapper-2-r1.ebuild
>>> md5 files ;-) automake-wrapper-3-r1.ebuild
>>> md5 files ;-) files/am-wrapper-1.sh
>>> md5 files ;-) files/digest-automake-wrapper-1-r1
>>> md5 files ;-) files/am-wrapper-2.sh
>>> md5 files ;-) files/am-wrapper-3.sh
>>> md5 files ;-) files/digest-automake-wrapper-2-r1
>>> md5 files ;-) files/digest-automake-wrapper-3-r1
ACCESS DENIED open_wr: /var/tmp/portage/automake-wrapper-3-r1/temp/ecl ass-debug.log
/usr/lib/portage/bin/ebuild.sh: line 1445: /var/tmp/portage/automake-wrap per-3-r1/temp/eclass-debug.log: Permission denied
ACCESS DENIED mkdir: /var/portage-extra/tmp/automake-wrapper-3-r1/wo rk
install: cannot create directory `/var/tmp/portage/automake-wrapper-3-r1/ work': Permission denied

!!! ERROR: sys-devel/automake-wrapper-3-r1 failed.
!!! Function dyn_unpack, Line 669, Exitcode 1
!!! Failed to create dir '/var/tmp/portage/automake-wrapper-3-r1/work'
!!! If you need support, post the topmost build error, NOT this status me ssage.

--------------------------- ACCESS VIOLATION SUMMARY -------------------- -------
LOG FILE = "/var/log/sandbox/sandbox-sys-devel_-_automake-wrapper-3-r1- 6949.log"

open_wr: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log ( symlink to /var/portage-extra/tmp/automake-wrapper-3-r1/temp/eclass-debug.l og)
chmod: /var/tmp/portage/automake-wrapper-3-r1/temp/eclass-debug.log ( symlink to /var/portage-extra/tmp/automake-wrapper-3-r1/temp/eclass-debug.l og)
mkdir: /var/portage-extra/tmp/automake-wrapper-3-r1/work

Or, je suis root, et, si je tente de créer ces répertoires à la mai n,
ça marche :

digory:~ % sudo -u portage mkdir /var/portage-extra/tmp/automake-wrapper- 3-r1/work
digory:~ % sudo -u portage rmdir /var/portage-extra/tmp/automake-wrapper- 3-r1/work
digory:~ % sudo mkdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo rmdir /var/portage-extra/tmp/automake-wrapper-3-r1/work
digory:~ % sudo -u portage mkdir /var/tmp/portage/automake-wrapper-3-r1/w ork
digory:~ % sudo -u portage rmdir /var/tmp/portage/automake-wrapper-3-r1/w ork

Notez que /var/tmp/portage est un lien vers /var/portage-extra/tmp et
que /var/portage-extra est servi en NFS (par une machine NetBSD). Le
problème est sans doute là mais je ne vois pas où puisque la machin e
NetBSD exporte avec :

/home/exports/gentoo -network 172.19.1.0/24 -maproot=root

Et que, je l'ai montré, root sur la machine gentoo peut bien créer le s
répertoires qu'il veut.



Salut,

le problème vient justement du lien je pense... Tu as beau être root,
il est probable que portage soit lancé en mode user et même si ce
n'était pas le cas, SANDBOX est là pour veiller à ce qu'il ne fasse
pas de bêtises.
Dans ton cas il me semble que le lien symbolique déroute un peu
sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
doit s'apercevoir que /var/tmp/portage est en fait
/var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !

Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !

Amicalement,

Boris.
--
mailing list






--
$ ruby -e'puts " .:@BFegiklnorst".unpack("x4ax7aaX6ax5aX15ax4aax6aaX7ax2
aX5aX8axaX3ax8aX4ax6aX3aX6ax3ax3aX9ax4ax2aX9axaX6ax3aX2ax4
ax3aX4aXaX12ax10aaX7a").join'
--
mailing list
Stephane Bortzmeyer
Le #7825271
On Thu, Feb 15, 2007 at 09:00:47AM +0100,
Boris Fersing a message of 100 lines which said:

Dans ton cas il me semble que le lien symbolique déroute un peu
sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
doit s'apercevoir que /var/tmp/portage est en fait
/var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !



Il a le droit au sens Unix mais il y a un autre mécanisme
("sandbox" ?), programmé dans portage, qui l'en empêche, c'est cela ?

Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !



Ça marche, merci beaucoup :

digory:/var/tmp % sudo mkdir portage
digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/portage

Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre
cela automatiquement en place au démarrage.
--
mailing list
Boris Fersing
Le #7825261
Le 15/02/07, Stephane Bortzmeyer
On Thu, Feb 15, 2007 at 09:00:47AM +0100,
Boris Fersing a message of 100 lines which said:

> Dans ton cas il me semble que le lien symbolique déroute un peu
> sandbox. Je ne connais pas le mécanisme interne, mais je pense qu'il
> doit s'apercevoir que /var/tmp/portage est en fait
> /var/portage-extra/tmp/ et que portage n'a pas le droit d'y écrire !

Il a le droit au sens Unix mais il y a un autre mécanisme
("sandbox"?), programmé dans portage, qui l'en empêche, c'est cela ?



En fait quand portage compile une application, il le fait dans un
environement protégé, sous surveillance, Sandbox. Si portage essaye
d'accéder à un fichier en dehors de cet environnement, ça gueule !
C'est pour éviter qu'un ebuild / makefile mal foutu casse ton système
!

Boris.


> Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
> symbolique !

Ça marche, merci beaucoup :

digory:/var/tmp % sudo mkdir portage
digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/porta ge

Et emerge est content. J'ai plus qu'à lire la doc de fstab pour mettre
cela automatiquement en place au démarrage.
--
mailing list






--
$ ruby -e'puts " .:@BFegiklnorst".unpack("x4ax7aaX6ax5aX15ax4aax6aaX7ax2
aX5aX8axaX3ax8aX4ax6aX3aX6ax3ax3aX9ax4ax2aX9axaX6ax3aX2ax4
ax3aX4aXaX12ax10aaX7a").join'
--
mailing list
Christophe PEREZ
Le #7825231
Le Thu, 15 Feb 2007 09:09:18 +0100, Stephane Bortzmeyer a écrit :

Tu peux essayer de le bluffer avec un mount -o bind plutôt qu'un lien
symbolique !



Ça marche, merci beaucoup :

digory:/var/tmp % sudo mkdir portage
digory:/var/tmp % sudo mount --bind /var/portage-extra/tmp /var/tmp/portage



Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir le
PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?
Ça me semble plus dans la philosophie portage, et plus simple à mettre
en oeuvre.

--
Christophe PEREZ
--
mailing list
Stephane Bortzmeyer
Le #7825201
On Thu, Feb 15, 2007 at 09:58:56AM -0400,
Christophe PEREZ a message of 17 lines which said:

Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir
le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?



Ah, oui, je l'ai mis dans mon /etc/make.conf (en variable
d'environnement, elle semble ignorée) et ça marche. Merci beaucoup.


--
mailing list
Christophe PEREZ
Le #7825191
Le Thu, 15 Feb 2007 22:27:40 +0100, Stephane Bortzmeyer a écrit :

Je dis peut-être une bêtise, mais pourquoi ne pas plutôt redéfinir
le PORTAGE_TMPDIR vers le NFS au lieu de faire ces montages/liens ?



Ah, oui, je l'ai mis dans mon /etc/make.conf (en variable
d'environnement, elle semble ignorée) et ça marche. Merci beaucoup.



Je t'en prie.

PS : Oui, évidemment, c'est une variable portage, donc se met dans le
make.conf.

--
Christophe PEREZ
--
mailing list
Publicité
Poster une réponse
Anonyme