bin/125932: pkg_add(1) doesn't prompt for root credentials and
then fails badly
Garrett Cooper
yanefbsd at gmail.com
Fri Sep 12 07:00:06 UTC 2008
The following reply was made to PR bin/125932; it has been noted by GNATS.
From: "Garrett Cooper" <yanefbsd at gmail.com>
To: "Bruce Cran" <bruce at cran.org.uk>
Cc: bug-followup at freebsd.org
Subject: Re: bin/125932: pkg_add(1) doesn't prompt for root credentials and then fails badly
Date: Thu, 11 Sep 2008 23:24:33 -0700
On Tue, Sep 9, 2008 at 1:23 PM, Bruce Cran <bruce at cran.org.uk> wrote:
> On Thu, 24 Jul 2008 11:18:31 -0700
> "Garrett Cooper" <yanefbsd at gmail.com> wrote:
>
>> On Thu, Jul 24, 2008 at 6:48 AM, Bruce Cran <bruce at cran.org.uk> wrote:
>> >>How-To-Repeat:
>> > Run pkg_add -r as a non-root user.
>> >>Fix:
>>
>> The issue isn't the fact that you're running as non-root; it's that
>> someone's not checking to see whether or not a fetch init succeeded
>> (filehandle's open, writing's being done) before continuing.
>>
>> I'll fix this later on tonight when I get back from San Jose.
>>
>
> Did you make any progress with this?
I thought I made a comment about this earlier, but apparently I didn't
send it out or it wasn't recorded:
Symptom:
The issue is caused by tar in the PUSHOUT macro in add/extract.c as
identified below, during the extract. If and when the tar stuff is
replaced with libarchive, this issue will fail sooner (and this should
be done because this would save a lot of time and resources when
extracting large packages like openoffice):
#define PUSHOUT(todir) /* push out string */ \
if (where_count > (int)sizeof(STARTSTRING)-1) { \
strcat(where_args, "|/usr/bin/tar --unlink -xpPf - -C "); \
strcat(where_args, todir); \
if (system(where_args)) { \ /*** XXX: FAILS HERE ***/
cleanup(0); \
errx(2, "%s: can not invoke %ld byte tar pipeline: %s", \
__func__, (long)strlen(where_args), where_args); \
} \
Real problem:
The actual problem is that the master and slave pkg_add processes
aren't communicating properly with one another, s.t. the slave
instances aren't breaking the master execution at the first sign of
failure.
HTH,
-Garrett
More information about the freebsd-bugs
mailing list