Copie automatique de dépendance

Programmation
1

Bonjour à tous,

En tentant de mettre en place un chroot rssh (scp, sftp, rsync), je suis tombé sur ce tuto et ce snippet :

1. #!/bin/bash 2. install -D $1 $2$1 3. for i in `ldd $1 | grep -o '/[^[:space:]]*'`; do 4. if [ ! -e $2$i ]; then install -D $i $2$i; fi 5. done
L’un d’entre-vous pourrait-il commenter les lignes 3 et 4 de manière complète ?

Je ne comprends pas, par exemple, pourquoi - dans la seconde ligne - il y a deux fois “$1” ($1 correspond bien au premier argument fournit et $2 au second ?).

Autre question, quand je “ldd /bin/sh” (par exemple) :

linux-vdso.so.1 => (0x00007fff8cdff000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c2e921000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c2ecc1000)
Pourquoi la première ligne ne pointe-t-elle sur rien ?
Pourquoi la dernière n’a-t-elle pas de pointage du tout ?

Merci d’avance,
P.

2

1 question par fil, coupe ton ton post en deux et fait un autre fil pour ta deuxième question.

Sinon pour ta première question il y a 2 fois $1 car le premier dit quoi copier et le deuxième sous quel nom le copier. Le $2 étant le chemin ou le déposer.
Donc pour l’exemple

Tu vas avoir un nouveau répertoire «/home/sftp/usr/bin/sftp» avec tout ce qu’il faut à l’intérieur.

3

Bonjour,

Merci pour ta réponse.

Les deux questions sont liées. Je tente de comprendre comment fonctionne un script qui fait notamment du parsing mais je ne comprends pas l’output de la commande qu’il parse.

En effet, je réalise que c’est la commande chargée de copier le binaire avant que les dépendances ne soient copiées.

4

Pour la deuxième partie je ne saurais dire …

5

[quote=“PierRaw”]

Autre question, quand je “ldd /bin/sh” (par exemple) :

linux-vdso.so.1 => (0x00007fff8cdff000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c2e921000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c2ecc1000)
Pourquoi la première ligne ne pointe-t-elle sur rien ?
Pourquoi la dernière n’a-t-elle pas de pointage du tout ?

Merci d’avance,
P.[/quote]

ld-linux est le chargeur de programme: exemple

francois@portos:~$ cp /bin/ls /tmp francois@portos:~$ chmod -x /tmp/ls francois@portos:~$ ldd /tmp/ls linux-vdso.so.1 => (0x00007fff6fd89000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f812f455000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f812f24d000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007f812f043000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f812ecbc000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f812eab8000) /lib64/ld-linux-x86-64.so.2 (0x00007f812f696000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f812e89b000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007f812e696000) francois@portos:~$ /lib64/ld-linux-x86-64.so.2 ^C francois@portos:~$ cd /tmp francois@portos:/tmp$ /tmp/ls bash: /tmp/ls: Permission non accordée francois@portos:/tmp$ /lib64/ld-linux-x86-64.so.2 /tmp/ls bash Cache keyring-IdDQhZ orbit-francois pulse-PKdhtXMmr18n blueman-applet-1000 _CACHE_CLEAN_ ls pulse-LVVmxGT1ANuM ssh-EdYvfjtA3137 francois@portos:/tmp$ par contre

francois@portos:/tmp$ /lib/ld-linux.so.2 /tmp/ls /tmp/ls: error while loading shared libraries: /tmp/ls: wrong ELF class: ELFCLASS64 francois@portos:/tmp$ il espère un ELF 32 bits.
C’est pour cela que rendre un programme non executable n’est pas une protection, cette technique te permet de l’exécuter de toute façon.

Les librairies non précisées (linux-vdso.so.1) sont des implémentations optimisées pour accéder au noyau, c’est soit linux-gate, soit linux-vdso (à ma connaissance, il y en a peut être d’autre). J’interprète ça comme la méthode d’accès aux fonctions du noyau choisies par le chargeur.