[pacman-dev] [PATCH] change the cwd from / to config->root while running scriplets
http://frugalware.org/~vmiklos/patches/libpacman-proposed/20051222/installfi... several scriptlet uses just usr/lib instead of /usr/lib and this is needed for them. also this was an incompatibility with pacman2 udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
http://frugalware.org/~vmiklos/patches/libpacman-proposed/20051222/installfi...
several scriptlet uses just usr/lib instead of /usr/lib and this is needed for them. also this was an incompatibility with pacman2
AFAICS, the scriplet is run inside a chrooted environment at the top level directory, so what's the difference between usr/lib and /usr/lib? Basically, that's the same code as in pacman 2.9.7: where's the incompatibility? -- Aurelien
On Mon, Jan 16, 2006 at 11:14:14PM +0100, Aurelien Foret
AFAICS, the scriplet is run inside a chrooted environment at the top level directory, so what's the difference between usr/lib and /usr/lib?
Basically, that's the same code as in pacman 2.9.7: where's the incompatibility?
pls read the manpage of chroot(2): "This call does not change the current working directory, so that after the call `.' can be outside the tree rooted at `/'. In particular, the superuser can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'." udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
VMiklos wrote:
pls read the manpage of chroot(2): "This call does not change the current working directory, so that after the call `.' can be outside the tree rooted at `/'. In particular, the superuser can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'."
I made a few attempts to reproduce the issue, but without success. I understand the reason of the fix, but wouldn't it be better to change the working directory within the child process, right after the call to chroot, instead of changing to the "root" directory from the father process? Something like: if(pid == 0) { if(chroot(root) == -1) { ... } if(chdir("/") == -1) { ... } ... } I've got the feeling it is safer to have the father staying at "/" while operations from the install scripts are performed. FYI, I had a look at the implementation of the chroot binary, and it is coded as described above... -- Aurelien
On Thu, Jan 26, 2006 at 09:04:44PM +0100, Aurelien Foret
VMiklos wrote: I made a few attempts to reproduce the issue, but without success.
what i use for testing: $ pacman -Q -r root alsa-utils 1.0.10-2 bash 3.1-1 coreutils 5.2.1-9 glibc 2.3.6-1 ncurses 5.5-1 readline 5.1-1 alsa-utils is the test pkg, whith the following .INSTALL: post_install() { touch tmp/withoutslash touch /tmp/withslash } if i revert the patch in our tree, then withoutslash is created in /tmp, whithslash is in root/tmp if i apply the patch again, then both created in root/tmp
I understand the reason of the fix, but wouldn't it be better to change the working directory within the child process, right after the call to chroot, instead of changing to the "root" directory from the father process?
does this make sense? i don't think so
Something like: if(pid == 0) { if(chroot(root) == -1) { ... } if(chdir("/") == -1) { ... } ... }
I've got the feeling it is safer to have the father staying at "/" while operations from the install scripts are performed.
it's safe to stay in the alternate root, too. or could you mention any example when there's a difference?
FYI, I had a look at the implementation of the chroot binary, and it is coded as described above...
ok, i don't say it's bad, just i think it's not better than my fix udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
participants (2)
-
Aurelien Foret
-
VMiklos