tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Bug in pax affecting syspkgs

On Wed, 13 May 2009, Alan Barrett wrote:
> syspkgs make no use of @owner or @group.  Ownership and mode is encoded
> in the pax header of each file in the .tgz file.

I should have realised this. I knew that the sets don't need a PLIST because 
the pax archive can store all the meta information, and how do packages store 
files? In a pax archive.

Incidently, there is a bug in NetBSD's pax that affect syspkgs. When pax is 
pulling meta information from an mtree file, it gets the file permissions for 
hard links wrong. The mtree specs that we use for sets and syspkgs only have 
complete meta information for the first hard link to a file. For subsequent 
links, pax uses the mtree default meta information, 
instead of the meta information from the first hard link, which is wrong. This 
doesn't show up in the install sets, because the default mtree ownerships are 
set to group:wheel, which happens to be the right value, even though it was 
found the wrong way. syspkgs don't set any default meta information in the 
mtree spec, so pax has to use a default default, which is the meta 
information on the file system.

The result is that we get this

-r-xr-xr-x  1 root     wheel      22018 May 10 13:14 sbin/swapctl
-r-xr-xr-x  2 lloyd    wheel          0 May 10 13:14 sbin/swapon == 

instead of this

-r-xr-xr-x  1 root     wheel      22018 May 10 13:14 ./sbin/swapctl
-r-xr-xr-x  2 root     wheel          0 May 10 13:14 ./sbin/swapon 
== ./sbin/swapctl

Of course, once pax sets the second ownership during file extraction, we lose. 

I guess that means that there are two bugs on our pax. 1) We should store the 
right information in the archive, and 2) we shouldn't update the file's meta 
information when we are creating a hard link to it.

I'll file a PR.


Home | Main Index | Thread Index | Old Index