Bug#514016: options for fixing
* Bdale Garbee (bd...@gag.com) [090922 19:14]: > On Thu, 2009-02-05 at 18:20 +0100, Thomas Viehmann wrote: > > > just as an exercise what might be done to fix this: > > It would seem that the options are > > - not fix it (for now), > > - find something in current tar that works (I didn't), > > - switch off tar, > > - try to do something with tar > > (new upstream - vs. release: ugh - has a "apply to symlink target" > >--transform flag, but that also might need post-processing of > >symlinks at end of bootstrapping), > > - try to do some ld-preload(?) trickery for changing the way symlinks > > are read, > > - try to find some way to chroot before calling tar, one possibility > > would be copying required files to some temp CWD, make tar look there > > for the libraries, chrooting to the target and calling tar from (the > > unchanged) CWD, > > - add chroot option to tar (see patch). > > How about just fixing the offending package to use a relative symlink, > like /lib64 -> lib? This is well within policy since they're adjacent > objects in the same directory, and is less likely to break things or be > a pain to maintain over time than any of the options above. I can't > think of any negative consequence to this change, offhand? I don't see a case where a package needs a absolute symlink. If there is no use case, it'd be easy to just stop such packages in dak from entering the archive. Cheers, Andi -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: Bug#514015: Bug#514016: options for fixing
On Fri, Feb 06, 2009 at 10:55:18AM +0100, Thomas Viehmann wrote: > On 2009-02-06 09:57:36.00 Raphael Hertzog wrote: > > Try it with dpkg --root=/target/dir/ … > From looking at the code, it does the right thing. No, it does not. | $ dpkg-deb -c ../test.deb | drwxr-x--- waldi/waldi 0 2009-02-07 17:09 ./ | drwxr-x--- waldi/waldi 0 2009-02-07 17:09 ./lib64/ | -rw-r- waldi/waldi 5 2009-02-07 17:09 ./lib64/test | $ l -ad lib* | drwxr-x--- 2 waldi waldi 4096 7. Feb 17:09 lib/ | lrwxrwxrwx 1 waldi waldi4 7. Feb 17:09 lib64 -> /lib/ | $ sudo dpkg --root . -i ../test.deb | (Reading database ... 3 files and directories currently installed.) | Preparing to replace test 1 (using ../test.deb) ... | Unpacking replacement test ... | Setting up test (1) ... | $ l lib*/test /lib/test | -rw-r- 1 waldi waldi 5 7. Feb 17:09 lib64/test | -rw-r- 1 waldi waldi 5 7. Feb 17:09 /lib/test Bastian -- Well, Jim, I'm not much of an actor either. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
On 2009-02-06 09:57:36.00 Raphael Hertzog wrote: > On Thu, 05 Feb 2009, Thomas Viehmann wrote: > > > What would dpkg do with the symlinks in the the unpack phase? > > > > I have not tested it, but I would venture the same thing (calling tar, > > ergo having the same problem) from when I last looked at it. > > dpkg does not call tar, it has it own tar implementation (which explains > why we don't support yet POSIX tar archives inside .deb). I'm not sure how > it behaves in the situation that matters for this bug. > > Try it with dpkg --root=/target/dir/ … Thanks for stepping in to correct me here. dpkg does have its own tar, only dpkg-deb calls tar. > Try it with dpkg --root=/target/dir/ … >From looking at the code, it does the right thing. Kind regards T. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
On Thu, 05 Feb 2009, Thomas Viehmann wrote: > > What would dpkg do with the symlinks in the the unpack phase? > > I have not tested it, but I would venture the same thing (calling tar, > ergo having the same problem) from when I last looked at it. dpkg does not call tar, it has it own tar implementation (which explains why we don't support yet POSIX tar archives inside .deb). I'm not sure how it behaves in the situation that matters for this bug. Try it with dpkg --root=/target/dir/ … Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
Hi, thanks for your replies. Again, this is mostly because I needed some idle occupation and am not into sudoku. Apologies for presenting it a way that looked like a proposal. Bdale Garbee wrote: > How about just fixing the offending package to use a relative symlink, > like /lib64 -> lib? This is well within policy since they're adjacent > objects in the same directory, and is less likely to break things or be > a pain to maintain over time than any of the options above. I can't > think of any negative consequence to this change, offhand? Well, having 1000 maintainers do the right thing is difficult, as proven by the release process. > Adding a Debian-specific option to tar would certainly not be my first > choice. Other options do exist, my list probably is not exhaustive, but I would think that they cost a lot of code with a lot of opportunity to add bugs where things work now and it might be interesting to have an upper bound for how involved a minimal fix is. Thinking on a larger scale, what we actually want to do here is unpack a tarball into a chroot. I venture that this is a reasonable use case of tar and that it might just be possible to try to have upstream agree to have such an option in principle so that there is a plan to get rid of the debian-specificity of the option. Bastian Blank wrote: >> - switch off tar, > I intend to replace tar with a custom unpack routine in cdebootstrap. TBH, I'm not that impressed by the implementation of ar (or a subset) in dpkg and am not sure that reimplementing tar extraction it is a good path to take when I would think that an option for tar to do the right thing (whether internally munging symlinks when resolving paths or using chroot) might have a general use beyond bootstrapping Debian systems. >> - try to do something with tar >> (new upstream - vs. release: ugh - has a "apply to symlink target" >>--transform flag, but that also might need post-processing of >>symlinks at end of bootstrapping), > > What would dpkg do with the symlinks in the the unpack phase? I have not tested it, but I would venture the same thing (calling tar, ergo having the same problem) from when I last looked at it. >> - try to do some ld-preload(?) trickery for changing the way symlinks >> are read, > fakechroot have to do this someway, but I was unable to grok that code > yet. Well, you'd have to intercept all the relevant calls (for dereferencing/reading symlinks). Seems doable, but IMO tar would be the better place. But if the masses want funny business, so be it. ... >> - add chroot option to tar (see patch). > This is a root only option. Yes. It was my impression that (c)debootstrap are supposed to be called by root. At least I always used to call them as root when I was a developer. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
On Thu, 2009-02-05 at 18:20 +0100, Thomas Viehmann wrote: > just as an exercise what might be done to fix this: > It would seem that the options are > - not fix it (for now), > - find something in current tar that works (I didn't), > - switch off tar, > - try to do something with tar > (new upstream - vs. release: ugh - has a "apply to symlink target" >--transform flag, but that also might need post-processing of >symlinks at end of bootstrapping), > - try to do some ld-preload(?) trickery for changing the way symlinks > are read, > - try to find some way to chroot before calling tar, one possibility > would be copying required files to some temp CWD, make tar look there > for the libraries, chrooting to the target and calling tar from (the > unchanged) CWD, > - add chroot option to tar (see patch). How about just fixing the offending package to use a relative symlink, like /lib64 -> lib? This is well within policy since they're adjacent objects in the same directory, and is less likely to break things or be a pain to maintain over time than any of the options above. I can't think of any negative consequence to this change, offhand? Adding a Debian-specific option to tar would certainly not be my first choice. Bdale -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
Hi,
just as an exercise what might be done to fix this:
It would seem that the options are
- not fix it (for now),
- find something in current tar that works (I didn't),
- switch off tar,
- try to do something with tar
(new upstream - vs. release: ugh - has a "apply to symlink target"
--transform flag, but that also might need post-processing of
symlinks at end of bootstrapping),
- try to do some ld-preload(?) trickery for changing the way symlinks
are read,
- try to find some way to chroot before calling tar, one possibility
would be copying required files to some temp CWD, make tar look there
for the libraries, chrooting to the target and calling tar from (the
unchanged) CWD,
- add chroot option to tar (see patch).
It would seem that in terms of total invasiveness, the last option is
minimal, but it might be unwise to add options without consulting
upstream (however, it once upstream agrees to have an option with a
given spec, one could implement that locally).
Of course, the patch introduces new strings (translator-:( ), but they
only shown with the new option.
But then, this is just an idea, I'm sure you'll come up with a good, and
probably better solution.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
reverted:
diff -u tar-1.20/src/list.c tar-1.20/src/list.c
--- tar-1.20/src/list.c
+++ tar-1.20/src/list.c
@@ -72,6 +72,11 @@
name_gather ();
open_archive (ACCESS_READ);
+ if (chroot_option)
+ {
+ sys_chroot(chroot_option);
+ }
+
do
{
prev_status = status;
diff -u tar-1.20/debian/changelog tar-1.20/debian/changelog
--- tar-1.20/debian/changelog
+++ tar-1.20/debian/changelog
@@ -1,3 +1,10 @@
+tar (1.20-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Implement --chroot option for extraction.
+
+ -- Thomas Viehmann Thu, 05 Feb 2009 17:32:49 +0100
+
tar (1.20-1) unstable; urgency=low
* new upstream version
only in patch2:
unchanged:
--- tar-1.20.orig/src/system.c
+++ tar-1.20/src/system.c
@@ -24,6 +24,11 @@
#if MSDOS
+void
+sys_chroot (char* dir)
+{
+}
+
bool
sys_get_archive_stat (void)
{
@@ -120,6 +125,21 @@
static struct stat archive_stat; /* stat block for archive file */
+void
+sys_chroot (char* dir)
+{
+ if (chroot(dir) < 0)
+{
+ int e = errno;
+ FATAL_ERROR ((0, e, _("Cannot chroot to %s"), dir));
+}
+ if (chdir("/") < 0)
+{
+ int e = errno;
+ FATAL_ERROR ((0, e, _("Cannot chdir to '/' after chroot to %s"), dir));
+}
+}
+
bool
sys_get_archive_stat (void)
{
only in patch2:
unchanged:
--- tar-1.20.orig/src/tar.c
+++ tar-1.20/src/tar.c
@@ -252,6 +252,7 @@
CHECK_DEVICE_OPTION,
CHECKPOINT_OPTION,
CHECKPOINT_ACTION_OPTION,
+ CHROOT_OPTION,
DELAY_DIRECTORY_RESTORE_OPTION,
HARD_DEREFERENCE_OPTION,
DELETE_OPTION,
@@ -613,6 +614,8 @@
{"add-file", ARGP_KEY_ARG, N_("FILE"), 0,
N_("add given FILE to the archive (useful if its name starts with a dash)"), GRID+1 },
+ {"chroot", CHROOT_OPTION, N_("DIR"), 0,
+ N_("chroot to directory DIR for extraction"), GRID+1 },
{"directory", 'C', N_("DIR"), 0,
N_("change to directory DIR"), GRID+1 },
{"files-from", 'T', N_("FILE"), 0,
@@ -1590,6 +1593,10 @@
args->version_control_string = arg;
break;
+case CHROOT_OPTION:
+ chroot_option = arg;
+ break;
+
case DELAY_DIRECTORY_RESTORE_OPTION:
delay_directory_restore_option = true;
break;
only in patch2:
unchanged:
--- tar-1.20.orig/src/common.h
+++ tar-1.20/src/common.h
@@ -141,6 +141,9 @@
/* Print a message if not all links are dumped */
GLOBAL int check_links_option;
+/* Chroot option value. */
+GLOBAL char const *chroot_option;
+
/* Patterns that match file names to be excluded. */
GLOBAL struct exclude *excluded;
@@ -293,6 +296,7 @@
/* Specified value or pattern. */
GLOBAL const char *volume_label_option;
+
/* Other global variables. */
@@ -700,6 +704,7 @@
/* Module system.c */
+void sys_chroot (char* dir);
void sys_detect_dev_null_output (void);
void sys_save_archive_dev_ino (void);
void sys_drain_input_pipe (void);
only in patch2:
unchanged:
