Re: pkg_add not working

[Baptiste Daroussin]

On Wed, Apr 17, 2013 at 08:59:25PM -0700, Mehmet Erol Sanliturk wrote:
> On Wed, Apr 17, 2013 at 8:49 PM, Neel Natu  wrote:
> 
> > Hi,
> >
> > I am running HEAD and recently started getting errors on pkg_add.
> >
> > uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:25:06
> > PDT 2013
> >
> > > pkg_add -r sudo
> > Error: Unable to get
> >
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz
> > :
> > File unavailable (e.g., file not found, no access)
> > pkg_add: unable to fetch '
> >
> > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz
> > '
> > by URL
> >
> > This used to work pretty well until a few days ago. Any clues?
> >
> > best
> > Neel
> >
> 
> 
> The 
> "packages-10-current"
> is deleted from
> 
> ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/
> 
> 
> It seems that , it will be reconstructed from scratch .
> 
> 
There is high probabilty that it won't, pkg_add is deprecated, and current has
switch to pkgng by default for a while now. given we have to rebuild all the
packages from scratch, there is a very high level of chance only the one
respecting the default will be built now (meaning pkgng)

regards,
Bapt


pgps6iSPe_oBM.pgp
Description: PGP signature

Re: pkg_add not working

[Mehmet Erol Sanliturk]

On Wed, Apr 17, 2013 at 8:49 PM, Neel Natu  wrote:

> Hi,
>
> I am running HEAD and recently started getting errors on pkg_add.
>
> uname: 10.0-CURRENT FreeBSD 10.0-CURRENT #103 r249396M: Thu Apr 11 23:25:06
> PDT 2013
>
> > pkg_add -r sudo
> Error: Unable to get
>
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz
> :
> File unavailable (e.g., file not found, no access)
> pkg_add: unable to fetch '
>
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-10-current/Latest/sudo.tbz
> '
> by URL
>
> This used to work pretty well until a few days ago. Any clues?
>
> best
> Neel
>


The 
"packages-10-current"
is deleted from

ftp://ftp1.freebsd.org/pub/FreeBSD/ports/amd64/


It seems that , it will be reconstructed from scratch .


Thank you very much .


Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg_add segfault

[Dag-Erling Smørgrav]

Mike Makonnen <[EMAIL PROTECTED]> writes:
> is this ok with you?

Ugh, yes.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add segfault

[Joris Vandalon]

On Wed, Mar 19, 2003 at 12:28:06PM -0500, Mike Makonnen wrote:
> Here's a patch.

Tnx, works fine now


Regards,
Joris


