bin/109334: pkg_add(1) using chroot exits with error if wrong
directory
Garrett Cooper
yanegomi at gmail.com
Wed Mar 24 07:00:12 UTC 2010
The following reply was made to PR bin/109334; it has been noted by GNATS.
From: Garrett Cooper <yanegomi at gmail.com>
To: bug-followup at FreeBSD.org, nick at anywi.com
Cc: randi at freebsd.org
Subject: Re: bin/109334: pkg_add(1) using chroot exits with error if wrong
directory
Date: Tue, 23 Mar 2010 23:52:42 -0700
The original comment states that sysinstall was the primary
consumer of the -C option, and while that may have been the case (once
upon a time), it isn't today according to the code I see in
usr.sbin/sysinstall/package.c .
So what I'm going to propose is the following: change the chroot,
s.t. it only affects the install, operation, which means that instead
of chroot'ing immediately, it'll first try to open the packages, then
prior to executing the install instructions will do the chroot and
will `chdir' to the default prefix (user specified); the default value
will be '/'. That way the chdir back to the starting point will be
sane.
Another less invasive solution would be to merely pop '/' on to
the playpen `stack' for the master in make_playpen, i.e.:
if (!getcwd(cwd, FILENAME_MAX)) {
upchuck("getcwd");
return NULL;
}
if (chdir(pen) == FAIL) { /* <-- 2. source of confusion */
cleanup(0);
errx(2, "%s: can't chdir to '%s'", __func__, pen);
}
strcpy(PenLocation, pen);
return pushPen(cwd); /* <-- 2. source of confusion */
The pseudo code being:
if chroot'ed then push '/' on the stack
else push the current working directory on the stack
The only potential issue I could see is when installing multiple
packages, but that use is tainted anyhow because we chrooted early on,
so the assumption is that the packages have been properly mirrored in
the target environment like they are in the host non-chrooted
environment.
It's up to you guys -- it's a toss-up either way as there will be
some level of confusion, but given that pkg_install is a mess and I
hope to refactor it over the course of the next couple of years, this
will be a minor mess that will need to be cleaned up later.
Thanks,
-Garrett
More information about the freebsd-bugs
mailing list