tar-Archiv auspacken mit extra passwd/group
Marc Haber
ich möchte gerne ein tar auspacken, das ein komplettes "Image" eines
Linux-Systems enthält, und daraus ein chroot bauen. In diesem tar sind
Dateiowner/group natürlich so vergeben, wie sie in dem Quellsystem in
/etc/passwd oder /etc/group waren. Nach dem Auspacken wird dann für
das chroot ein komplett neues /etc/passwd und /etc/group in den Tree
hineingeklatscht.
Packe ich das tar mit --numeric-owner aus, passen die uids/gids nach
dem Tausch des /etc/passwd und /etc/group nicht mehr; wenn ich das tar
ohne --numeric-owner auspacke, bekomme ich die usernamen-uid und
gruppennamen-gid-Zuordnung des Wirtssystems, die natürlich auch nicht
zum tar passen.
Eine Funktion, mit der man tar beim Auspacken ein eigenes passwd und
ein eigenes group-File vorwerfen kann, habe ich nicht gefunden.
Gibt es noch einen anderen Trick, dieses Problem zu lösen, oder muss
man wirklich das diff zwischen den "alten" und den "neuen" uids/gids
bilden und mit find, xargs und chown operieren?
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Tim Landscheidt
> ich m�chte gerne ein tar auspacken, das ein komplettes "Image" eines
> Linux-Systems enth�lt, und daraus ein chroot bauen. In diesem tar sind
> Dateiowner/group nat�rlich so vergeben, wie sie in dem Quellsystem in
> /etc/passwd oder /etc/group waren. Nach dem Auspacken wird dann f�r
> das chroot ein komplett neues /etc/passwd und /etc/group in den Tree
> hineingeklatscht.
> Packe ich das tar mit --numeric-owner aus, passen die uids/gids nach
> dem Tausch des /etc/passwd und /etc/group nicht mehr; wenn ich das tar
> ohne --numeric-owner auspacke, bekomme ich die usernamen-uid und
> gruppennamen-gid-Zuordnung des Wirtssystems, die nat�rlich auch nicht
> zum tar passen.
> Eine Funktion, mit der man tar beim Auspacken ein eigenes passwd und
> ein eigenes group-File vorwerfen kann, habe ich nicht gefunden.
> Gibt es noch einen anderen Trick, dieses Problem zu l�sen, oder muss
> man wirklich das diff zwischen den "alten" und den "neuen" uids/gids
> bilden und mit find, xargs und chown operieren?
Hmmm, nur /etc/{passwd,group} auspacken, Image nach /tmp ko-
pieren, dann chroot und den Rest entpacken? Oder eigene In-
tervalle je System f�r uids/gids vorsehen (wenn das Image
noch ver�nderlich ist)?
Tim
Christian Weisgerber
> Packe ich das tar mit --numeric-owner aus, passen die uids/gids nach
> dem Tausch des /etc/passwd und /etc/group nicht mehr; wenn ich das tar
> ohne --numeric-owner auspacke, bekomme ich die usernamen-uid und
> gruppennamen-gid-Zuordnung des Wirtssystems, die natï¿œrlich auch nicht
> zum tar passen.
Mit bsdtarￜ eine mtree-Beschreibung ohne uid/gid aus dem Archiv
erstellen und dann im Chroot diese Beschreibung nochmal ï¿œber den
Dateibaum laufen lassen. Sowas in dieser Art (ungetestet):
bsdtar -cf - --format mtree --options !uid,!gid @archiv.tar |
chroot /bla bsdtar -xpf -
ￜ) http://code.google.com/p/libarchive/
--
Christian "naddy" Weisgerber na...@mips.inka.de
Marc Haber
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Packe ich das tar mit --numeric-owner aus, passen die uids/gids nach
>> dem Tausch des /etc/passwd und /etc/group nicht mehr; wenn ich das tar
>> ohne --numeric-owner auspacke, bekomme ich die usernamen-uid und
>> zum tar passen.
>
>Mit bsdtar¹ eine mtree-Beschreibung ohne uid/gid aus dem Archiv
>erstellen und dann im Chroot diese Beschreibung nochmal über den
>Dateibaum laufen lassen. Sowas in dieser Art (ungetestet):
>
>bsdtar -cf - --format mtree --options !uid,!gid @archiv.tar |
> chroot /bla bsdtar -xpf -
Das sieht gut aus, wobei es mir irgendwie nicht in den Kram passt,
dass ich mich extra nochmal durch die 120 MB Input-Tar durchfräsen
muss, nur um die user- und gruppennamen herausziehen zu können. Und
--options kennt mein bsdtar 2.6.2 (aus Debian unstable) nicht.
Marc Haber
>> man wirklich das diff zwischen den "alten" und den "neuen" uids/gids
>> bilden und mit find, xargs und chown operieren?
>
>Hmmm, nur /etc/{passwd,group} auspacken, Image nach /tmp ko-
>pieren, dann chroot und den Rest entpacken?
Dann muss ich mich mit den ganzen Libraries im chroot abkämpfen, weil
tar ja dynamisch gelinkt ist. Würde ich gerne vermeiden wenn das
ginge.
>Oder eigene In-
>tervalle je System für uids/gids vorsehen (wenn das Image
>noch veränderlich ist)?
Dann würd ich eher die Systeme gleichschalten, würde mir aber gerne
die Flexibilität erhalten.
Marc Haber
>Mit bsdtar¹ eine mtree-Beschreibung ohne uid/gid aus dem Archiv
>erstellen und dann im Chroot diese Beschreibung nochmal über den
>Dateibaum laufen lassen.
bsdtar hat eine --chroot-Option, aber irgendwie tut das leider nicht
so, wie ich mir das vorstelle:
|$ < $INFILE bunzip2 | sudo bsdtar --list --file - --verbose | grep spool/exim
|drwxr-x--- 0 Debian-exim Debian-exim 0 Mar 17 13:19 mnt/var/var/spool/exim4/
|$ grep Debian-exim /etc/passwd
|Debian-exim:x:103:103::/var/spool/exim4:/bin/false
|$ grep Debian-exim zgserver/etc/passwd
|Debian-exim:x:102:102::/var/spool/exim4:/bin/false
|$ < $INFILE bunzip2 | sudo bsdtar --extract --file - --directory zgserver --chroot --exclude etc/passwd --exclude etc/group
|$ grep Debian-exim zgserver/etc/passwd
|Debian-exim:x:102:102::/var/spool/exim4:/bin/false
|$ ls -lnd zgserver/var/spool/exim4
|drwxr-x--- 2 103 103 4.0K 2009-03-17 13:19 zgserver/var/spool/exim4/
|$
Ich dachte immer, in einem tarfile stünden die symbolischen user- und
gruppennamen und tar würde sich beim auspacken an das lokale
/etc/passwd und /etc/groups halten? Laut strace chrooted sich das tar
recht früh, wie kommt dann die uid 103 da her?
Sven Joachim
> na...@mips.inka.de (Christian Weisgerber) wrote:
>>Mit bsdtar� eine mtree-Beschreibung ohne uid/gid aus dem Archiv
>>erstellen und dann im Chroot diese Beschreibung nochmal �ber den
>>Dateibaum laufen lassen.
>
> bsdtar hat eine --chroot-Option, aber irgendwie tut das leider nicht
> so, wie ich mir das vorstelle:
>
> |$ < $INFILE bunzip2 | sudo bsdtar --list --file - --verbose | grep spool/exim
> |drwxr-x--- 0 Debian-exim Debian-exim 0 Mar 17 13:19 mnt/var/var/spool/exim4/
> |$ grep Debian-exim /etc/passwd
> |Debian-exim:x:103:103::/var/spool/exim4:/bin/false
> |$ grep Debian-exim zgserver/etc/passwd
> |Debian-exim:x:102:102::/var/spool/exim4:/bin/false
> |$ < $INFILE bunzip2 | sudo bsdtar --extract --file - --directory zgserver --chroot --exclude etc/passwd --exclude etc/group
> |$ grep Debian-exim zgserver/etc/passwd
> |Debian-exim:x:102:102::/var/spool/exim4:/bin/false
> |$ ls -lnd zgserver/var/spool/exim4
> |drwxr-x--- 2 103 103 4.0K 2009-03-17 13:19 zgserver/var/spool/exim4/
> |$
>
> Ich dachte immer, in einem tarfile st�nden die symbolischen user- und
> gruppennamen
Sofern das Archiv nicht mit der Option "--numeric-owner" erzeugt wurde,
ja. Die User- und Gruppennummern stehen _immer_ drin.
> und tar w�rde sich beim auspacken an das lokale /etc/passwd und
> /etc/groups halten?
Das nicht. Als anst�ndiges Programm verwendet tar die �blichen
Libc-Funktionen getpwnam(3), getpwuid(3), getgrnam(3) und getgrgid(3),
anstatt die Dateien selbst zu parsen.
> Laut strace chrooted sich das tar
> recht fr�h, wie kommt dann die uid 103 da her?
Vermutlich aus der /etc/passwd, falls du nicht gerade NIS oder LDAP
verwendest. ;-) Ich wei� auch nicht so recht, wozu die Option �--chroot�
�berhaupt gut sein soll; sinnvoll erscheint sie mir nur in Verbindung
mit �-P�, um zu vermeiden, dass Dateien au�erhalb des angegebenen
Verzeichnisses entpackt werden.
Sven
Helmut Hullen
Du meintest am 11.09.09:
> Ich dachte immer, in einem tarfile st�nden die symbolischen user- und
> gruppennamen
Vielleicht.
Beim Einpacken l�sst sich mit der Option --numeric-owner auch erreichen,
dass die IDs genommen werden.
> und tar w�rde sich beim auspacken an das lokale
> /etc/passwd und /etc/groups halten?
Ist so vor-eingestellt, mit der Auspack-Option -o (--no-same-owner).
Lies Dir mal in aller Ruhe die vielen Optionen bei
pinfo tar (notfalls: info tar)
durch; "All Options", "Option Summary"
Viele Gruesse
Helmut
"Ubuntu" - an African word, meaning "Slackware is too hard for me".
Sven Joachim
> Hallo, Marc,
>
> Du meintest am 11.09.09:
>
>> Ich dachte immer, in einem tarfile st�nden die symbolischen user- und
>> gruppennamen
>
> Vielleicht.
> Beim Einpacken l�sst sich mit der Option --numeric-owner auch erreichen,
> dass die IDs genommen werden.
s/die IDs/nur die IDs/
>> und tar w�rde sich beim auspacken an das lokale
>> /etc/passwd und /etc/groups halten?
>
> Ist so vor-eingestellt, mit der Auspack-Option -o (--no-same-owner).
Diese Option f�hrt dazu, dass alle ausgepackten Dateien dem Superuser
geh�ren. Nicht gerade das, was Marc will.
Sven
Marc Haber
>Lies Dir mal in aller Ruhe die vielen Optionen bei
>
> pinfo tar (notfalls: info tar)
>
>durch; "All Options", "Option Summary"
Warum soll ich die Dokumentation von GNU tar lesen wenn ich
offensichtlich an dieser Stelle mit bsdtar arbeite, weil ich die
Option --chroot benutze?
Eventuell könnte es die Blamage für Dich ein wenig reduzieren wenn Du
wenigstens die Frage lesen würdest bevor Du unqualifiziert
herumblubberst, ich bin kein Berufsschüler im ersten Ausbildungsjahr.
Marc Haber
>Am 11.09.2009 um 09:06 schrieb Marc Haber:
>> na...@mips.inka.de (Christian Weisgerber) wrote:
>>>Mit bsdtar¹ eine mtree-Beschreibung ohne uid/gid aus dem Archiv
>>>Dateibaum laufen lassen.
>>
>> bsdtar hat eine --chroot-Option, aber irgendwie tut das leider nicht
>> so, wie ich mir das vorstelle:
>>
>> |$ < $INFILE bunzip2 | sudo bsdtar --list --file - --verbose | grep spool/exim
>> |drwxr-x--- 0 Debian-exim Debian-exim 0 Mar 17 13:19 mnt/var/var/spool/exim4/
>> |$ grep Debian-exim /etc/passwd
>> |Debian-exim:x:103:103::/var/spool/exim4:/bin/false
>> |$ grep Debian-exim zgserver/etc/passwd
>> |Debian-exim:x:102:102::/var/spool/exim4:/bin/false
>> |$ < $INFILE bunzip2 | sudo bsdtar --extract --file - --directory zgserver --chroot --exclude etc/passwd --exclude etc/group
>> |$ grep Debian-exim zgserver/etc/passwd
>> |Debian-exim:x:102:102::/var/spool/exim4:/bin/false
>> |$ ls -lnd zgserver/var/spool/exim4
>> |drwxr-x--- 2 103 103 4.0K 2009-03-17 13:19 zgserver/var/spool/exim4/
>> |$
>>
>> gruppennamen
>
>Sofern das Archiv nicht mit der Option "--numeric-owner" erzeugt wurde,
>ja. Die User- und Gruppennummern stehen _immer_ drin.
Ok, mir war neu, dass --numeric-owner auch beim Einpacken eine
Funktion hat.
>> und tar würde sich beim auspacken an das lokale /etc/passwd und
>> /etc/groups halten?
>
>Das nicht. Als anständiges Programm verwendet tar die üblichen
>Libc-Funktionen getpwnam(3), getpwuid(3), getgrnam(3) und getgrgid(3),
>anstatt die Dateien selbst zu parsen.
Ja, und die greifen auf /etc/passwd und /etc/group zu, und das sind
die innerhalb des auszupackenden directories, da bsdtar --chroot sich
vor dem Auspacken selbst in das Verzeichnis hineinchrooted. Das lässt
sich auch aus einem strace des Prozesses ablesen.
>> Laut strace chrooted sich das tar
>> recht früh, wie kommt dann die uid 103 da her?
>
>Vermutlich aus der /etc/passwd,
Wie kommt der Prozess nachdem er sich chrooted hat an das /etc/passwd
des Wirtssystems heran?
>Ich weiß auch nicht so recht, wozu die Option »--chroot«
>überhaupt gut sein soll; sinnvoll erscheint sie mir nur in Verbindung
>mit »-P«, um zu vermeiden, dass Dateien außerhalb des angegebenen
>Verzeichnisses entpackt werden.
Im konkreten Fall ist es im Prinzip genau das was ich von ihm will,
hier ein (großzügig gekürzter) Auszug aus dem strace:
|chdir("zgserver") = 0
|geteuid32() = 0
|chroot(".") = 0
|mkdir("mnt/var/var/spool/exim4", 0750) = 0
|umask(022) = 0
|lchown32("mnt/var/var/spool/exim4", 103, 103) = 0
Aber interessanterweise sehe ich in diesem strace auch nirgends, dass
das bsdtar überhaupt versucht, irgend eine Datei namens /etc/passwd zu
öffnen. Der nimmt wohl blind die numerischen IDs, obwohl
--numeric-owner weder beim ein- noch beim Auspacken gesetzt war.
Helmut Hullen
Du meintest am 11.09.09:
>> Lies Dir mal in aller Ruhe die vielen Optionen bei
>>
>> pinfo tar (notfalls: info tar)
>>
>> durch; "All Options", "Option Summary"
> Warum soll ich die Dokumentation von GNU tar lesen wenn ich
> offensichtlich an dieser Stelle mit bsdtar arbeite, weil ich die
> Option --chroot benutze?
> Eventuell k�nnte es die Blamage f�r Dich ein wenig reduzieren wenn Du
> wenigstens die Frage lesen w�rdest bevor Du unqualifiziert
> herumblubberst, ich bin kein Berufssch�ler im ersten Ausbildungsjahr.
F�hlst Du Dich jetzt wohler?
Die Frage (eigentlich waren es - soweit ich das habe erkennen k�nnen -
mehrere Fragen) habe ich gelesen.
Nach Deiner Art zu antworten habe ich zwar M�he, Dich nicht als
"Berufssch�ler im 1. Ausbildungsjahr" einzustufen, aber wenn's Dir
wohltut ...
Sven Joachim
> Sven Joachim <sven...@gmx.de> wrote:
>>Am 11.09.2009 um 09:06 schrieb Marc Haber:
>>>
>>> Ich dachte immer, in einem tarfile st�nden die symbolischen user- und
>>> gruppennamen
>>
>>Sofern das Archiv nicht mit der Option "--numeric-owner" erzeugt wurde,
>>ja. Die User- und Gruppennummern stehen _immer_ drin.
>
> Ok, mir war neu, dass --numeric-owner auch beim Einpacken eine
> Funktion hat.
>
>>> und tar w�rde sich beim auspacken an das lokale /etc/passwd und
>>> /etc/groups halten?
>>
>>Das nicht. Als anst�ndiges Programm verwendet tar die �blichen
>>Libc-Funktionen getpwnam(3), getpwuid(3), getgrnam(3) und getgrgid(3),
>>anstatt die Dateien selbst zu parsen.
>
> Ja, und die greifen auf /etc/passwd und /etc/group zu, und das sind
> die innerhalb des auszupackenden directories, da bsdtar --chroot sich
> vor dem Auspacken selbst in das Verzeichnis hineinchrooted. Das l�sst
> sich auch aus einem strace des Prozesses ablesen.
>
>>> Laut strace chrooted sich das tar
>>> recht fr�h, wie kommt dann die uid 103 da her?
>>
>>Vermutlich aus der /etc/passwd,
Ahem, das war lat�rnich falsch...
> Wie kommt der Prozess nachdem er sich chrooted hat an das /etc/passwd
> des Wirtssystems heran?
...gar nicht, also kommt die 103 wohl aus dem Archiv selbst.
> Aber interessanterweise sehe ich in diesem strace auch nirgends, dass
> das bsdtar �berhaupt versucht, irgend eine Datei namens /etc/passwd zu
> �ffnen. Der nimmt wohl blind die numerischen IDs, obwohl
> --numeric-owner weder beim ein- noch beim Auspacken gesetzt war.
Ich sehe hier, dass nach dem chroot versucht wird, die
/etc/nsswitch.conf zu �ffnen, welche nicht existiert. Anscheinend
schlagen die glibc-Funktionen sofort fehl, wenn sie mangels
nsswitch.conf nicht wissen, was sie tun sollen.
Sven
Marc Haber
>Die Frage (eigentlich waren es - soweit ich das habe erkennen können -
>mehrere Fragen) habe ich gelesen.
Aber nicht verstanden.
Christian Weisgerber
> >bsdtar -cf - --format mtree --options !uid,!gid @archiv.tar |
> > chroot /bla bsdtar -xpf -
>
> Und --options kennt mein bsdtar 2.6.2 (aus Debian unstable) nicht.
Schauen, was passiert, wenn man uid/gid drin lï¿œsst?
uid/gid mit sed entfernen?
Marc Haber
>Am 11.09.2009 um 12:50 schrieb Marc Haber:
>> Aber interessanterweise sehe ich in diesem strace auch nirgends, dass
>> öffnen. Der nimmt wohl blind die numerischen IDs, obwohl
>> --numeric-owner weder beim ein- noch beim Auspacken gesetzt war.
>
>Ich sehe hier, dass nach dem chroot versucht wird, die
>schlagen die glibc-Funktionen sofort fehl, wenn sie mangels
>nsswitch.conf nicht wissen, was sie tun sollen.
Allerdings hilft es auch nicht, vor dem Auspacken eine sinnvolle
nsswitch.conf in das chroot zu kopieren.
Und laut Manpage von nsswitch.conf gibt es Defaults, und zwar diese
hier:
| passwd: compat
| group: compat
| shadow: compat
|
| hosts: dns [!UNAVAIL=return] files
| networks: nis [NOTFOUND=return] files
| ethers: nis [NOTFOUND=return] files
| protocols: nis [NOTFOUND=return] files
| rpc: nis [NOTFOUND=return] files
| services: nis [NOTFOUND=return] files
Und danach fallen haufenweise Leseversuche von Libraries, unter
anderem auch libnss_compat.so.2, auf die Nase. Irgendwie ist das
chroot-Feature von bsdtar nicht so wirklich ausgereift und/oder
durchdacht.
Daran scheint es zu liegen, denn wenn ich das tarfile ein zweites Mal
"obendrüber" auspacke, stimmen die UIDs plötzlich.
So ein <censored>.
Christian Weisgerber
> Ich dachte immer, in einem tarfile stï¿œnden die symbolischen user- und
> gruppennamen und tar wï¿œrde sich beim auspacken an das lokale
> /etc/passwd und /etc/groups halten?
Es stehen die symbolischen und die numerischen Kennungen im Archiv.
Beim Auspacken versucht tar die symbolische Kennung aufzulï¿œsen;
scheitert das, verwendet er die numerische.
> Laut strace chrooted sich das tar recht frï¿œh, wie kommt dann die
> uid 103 da her?
Aus dem Archiv, weil die Auflï¿œsung gescheitert ist?
Aus dem Wirtssystem ï¿œber nscd oder vorher gelesen und gecachet?
Helmut Hullen
Du meintest am 11.09.09:
[...]
>>>>> Gibt es noch einen anderen Trick, dieses Problem zu l�sen, oder
>>>>> muss man wirklich das diff zwischen den "alten" und den "neuen"
>>>>> uids/gids bilden und mit find, xargs und chown operieren?
[...]
>>> Eventuell k�nnte es die Blamage f�r Dich ein wenig reduzieren wenn
>>> Du wenigstens die Frage lesen w�rdest bevor Du unqualifiziert
>>> herumblubberst, ich bin kein Berufssch�ler im ersten
>>> Ausbildungsjahr.
>> Die Frage (eigentlich waren es - soweit ich das habe erkennen k�nnen
>> - mehrere Fragen) habe ich gelesen.
> Aber nicht verstanden.
Sch�n, wie Du mit weiteren unbewiesenen und unbeweisbaren
Unterstellungen nachkartest (und dabei so rein zuf�llig Deine eigenen
vorangegangenen Beitr�ge l�schst).
Deine beiden Fragen waren "gibt es noch einen anderen Trick" sowie "muss
man wirklich ...". Beide Fragen habe ich verstanden. Mag sein, dass Dir
meine Antwort darauf nicht gef�llt - that's life!
Marc Haber
>> gruppennamen und tar würde sich beim auspacken an das lokale
>> /etc/passwd und /etc/groups halten?
>
>Es stehen die symbolischen und die numerischen Kennungen im Archiv.
>scheitert das, verwendet er die numerische.
Und das scheitert, weil er nach dem chroot-Call noch versucht,
Libraries nachzuladen. Wenn ich ihm das /lib aus dem Wirtssystem
vorher in das spätere chroot kopiere, funktioniert das.
Und leider hilft LD_LIBRARY_PATH auch nicht wirklich, denn wenn ich
ihm das /lib nach chroot/libtemp kopiere, sucht
LD_LIBRARY_PATH="/libtemp" bsdtar --chroot
fleißig nach Libraries in /libtemp bis zum chroot und ab da sucht er
dann nur noch in /lib.
Und ich scheue mich irgendwie davor, Gefahr zu laufen, dass nach dem
Auspacken des Archives Libraries in /lib hängen bleiben, die da gar
nicht hin gehören.
>> Laut strace chrooted sich das tar recht früh, wie kommt dann die
>> uid 103 da her?
>
>Aus dem Archiv, weil die Auflösung gescheitert ist?
Vermutlich. Gibt es da keine Warnung?
>Aus dem Wirtssystem über nscd oder vorher gelesen und gecachet?
nscd, negativ, gecached, hoffentlich nicht.
Marc Haber
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> >bsdtar -cf - --format mtree --options !uid,!gid @archiv.tar |
>> > chroot /bla bsdtar -xpf -
>>
>> Und --options kennt mein bsdtar 2.6.2 (aus Debian unstable) nicht.
>
>uid/gid mit sed entfernen?
Das hab ich noch nicht probiert, ich finde den Ansatz mit --chroot
allerdings schöner.
Christian Weisgerber
> >Es stehen die symbolischen und die numerischen Kennungen im Archiv.
> >Beim Auspacken versucht tar die symbolische Kennung aufzulï¿œsen;
> >scheitert das, verwendet er die numerische.
>
> Und das scheitert, weil er nach dem chroot-Call noch versucht,
> Libraries nachzuladen.
Du brauchst einen statisch gelinkten bsdtar.
> >Aus dem Archiv, weil die Auflï¿œsung gescheitert ist?
>
> Vermutlich. Gibt es da keine Warnung?
Nein.
Und die Kombination aus ï¿œbertragung der symbolischen Kennung und
Rï¿œckgriff auf die numerische kann unangenehme Auswirkungen haben.
Man ï¿œberlege, was zwischen diesen beiden Systemen beim Auspacken
eines Archivs geschieht:
kinnison:1000 worsel:1000
worsel:1001 tregonsee:1001
Marc Haber
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> >Es stehen die symbolischen und die numerischen Kennungen im Archiv.
>> >scheitert das, verwendet er die numerische.
>>
>> Und das scheitert, weil er nach dem chroot-Call noch versucht,
>> Libraries nachzuladen.
>
>Du brauchst einen statisch gelinkten bsdtar.
Oder einen bsdtar, der vernünftig mit Libaries umgeht. An dieser
Stelle ein speziell gebautes Binary zu benutzen ist schlicht eine
Nichtoption. Oder gibt es ein Tool, dass die benötigten Libraries
nachträglich zu einem dynamischen Binary hinzulinked und als Ergebnis
ein statisches Binary erzeugt, das man danach wieder wegwerfen kann
und das keine Entwicklerwerkzeuge auf dem System erfordert?
Marc Haber
>na...@mips.inka.de (Christian Weisgerber) wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>> >Es stehen die symbolischen und die numerischen Kennungen im Archiv.
>>> >Beim Auspacken versucht tar die symbolische Kennung aufzulösen;
>>> >scheitert das, verwendet er die numerische.
>>>
>>> Und das scheitert, weil er nach dem chroot-Call noch versucht,
>>> Libraries nachzuladen.
>>
>>Du brauchst einen statisch gelinkten bsdtar.
>
>Oder einen bsdtar, der vernünftig mit Libaries umgeht.
An dieser Stelle wird das auch nicht helfen, weil der bsdtar seine
Libs explizit mit dlopen nachlädt. Sowas kann man doch nicht statisch
linken, oder?
Christian Weisgerber
> >>Du brauchst einen statisch gelinkten bsdtar.
> >
> >Oder einen bsdtar, der vernï¿œnftig mit Libaries umgeht.
>
> An dieser Stelle wird das auch nicht helfen, weil der bsdtar seine
> Libs explizit mit dlopen nachlï¿œdt.
bsdtar an sich macht das nicht. Den Effekt hast du vermutlich deiner
libc zu verdanken, die Backends fï¿œr getpwnam() als Module nachlï¿œdt.
> Sowas kann man doch nicht statisch linken, oder?
Nein, aber vielleicht ist deine statische libc, falls es sowas auf
deinem System gibt, so gebaut, dass sie die Module beinhaltet oder
es wird nur eine Minimalfunktionalitï¿œt unterstï¿œtzt (z.B. getpwent
fï¿œr /etc/passwd, aber nicht fï¿œr LDAP).
Marc Haber
>ich möchte gerne ein tar auspacken, das ein komplettes "Image" eines
>Linux-Systems enthält, und daraus ein chroot bauen. In diesem tar sind
>Dateiowner/group natürlich so vergeben, wie sie in dem Quellsystem in
>/etc/passwd oder /etc/group waren. Nach dem Auspacken wird dann für
>das chroot ein komplett neues /etc/passwd und /etc/group in den Tree
>hineingeklatscht.
>
>Packe ich das tar mit --numeric-owner aus, passen die uids/gids nach
>dem Tausch des /etc/passwd und /etc/group nicht mehr; wenn ich das tar
>ohne --numeric-owner auspacke, bekomme ich die usernamen-uid und
>gruppennamen-gid-Zuordnung des Wirtssystems, die natürlich auch nicht
>zum tar passen.
>
>Eine Funktion, mit der man tar beim Auspacken ein eigenes passwd und
>ein eigenes group-File vorwerfen kann, habe ich nicht gefunden.
Mit Hilfe dieses Threads habe ich jetzt eine - ekelhafte - Lösung
gefunden:
| # bsdtar --extract --chroot honors the symbolic owner/group names
| # only if /etc/nsswitch.conf and /lib is present
| mkdir -p $TARGETDIR/etc
| cp $SOURCEDIR/etc/passwd $SOURCEDIR/etc/group $TARGETDIR/etc
| cp /etc/nsswitch.conf $TARGETDIR/etc
| mkdir -p $TARGETDIR/lib
| SUBDIR="unpack"
| find /lib -maxdepth 1 -xtype f -print0 | xargs --no-run-if-empty --null cp --no-clobber --target-directory=$TARGETDIR/lib
| # we add a prefix to keep the chroot's lib from interfering with the
| # /lib needed for bsdtar to function
| < $TARDIR/$DISTRI/$TARFILE bunzip2 | tardy -Remove_Prefix $DISTRI -Prefix $SUBDIR | bsdtar --extract --file - --directory $TARGETDIR --chroot
| # zap our helper files, move up what we unpacked to $TARGETDIR/unpack
| find $TARGETDIR -mindepth 1 -maxdepth 1 -name $SUBDIR -prune -o -print0 | xargs --null rm -rf
| mv $TARGETDIR/unpack/* $TARGETDIR/
| rmdir $TARGETDIR/unpack
Danke für Eure Hilfe. Ich hätte gerne eine weniger häßliche Lösung
gefunden.