> 
> Des,
> is this ok with you?
> 
> Cheers.
> -- 
> Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
> [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9
> 
> Index: lib/libfetch/ftp.c
> ===
> RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v
> retrieving revision 1.86
> diff -u -r1.86 ftp.c
> --- lib/libfetch/ftp.c11 Mar 2003 08:20:58 -  1.86
> +++ lib/libfetch/ftp.c19 Mar 2003 17:24:20 -
> @@ -894,7 +894,7 @@
>   struct url *purl;
>   char *p;
>  
> - if (strchr(flags, 'd') != NULL)
> + if (flags != NULL && strchr(flags, 'd') != NULL)
>   return (NULL);
>   if (((p = getenv("FTP_PROXY")) || (p = getenv("ftp_proxy")) ||
>   (p = getenv("HTTP_PROXY")) || (p = getenv("http_proxy"))) &&
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add segfault

[Mike Makonnen]

Here's a patch.

Des,
is this ok with you?

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9

Index: lib/libfetch/ftp.c
===
RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v
retrieving revision 1.86
diff -u -r1.86 ftp.c
--- lib/libfetch/ftp.c  11 Mar 2003 08:20:58 -  1.86
+++ lib/libfetch/ftp.c  19 Mar 2003 17:24:20 -
@@ -894,7 +894,7 @@
struct url *purl;
char *p;
 
-   if (strchr(flags, 'd') != NULL)
+   if (flags != NULL && strchr(flags, 'd') != NULL)
return (NULL);
if (((p = getenv("FTP_PROXY")) || (p = getenv("ftp_proxy")) ||
(p = getenv("HTTP_PROXY")) || (p = getenv("http_proxy"))) &&

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add segfault

[Mike Makonnen]

On Wed, 19 Mar 2003 16:19:59 +0100
Joris Vandalon <[EMAIL PROTECTED]> wrote:

> Hi there,
> 
> it seemd that pkg_add coredumps while doing pkg_add -r $package
> pkg_add $package seems work ok.
> anyone else experiencing the same problem?
> 
> -example-
> 
> [EMAIL PROTECTED] strace]# pkg_add -r lftp
> Segmentation fault (core dumped)
> [EMAIL PROTECTED] strace]# 
> 

Use rev. 1.85 of /src/lib/libfetch/ftp.c

-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add segfault

[Pierrick Brossin]

Quoting Joris Vandalon <[EMAIL PROTECTED]>:

> Hi there,
> 
> it seemd that pkg_add coredumps while doing pkg_add -r $package
> pkg_add $package seems work ok.
> anyone else experiencing the same problem?

Yeah!

Wanted to pkg_add -r and it coredumped. I tried to cvsup and remake it but
it's not any better!

-- 
Pierrick Brossin
IT Swiss - QUARK Media House
6a Puits Godet, 2000 Neuchatel, Switzerland
Mail Prof: [EMAIL PROTECTED] Mail Priv: [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add segfault

[Scott Sipe]

pkg_add -r coredumps for me on a system built Mar 18, but not on one built
Mar 3.

Scott


From: "Joris Vandalon" <[EMAIL PROTECTED]>

> Hi there,
>
> it seemd that pkg_add coredumps while doing pkg_add -r $package
> pkg_add $package seems work ok.
> anyone else experiencing the same problem?
>
> -example-
>
> [EMAIL PROTECTED] strace]# pkg_add -r lftp
> Segmentation fault (core dumped)
> [EMAIL PROTECTED] strace]#
>
> -end example-
>
> Regards,
>
> Joris
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add

[Craig Rodrigues]

On Sun, Sep 15, 2002 at 07:56:09PM -0700, David O'Brien wrote:
> On Sun, Sep 15, 2002 at 09:47:28PM +, justin wrote:
> > >> SORRY IF THIS IS A REPEAT!
> > 
> > I have recompiled my base the past 2 days now, and pkg_add will segfault
> > signal 10 and core dumps after the second file transfer I can still use
> > it to install the package, but i have to run the command multiple times
> > depending on how many dependancies the port has. If it is only 1 file,
> > it works fine and without problems.
> 
> What is the exact outout with `pkg_add -v'.  Can you compile pkg_add with
> -g debugging and provide a trace?

I can reproduce the problem with pkg_add by doing:
pkg_add -v -r cvsupit
on a clean system.

This happens with the latest sources in /usr/src/usr.sbin/pkg_install/

-- 
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]


Script started on Wed Sep 18 00:12:02 2002
rincewind# gdb pkg_add

GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(gdb) r -v -r cvsupit
Starting program: /usr/src/usr.sbin/pkg_install/add/pkg_add -v -r cvsupit
looking up ftp.freebsd.org
connecting to ftp.freebsd.org:21
setting passive mode
opening data connection
initiating transfer
Fetching 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz...+CONTENTS

+COMMENT
+DESC
+INSTALL
+REQUIRE
+MTREE_DIRS
tar command returns 0 status
 Done.
Package 'cvsupit-3.1' depends on 'perl-5.6.1_8'.
setting passive mode
opening data connection
initiating transfer
Fetching 
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/All/perl-5.6.1_8.tbz...+CONTENTS

+COMMENT
+DESC
+INSTALL
+DISPLAY
+MTREE_DIRS
Attempting to record package into /var/db/pkg/perl-5.6.1_8..
Package perl-5.6.1_8 registered in /var/db/pkg/perl-5.6.1_8

Installation of Perl distribution is finished.  Please note, that since
Perl is also in the base system, this distribution will not be used by
default.

If you want this version of Perl to be used by default, please type

  use.perl port

Assuming that use.perl script (which was installed with the rest of the
Perl distribution) can be found in your PATH (you might have to type
`rehash' first, depending upon a shell you use), this action will
replace /usr/bin/perl and /usr/bin/suidperl with symbolic links to the
versions of these binaries in the Perl distribution.  This action will
also put some variables into your /etc/make.conf file, so that newly
installed ports (not packages!) will use new version of perl, and the
system upgrades from the source will not overwrite the changes made.

