Debian Bug report logs - #17732
FIXED in NMU [was: dpkg suddnely has problems unpacking many .debs]

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Larry 'Daffy' Daffner" <vizzie@mail.airmail.net>

To: submit@bugs.debian.org

Subject: dpkg suddnely has problems unpacking many .debs

Date: Sun, 01 Feb 1998 18:00:31 -0600

Package: dpkg
Version: 1.4.0.20

After upgrading to dpkg 1.4.0.20, I suddenly have problems when
installing many previously uninstalled packages. For example:

Unpacking lesstif (from .../oldlibs/lesstif_0.82-4.deb) ...
dpkg: error processing debian/dists/unstable/main/binary-i386/oldlibs/lesstif_0.82-4.deb (--install):
 error setting ownership of symlink `usr/lib/libc5-compat/libMrm.so.0': No such file or directory
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 debian/dists/unstable/main/binary-i386/oldlibs/lesstif_0.82-4.deb
DPKG ERROR

Many other packages have encountered the exact same problem. It
appears as though the symbolic link is in the data.tar.gz ahead of the 
file it points to when this happens. This didn't happen with previous
versions of dpkg. The package can be installed, if the .deb is
unpacked with ar, and then the data.tar.gz unpacked by hand, then
trying to install the .deb.

-Larry
-- 
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  vizzie@airmail.net / http://web2.airmail.net/vizzie/
"I believe every human has a finite number of heartbeats. I don't intend to
 waste any of mine running around doing exercises."  --Neil Armstrong

Message #10 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: vizzie@airmail.net, 17732@bugs.debian.org

Subject: Re: Bug#17732: dpkg suddnely has problems unpacking many .debs

Date: Sun, 1 Feb 1998 16:56:21 -0800

Larry 'Daffy' Daffner wrote:
> Many other packages have encountered the exact same problem. It
> appears as though the symbolic link is in the data.tar.gz ahead of the 
> file it points to when this happens. This didn't happen with previous
> versions of dpkg. The package can be installed, if the .deb is
> unpacked with ar, and then the data.tar.gz unpacked by hand, then
> trying to install the .deb.

Are you sure you didn't upgrade to a 2.1.8x kernel as well? I thought 2.1
kernels were the cause of this problem.

-- 
see shy jo

Message #15 received at 17732@bugs.debian.org (full text, mbox, reply):

From: "Larry 'Daffy' Daffner" <vizzie@mail.airmail.net>

To: Joey Hess <joey@kitenet.net>

Cc: vizzie@airmail.net, 17732@bugs.debian.org

Subject: Re: Bug#17732: dpkg suddnely has problems unpacking many .debs

Date: Sun, 01 Feb 1998 19:33:53 -0600

>>>>> "JH" == Joey Hess <joey@kitenet.net> writes:

  JH> Larry 'Daffy' Daffner wrote:
  >> Many other packages have encountered the exact same problem. It
  >> appears as though the symbolic link is in the data.tar.gz ahead
  >> of the file it points to when this happens. This didn't happen
  >> with previous versions of dpkg. The package can be installed, if
  >> the .deb is unpacked with ar, and then the data.tar.gz unpacked
  >> by hand, then trying to install the .deb.

  JH> Are you sure you didn't upgrade to a 2.1.8x kernel as well? I
  JH> thought 2.1 kernels were the cause of this problem.

Oops, is that the problem? Nevermind then. I am running 2.1.84, so
that would be the problem. It just happened that the 2 events were
close together in time, so I thought that dpkg was at fault. My
mistake.

-Larry

-- 
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  vizzie@airmail.net / http://web2.airmail.net/vizzie/
	Clarke's Third Law:
	Any sufficiently advanced technology is indistinguishable from magic.

Message #20 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Juan Cespedes <cespedes@debian.org>

To: Larry 'Daffy' Daffner <vizzie@mail.airmail.net>

Cc: 17732@bugs.debian.org

Subject: Re: dpkg suddnely has problems unpacking many .debs

Date: Sun, 5 Apr 1998 16:40:19 +0200

	I think this is not a bug in dpkg, but in some versions of the
Linux kernel.

	Can this bug be closed?

	Thanks.

-- 
Juan Cespedes

Message #31 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Juan Cespedes <cespedes@debian.org>

To: control@bugs.debian.org

Cc: 10072@bugs.debian.org, 12617@bugs.debian.org, 13598@bugs.debian.org, 13892@bugs.debian.org, 14696@bugs.debian.org, 16091@bugs.debian.org, 16527@bugs.debian.org, 17732@bugs.debian.org

Subject: retitling fixed bugs

Date: Mon, 13 Jul 1998 22:58:30 +0200

retitle 10072 FIXED in NMU [was: dpkg: dpkg-source cannot unpack source]
retitle 12617 FIXED in NUM [was: dpkg: unchecked prompting in postinst]
retitle 13598 FIXED in NMU [was: dpkg-ftp should depend on `awk']
retitle 13892 FIXED in NMU [was: dpkg: should depend on awk]
retitle 14696 FIXED in NMU [was: Typo? in Debian packaging manual]
retitle 16091 FIXED in NMU [was: dpkg: dselect won't read Packages from sunsite]
retitle 16527 FIXED in NMU [was: link shared libs against other shared libs]
retitle 17732 FIXED in NMU [was: dpkg suddnely has problems unpacking many .debs]
stop

	Some of these bugs haven't really been fixed by a NMU: some of
them are not bugs, some have been fixed by an official release and
some have been fixed by other packages.  However, I think it's easier
to use the same title on all of them.

Comments:
10072 was fixed a lot of time ago
12617 is not a bug (the submitter agrees on this)
13598 and 13892 have already been fixed by base-files_1.7
16091 was probably a bug in sunsite's mirror; it's not a bug in dpkg
17732 was the "chown/lchown" bug in kernel 2.1.8x

-- 
Juan Cespedes

Message #40 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ian@davenant.greenend.org.uk>

To: 17732@bugs.debian.org

Subject: Kernel bug

Date: Sat, 13 Mar 1999 13:59:34 +0000 (GMT)

These bugs are due to the Linux kernel changing the semantics of
chown() without telling anyone ...

Ian.

Message #45 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Ian Jackson <ian@davenant.greenend.org.uk>, 17732@bugs.debian.org

Subject: Re: Bug#17732: Kernel bug

Date: Mon, 15 Mar 1999 00:40:39 -0800

Ian Jackson wrote:
> These bugs are due to the Linux kernel changing the semantics of
> chown() without telling anyone ...

Without telling anyone?

The change was publically announced to the usual places (kernel mailing
list) and has been common knowledge for months.

-- 
see shy jo

Message #50 received at 17732@bugs.debian.org (full text, mbox, reply):

From: kaih@khms.westfalen.de (Kai Henningsen)

To: 17732@bugs.debian.org

Subject: Re: Bug#17732: Kernel bug

Date: 16 Mar 1999 08:40:00 +0200

joey@kitenet.net (Joey Hess)  wrote on 15.03.99 in <19990315004039.A13157@kitenet.net>:

> Ian Jackson wrote:
> > These bugs are due to the Linux kernel changing the semantics of
> > chown() without telling anyone ...
>
> Without telling anyone?
>
> The change was publically announced to the usual places (kernel mailing
> list) and has been common knowledge for months.

The way I remember it, the problem with the old chown was that it changed  
the file pointed to by a symlink, not the symlink itself.

Beside the obvioue problem (no way to change symlink ownershape), this  
also makes for an easy security hole unless you're paranoid about it, and  
a hard one even *if* you're paranoid about it because there was no atomic  
way to check-if-link-then-chown.

Example:

    User has a private directory with a symlink to /etc/passwd.
    Admin, for some reason, wants to change User's uid.
    chown -R newuid /private/dir ...

So now, we have two versions of chown(), one which works on the file  
pointed to, and one which works on the symlink itself.

*If* this is a problem for anybody, then obviously the new behaviour is  
available under the old system call number.

The thing I don't understand, however, is *why* this would be a problem  
for dpkg. I see no reason why dpkg would want to chown() a symlink in a  
situation where it woule either be seriously bad if the symlink changed  
owner, or if the file pointed to didn't.

Could someone enlighten me?

MfG Kai

Message #55 received at 17732@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ian@davenant.greenend.org.uk>

To: 17732@bugs.debian.org

Subject: Re: Bug#17732: Kernel bug

Date: Sun, 21 Mar 1999 17:45:58 +0000 (GMT)

Kai Henningsen writes ("Bug#17732: Kernel bug"):
...
> The way I remember it, the problem with the old chown was that it changed  
> the file pointed to by a symlink, not the symlink itself.

No, the other way around.  chown() on a symlink used to change the link.

> So now, we have two versions of chown(), one which works on the file  
> pointed to, and one which works on the symlink itself.

The problem is that when lchown() was introduced, the meaning of
chown() was changed.  The existing syscall number was reused for the
new semantics.

...
> The thing I don't understand, however, is *why* this would be a problem  
> for dpkg. I see no reason why dpkg would want to chown() a symlink in a  
> situation where it woule either be seriously bad if the symlink changed  
> owner, or if the file pointed to didn't.
> 
> Could someone enlighten me?

Link ownership can be important eg in sticky directories.  Certainly
the system (including dpkg) should be able to distinguish the intended
link ownership from the target ownership.

However, the problem has now gone away because dpkg always uses lchown
now.

Ian.

Message #60 received at 17732@bugs.debian.org (full text, mbox, reply):

From: kaih@khms.westfalen.de (Kai Henningsen)

To: 17732@bugs.debian.org

Subject: Re: Bug#17732: Kernel bug

Date: 22 Mar 1999 21:43:00 +0200

ian@davenant.greenend.org.uk (Ian Jackson)  wrote on 21.03.99 in <14069.12374.847139.888723@anarres.relativity.greenend.org.uk>:

> Kai Henningsen writes ("Bug#17732: Kernel bug"):
> ...
> > The way I remember it, the problem with the old chown was that it changed
> > the file pointed to by a symlink, not the symlink itself.
>
> No, the other way around.  chown() on a symlink used to change the link.

Hmmm ... [ look at source (2.0.36 vs. 2.2.1) ] ... that seems correct.

> > So now, we have two versions of chown(), one which works on the file
> > pointed to, and one which works on the symlink itself.
>
> The problem is that when lchown() was introduced, the meaning of
> chown() was changed.  The existing syscall number was reused for the
> new semantics.

That however, seems to be false. Both from the source and from your  
claims, the old chown() did what the new lchown() does; the old chown() is  
#16, and the new lchown() is ... wait for it ... #16. (The new chown() is  
at #182.)

It is true that chown() was changed - for a very small number of  
experimental kernel revisions.

In other words, the problem was using a new feature of an experimental  
kernel that was still buggy, as such features tend to be.

> However, the problem has now gone away because dpkg always uses lchown
> now.

*And* because syscall #16 has the same semantics in 2.2.x as in 2.0.x,  
whatever it might have had for some 2.1.x kernels.

I think this wraps it up.

MfG Kai

Send a report that this bug log contains spam.