At any time you can also type

  use.perl system

if you wish to revert back to the system version of perl.

'perl-5.6.1_8' loaded successfully.
Package 'cvsupit-3.1' depends on 'imake-4.2.0_1'.

Program received signal SIGBUS, Bus error.
0x280a0792 in SSL_write () from /usr/lib/libssl.so.2
(gdb) where
#0  0x280a0792 in SSL_write () from /usr/lib/libssl.so.2
#1  0x28078129 in _fetch_write () from /usr/lib/libfetch.so.3
#2  0x280781de in _fetch_putln () from /usr/lib/libfetch.so.3
#3  0x28075d61 in fetchListHTTP () from /usr/lib/libfetch.so.3
#4  0x280771c4 in fetchListHTTP () from /usr/lib/libfetch.so.3
#5  0x2807743d in _ftp_request () from /usr/lib/libfetch.so.3
#6  0x28077591 in fetchXGetFTP () from /usr/lib/libfetch.so.3
#7  0x280783b0 in fetchXGet () from /usr/lib/libfetch.so.3
#8  0x280786e5 in fetchXGetURL () from /usr/lib/libfetch.so.3
#9  0x2807871f in fetchGetURL () from /usr/lib/libfetch.so.3
#10 0x0804f5ef in fileGetURL (
base=0x8056860 
"ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz";, 
spec=0x808d070 "imake-4.2.0_1") at file.c:199
#11 0x0804aa97 in pkg_do (
pkg=0x8056860 
"ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/cvsupit.tbz";) at 
perform.c:297
#12 0x0804a24b in pkg_perform (pkgs=0x8088c60) at perform.c:50
#13 0x08049faf in real_main (argc=-1077936975, argv=0xbfbffb9c) at main.c:215
#14 0x0804c96e in main (argc=673297920, argv=0xbfbffb8c) at pkgwrap.c:88
#15 0x08049b29 in _start ()
(gdb) quit
The program is running.  Exit anyway? (y or n) y
rincewind# ^Dexit

Script done on Wed Sep 18 00:13:37 2002

Re: pkg_add broken by POLA breakage in tar

[Bakul Shah]

I said:
> my guess is John Gilmore originally created gnu tar from
> reading of the man page.  If so, that would explain the
> difference.  I don't have the V7 sources so can't check but
> given that companies with the Unix licence (and the orig.
> sources) all do the same I believe the V7 man page just
> missed out some details.  I don't know what POSIX says.

I found the sources to V6, V7, various BSDs thanks to
www.tuhs.org (The Unix Heritage Society).  Boy! Was I wrong!

V7 tar does nothing special for root, neither do various BSDs
(I checked upto 4.3BSD-Reno -- I even compiled the reno tar
and verified that as root umask is obeyed).  I don't know at
which point root got special treatment in tar at various Unix
companies.

My apologies to Maxim and others for confusing them.
I plead (hopefully temporary) dementia!

-- bakul

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Garrett Wollman]

< said:

> If it were upto me I'd choose what POSIX says.

POSIX says to use pax(1).  There is no `tar' in POSIX.  (There is,
unfortunately, a cpio(1) in POSIX.)

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Bakul Shah]

> Well, OK, now I am really confused. So what should we be bound to? To
> the POLA (old GNU tar in 4.6-release and downward was not fully
> preserving permissions unless -p is specified, even when invoked by
> root)? Or to what other systems do? Bruce, what do you think?

Okay, I did some more research and now I am sorry I got
involved!

In addition to SUN, SGI says -p (restore permissions) is the
default when run as super-user.  HPUX says the same thing.
Further it says it conforms to SVID2, SVID3, XPG2, XPG3 (I
don't know if this is just boiler plate or actual conformance
-- I don't have the standards).  Ultrix is not clear.
Version 7 tar(1) man page is not entirely clear about this.

I checked out the earliest version of tar from FreeBSD cvs
and that indeed does not default to -p for the superuser.
my guess is John Gilmore originally created gnu tar from
reading of the man page.  If so, that would explain the
difference.  I don't have the V7 sources so can't check but
given that companies with the Unix licence (and the orig.
sources) all do the same I believe the V7 man page just
missed out some details.  I don't know what POSIX says.

{Net,Open}BSD & Linux do what gnu tar does.

If it were upto me I'd choose what POSIX says.  If it is
ambiguous and doesn't clearly specify the super user case,
I'd choose -p to be the default for root since a usability
point of view I really don't see the point of respecting
umask while extracting an archive --  a weird umask can
produce some very surprising results!  But clearly, for
portability one should always specify -p even as root and
scripts using tar should be fixed!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Bruce Evans]

On Thu, 1 Aug 2002, Maxim Sobolev wrote:

> Bakul Shah wrote:
> >
> > My recollection matches what Bruce says (and I have been
> > using unix since when version 7 was the latest and greatest).
> > At least the SUN OS 5.6 man page I could locate online says
> > this:
> >
> >  The o function modifier is only valid with the x function. p
> >  Restore the named files to their original modes, and ACLs if
> >  applicable, ignoring the present umask(1). This is the
> >  default behavior if invoked as super-user with the x
> >  function letter specified. If super-user, SETUID and sticky
> >  information are also extracted, and files are restored with
> >  their original owners and permissions, rather than owned
> >  by root.
> >
> > This superuser behavior is what allows one to use tar as an
> > archiving program.
>
> Well, OK, now I am really confused. So what should we be bound to? To
> the POLA (old GNU tar in 4.6-release and downward was not fully
> preserving permissions unless -p is specified, even when invoked by
> root)? Or to what other systems do? Bruce, what do you think?

I'm confused too.  I new about the special case for root from old (gnu
tar?) documentation and thought that FreeBSD tar had it.  But the
FreeBSD behaviour seems to be in the FSF version of old tar.  The
ChangeLogs for the current tar only go back to 1996 and don't seem
to cover any FSF changes related to this.

I think we should switch to the documented superuser behaviour as soon
as possible (immediately in -current).

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Bruce Evans]

On Thu, 1 Aug 2002, Maxim Sobolev wrote:

> Maxim Sobolev wrote:
> >
> > Maxim Sobolev wrote:
> > >
> > > Bruce Evans wrote:
> > > >
> > > > Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
> > > > thousands of user scripts that are no more careful than pkg_add) in
> > > > -current and RELENG_4:
> > >
> > > Are you sure? My own investigation at the time of the commit showed

Oops, apparently not ...

> > > that old tar shipped with FreeBSD, was adjusting permissions of
> > > extracting files when running as uid 0 according to current umask
> > > settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.
>
> OK, further investigation shows that the problem is likely that unlike
> the old one, the new tar doesn't preserve suid/sgid bits on
> extraction, and it is what probably needs to be fixed instead.
>
> >
> > Need evidence? Here it is:
> > ...

Sorry, I didn't test it at runtime.  I don't really like either changing
the Gnu/historical behaviour for root or preserving set*id bits while not
preserving other attributes, but since this seems have 10 years of
precedence in FreeBSD it doesn't break POLA.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Maxim Sobolev]

Bakul Shah wrote:
> 
> My recollection matches what Bruce says (and I have been
> using unix since when version 7 was the latest and greatest).
> At least the SUN OS 5.6 man page I could locate online says
> this:
> 
>  The o function modifier is only valid with the x function. p
>  Restore the named files to their original modes, and ACLs if
>  applicable, ignoring the present umask(1). This is the
>  default behavior if invoked as super-user with the x
>  function letter specified. If super-user, SETUID and sticky
>  information are also extracted, and files are restored with
>  their original owners and permissions, rather than owned
>  by root.
> 
> This superuser behavior is what allows one to use tar as an
> archiving program.

Well, OK, now I am really confused. So what should we be bound to? To
the POLA (old GNU tar in 4.6-release and downward was not fully
preserving permissions unless -p is specified, even when invoked by
root)? Or to what other systems do? Bruce, what do you think?

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Bakul Shah]

My recollection matches what Bruce says (and I have been
using unix since when version 7 was the latest and greatest).
At least the SUN OS 5.6 man page I could locate online says
this:

 The o function modifier is only valid with the x function. p
 Restore the named files to their original modes, and ACLs if
 applicable, ignoring the present umask(1). This is the
 default behavior if invoked as super-user with the x
 function letter specified. If super-user, SETUID and sticky
 information are also extracted, and files are restored with
 their original owners and permissions, rather than owned
 by root.

This superuser behavior is what allows one to use tar as an
archiving program.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Maxim Sobolev]

Maxim Sobolev wrote:
> 
> Maxim Sobolev wrote:
> >
> > Bruce Evans wrote:
> > >
> > > Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
> > > thousands of user scripts that are no more careful than pkg_add) in
> > > -current and RELENG_4:
> >
> > Are you sure? My own investigation at the time of the commit showed
> > that old tar shipped with FreeBSD, was adjusting permissions of
> > extracting files when running as uid 0 according to current umask
> > settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.

OK, further investigation shows that the problem is likely that unlike
the old one, the new tar doesn't preserve suid/sgid bits on
extraction, and it is what probably needs to be fixed instead.

> 
> Need evidence? Here it is:
> 
> # cvs co -D "10 months ago" src/gnu/usr.bin/tar
> [...]
> # cd src/gnu/usr.bin/tar
> # make
> [...]
> # mkdir foo
> # touch foo/bar
> # chmod 777 foo
> # chmod 777 foo/bar
> # ./tar cvf foo.tar foo
> foo/
> foo/bar
> # rm -rf foo
> # ./tar xvf foo.tar
> foo/
> foo/bar
> root@notebook# ls -l | grep foo
> drwxr-xr-x  2 root  wheel 512  1 âþú 19:01 foo/
> -rw-r--r--  1 root  wheel   10240  1 âþú 19:01 foo.tar
> root@notebook# ls -l foo
> total 0
> -rwxr-xr-x  1 root  wheel  0  1 âþú 19:01 bar*
> # umask
> 0022
> #
> 
> -Maxim
> 
> >
> > -Maxim
> >
> > >
> > > % RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> > > % Working file: extract.c
> > > % head: 1.4
> > > % branch:
> > > % locks: strict
> > > % access list:
> > > % symbolic names:
> > > %   RELENG_4: 1.4.0.2
> > > 
> > > %   TAR_v1_13_25: 1.1.1.1
> > > %   FSF: 1.1.1
> > > % keyword substitution: kv
> > > % total revisions: 6;   selected revisions: 6
> > > % description:
> > > % ...
> > > % 
> > > % revision 1.3
> > > % date: 2002/06/07 06:02:35;  author: sobomax;  state: Exp;  lines: +1 -1
> > > % Disabling automatic --same-owner option when running as uid 0 along with
> > > % the --same-permissions was an overkill, so put it back. This is consistent
> > > % with what our old tar did.
> > > %
> > > % Suggested by: dillon
> > > % 
> > > % revision 1.2
> > > % date: 2002/06/07 00:03:23;  author: sobomax;  state: Exp;  lines: +4 -0
> > > % IMO it was a quite ugly idea that if we are running as uid 0 then we can
> > > % safely ignore current umask(2) and assume that permissions should be set
> > > % right like in the archive. Not only it violates POLA, but introduces
> > >  ^
> > > % huge potential security vulnerability, particularly for ports, where
> > > % many popular archives come with 777 files and dirs.
> > > % 
> > >
> > > Actually, it is the change violates POLA, and breaks everything that
> > > depends on the historical and still documented behaviour.  (The man
> > > page even says that (almost) all permissions are restored even in the
> > > !root case (it says this indirectly by saying that all attributes are
> > > restored if possible and not mentioning the umask or root).  The info
> > > page is better.)
> > >
> > > This bug showed up as breakage in mutt.  mutt uses a setgid utility
> > > named mutt_dotlock to lock /var/mail/*, so it fails to download mail
> > > if mutt_dotlock's setgid bit is lost on extraction.  It is probably
> > > another bug that mutt_dotlock attempts to create a temporary file in
> > > /var/mail instead of using flock().
> > >
> > > "Fixes":
> > >
> > > (1) Change pkg_add and thousands of user scripts to use tar -p.  This
> > > may reopen security holes closed by respecting the umask.
> > >
> > > %%%
> > > Index: extract.c
> > > ===
> > > RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
> > > retrieving revision 1.33
> > > diff -u -2 -r1.33 extract.c
> > > --- extract.c   11 May 2002 04:17:54 -  1.33
> > > +++ extract.c   1 Aug 2002 10:26:10 -
> > > @@ -33,5 +33,5 @@
> > >  #define PUSHOUT(todir) /* push out string */ \
> > >  if (where_count > (int)sizeof(STARTSTRING)-1) { \
> > > -   strcat(where_args, "|tar --unlink -xf - -C "); \
> > > +   strcat(where_args, "|tar --unlink -pxf - -C "); \
> > > strcat(where_args, todir); \
> > > if (system(where_args)) { \
> > > %%%
> > >
> > > (2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
> > >
> > > %%%
> > > Index: extract.c
> > > ===
> > > RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> > > retrieving revision 1.4
> > > diff -u -2 -r1.4 extract.c
> > > --- extract.c   3 Jul 2002 12:44:31 -   1.4
> > > +++ extract.c   1 Aug 2002 10:44:34 -
> > > @@ -113,7 +113,5 @@
> > >  {
> > >we_are_root = geteuid () == 0;
> > > -#ifndef __FreeBSD__
> > >same_permission

Re: pkg_add broken by POLA breakage in tar

[Maxim Sobolev]

Maxim Sobolev wrote:
> 
> Bruce Evans wrote:
> >
> > Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
> > thousands of user scripts that are no more careful than pkg_add) in
> > -current and RELENG_4:
> 
> Are you sure? My own investigation at the time of the commit showed
> that old tar shipped with FreeBSD, was adjusting permissions of
> extracting files when running as uid 0 according to current umask
> settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.

Need evidence? Here it is:

# cvs co -D "10 months ago" src/gnu/usr.bin/tar
[...]
# cd src/gnu/usr.bin/tar
# make
[...]
# mkdir foo
# touch foo/bar
# chmod 777 foo
# chmod 777 foo/bar
# ./tar cvf foo.tar foo
foo/
foo/bar
# rm -rf foo
# ./tar xvf foo.tar
foo/
foo/bar
root@notebook# ls -l | grep foo
drwxr-xr-x  2 root  wheel 512  1 âþú 19:01 foo/
-rw-r--r--  1 root  wheel   10240  1 âþú 19:01 foo.tar
root@notebook# ls -l foo
total 0
-rwxr-xr-x  1 root  wheel  0  1 âþú 19:01 bar*
# umask
0022
#

-Maxim

> 
> -Maxim
> 
> >
> > % RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> > % Working file: extract.c
> > % head: 1.4
> > % branch:
> > % locks: strict
> > % access list:
> > % symbolic names:
> > %   RELENG_4: 1.4.0.2
> > 
> > %   TAR_v1_13_25: 1.1.1.1
> > %   FSF: 1.1.1
> > % keyword substitution: kv
> > % total revisions: 6;   selected revisions: 6
> > % description:
> > % ...
> > % 
> > % revision 1.3
> > % date: 2002/06/07 06:02:35;  author: sobomax;  state: Exp;  lines: +1 -1
> > % Disabling automatic --same-owner option when running as uid 0 along with
> > % the --same-permissions was an overkill, so put it back. This is consistent
> > % with what our old tar did.
> > %
> > % Suggested by: dillon
> > % 
> > % revision 1.2
> > % date: 2002/06/07 00:03:23;  author: sobomax;  state: Exp;  lines: +4 -0
> > % IMO it was a quite ugly idea that if we are running as uid 0 then we can
> > % safely ignore current umask(2) and assume that permissions should be set
> > % right like in the archive. Not only it violates POLA, but introduces
> >  ^
> > % huge potential security vulnerability, particularly for ports, where
> > % many popular archives come with 777 files and dirs.
> > % 
> >
> > Actually, it is the change violates POLA, and breaks everything that
> > depends on the historical and still documented behaviour.  (The man
> > page even says that (almost) all permissions are restored even in the
> > !root case (it says this indirectly by saying that all attributes are
> > restored if possible and not mentioning the umask or root).  The info
> > page is better.)
> >
> > This bug showed up as breakage in mutt.  mutt uses a setgid utility
> > named mutt_dotlock to lock /var/mail/*, so it fails to download mail
> > if mutt_dotlock's setgid bit is lost on extraction.  It is probably
> > another bug that mutt_dotlock attempts to create a temporary file in
> > /var/mail instead of using flock().
> >
> > "Fixes":
> >
> > (1) Change pkg_add and thousands of user scripts to use tar -p.  This
> > may reopen security holes closed by respecting the umask.
> >
> > %%%
> > Index: extract.c
> > ===
> > RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
> > retrieving revision 1.33
> > diff -u -2 -r1.33 extract.c
> > --- extract.c   11 May 2002 04:17:54 -  1.33
> > +++ extract.c   1 Aug 2002 10:26:10 -
> > @@ -33,5 +33,5 @@
> >  #define PUSHOUT(todir) /* push out string */ \
> >  if (where_count > (int)sizeof(STARTSTRING)-1) { \
> > -   strcat(where_args, "|tar --unlink -xf - -C "); \
> > +   strcat(where_args, "|tar --unlink -pxf - -C "); \
> > strcat(where_args, todir); \
> > if (system(where_args)) { \
> > %%%
> >
> > (2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
> >
> > %%%
> > Index: extract.c
> > ===
> > RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> > retrieving revision 1.4
> > diff -u -2 -r1.4 extract.c
> > --- extract.c   3 Jul 2002 12:44:31 -   1.4
> > +++ extract.c   1 Aug 2002 10:44:34 -
> > @@ -113,7 +113,5 @@
> >  {
> >we_are_root = geteuid () == 0;
> > -#ifndef __FreeBSD__
> >same_permissions_option += we_are_root;
> > -#endif
> >same_owner_option += we_are_root;
> >xalloc_fail_func = extract_finish;
> > %%%
> >
> > Bruce
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add broken by POLA breakage in tar

[Maxim Sobolev]

Bruce Evans wrote:
> 
> Revs.1.2-1.3 of tar/src/extract.c break pkg_add (not to mention probably
> thousands of user scripts that are no more careful than pkg_add) in
> -current and RELENG_4:

Are you sure? My own investigation at the time of the commit showed
that old tar shipped with FreeBSD, was adjusting permissions of
extracting files when running as uid 0 according to current umask
settings, so that IMO 1.2-1.3 actually restored POLA, not broke it.

-Maxim

> 
> % RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> % Working file: extract.c
> % head: 1.4
> % branch:
> % locks: strict
> % access list:
> % symbolic names:
> %   RELENG_4: 1.4.0.2
> 
> %   TAR_v1_13_25: 1.1.1.1
> %   FSF: 1.1.1
> % keyword substitution: kv
> % total revisions: 6;   selected revisions: 6
> % description:
> % ...
> % 
> % revision 1.3
> % date: 2002/06/07 06:02:35;  author: sobomax;  state: Exp;  lines: +1 -1
> % Disabling automatic --same-owner option when running as uid 0 along with
> % the --same-permissions was an overkill, so put it back. This is consistent
> % with what our old tar did.
> %
> % Suggested by: dillon
> % 
> % revision 1.2
> % date: 2002/06/07 00:03:23;  author: sobomax;  state: Exp;  lines: +4 -0
> % IMO it was a quite ugly idea that if we are running as uid 0 then we can
> % safely ignore current umask(2) and assume that permissions should be set
> % right like in the archive. Not only it violates POLA, but introduces
>  ^
> % huge potential security vulnerability, particularly for ports, where
> % many popular archives come with 777 files and dirs.
> % 
> 
> Actually, it is the change violates POLA, and breaks everything that
> depends on the historical and still documented behaviour.  (The man
> page even says that (almost) all permissions are restored even in the
> !root case (it says this indirectly by saying that all attributes are
> restored if possible and not mentioning the umask or root).  The info
> page is better.)
> 
> This bug showed up as breakage in mutt.  mutt uses a setgid utility
> named mutt_dotlock to lock /var/mail/*, so it fails to download mail
> if mutt_dotlock's setgid bit is lost on extraction.  It is probably
> another bug that mutt_dotlock attempts to create a temporary file in
> /var/mail instead of using flock().
> 
> "Fixes":
> 
> (1) Change pkg_add and thousands of user scripts to use tar -p.  This
> may reopen security holes closed by respecting the umask.
> 
> %%%
> Index: extract.c
> ===
> RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/extract.c,v
> retrieving revision 1.33
> diff -u -2 -r1.33 extract.c
> --- extract.c   11 May 2002 04:17:54 -  1.33
> +++ extract.c   1 Aug 2002 10:26:10 -
> @@ -33,5 +33,5 @@
>  #define PUSHOUT(todir) /* push out string */ \
>  if (where_count > (int)sizeof(STARTSTRING)-1) { \
> -   strcat(where_args, "|tar --unlink -xf - -C "); \
> +   strcat(where_args, "|tar --unlink -pxf - -C "); \
> strcat(where_args, todir); \
> if (system(where_args)) { \
> %%%
> 
> (2) Restore standard gnu tar behaviour by backing out extract.c revs 1.2-1.3.
> 
> %%%
> Index: extract.c
> ===
> RCS file: /home/ncvs/src/contrib/tar/src/extract.c,v
> retrieving revision 1.4
> diff -u -2 -r1.4 extract.c
> --- extract.c   3 Jul 2002 12:44:31 -   1.4
> +++ extract.c   1 Aug 2002 10:44:34 -
> @@ -113,7 +113,5 @@
>  {
>we_are_root = geteuid () == 0;
> -#ifndef __FreeBSD__
>same_permissions_option += we_are_root;
> -#endif
>same_owner_option += we_are_root;
>xalloc_fail_func = extract_finish;
> %%%
> 
> Bruce

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add problems, and garbage at end of dist tarballs

[Juergen Lock]

In article <[EMAIL PROTECTED]> you write:
>
>Core was generated by `pkg_add'.
>Program terminated with signal 10, Bus error.
>Reading symbols from /usr/lib/libfetch.so.3...(no debugging symbols
>found)...
>done.
>Reading symbols from /usr/lib/libmd.so.2...(no debugging symbols
>found)...done.
>Reading symbols from /usr/lib/libc.so.5...(no debugging symbols
>found)...done.
>Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
>found)...
>done.
>#0  0x8049b24 in free ()
>(gdb) bt
>#0  0x8049b24 in free ()
>#1  0x3 in ?? ()
>#2  0x8049695 in free ()
>(gdb)
>
>[...]
Here is the backtrace built with -g:

(gdb) r foo
Starting program: /usr/src/usr.sbin/pkg_install/add/./pkg_add foo

Program received signal SIGBUS, Bus error.
0x8049b24 in main (argc=2, argv=0xbfbffb8c) at main.c:192
192 packagesite[0] = '\0';
(gdb) bt
#0  0x8049b24 in main (argc=2, argv=0xbfbffb8c) at main.c:192
#1  0x8049695 in _start ()
(gdb) 

 And this fixes it (packagesite was used unitialized):

Index: /usr/src/usr.sbin/pkg_install/add/main.c
@@ -78,6 +78,7 @@
 char *cp, *packagesite, *remotepkg = NULL, *ptr;
 static char temppackageroot[MAXPATHLEN];
 
+packagesite = temppackageroot;
 start = argv;
 while ((ch = getopt(argc, argv, Options)) != -1) {
switch(ch) {

 The second thing, while unpacking the srcdist i got:

bash# cat /mnt/home/ftp/pub/FreeBSD/5.0-20010909-CURRENT/src/susbin.* |(cd /usr/src && 
tar xfvzk - )
...
usr.sbin/zic/WWW.htm
usr.sbin/zic/ialloc.c
usr.sbin/zic/private.h
usr.sbin/zic/scheck.c
usr.sbin/zic/zdump.8
usr.sbin/zic/zdump.c
usr.sbin/zic/zic.8
usr.sbin/zic/zic.c
usr.sbin/zic/zdump/

gzip: stdin: decompression OK, trailing garbage ignored
usr.sbin/zic/zdump/Makefile
usr.sbin/zic/zic/
usr.sbin/zic/zic/Makefile
tar: child returned status 2

 which might explain sysinstall giving an error after every dist:

DEBUG: wait for gunzip returned status of -1

(and so it asked whether it should retry loading the dist every time)
That was during the (ftp) install of 5.0-20010909-CURRENT.

 Greetings,
Juergen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: pkg_add -r broken

[Dag-Erling Smorgrav]

"David O'Brien" <[EMAIL PROTECTED]> writes:
> Are others seeing that ``pkg_add -r foo'' is broken?

Found the bug, there'll be a fix within an hour.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message