chroot: Keine Benutzerwechsel und -auflösung möglich

[Artimis]

Hallo @ *.

Ich bin gerade fröhlich am in die Tischkante beißen beim Versuch, unter linux-vserver eine chroot-Umgebung unter einem eingeschränkten Benutzer zum laufen zu bringen.

Dabei habe ich schlicht folgendes versucht:

sudo chroot /home/user/chroot su user -c "whoami"

Dies scheitert jedoch beim su in der chroot-Umgebung mit folgender Fehlermeldung:

su: Cannot determine your user name.

Also habe ich mich mal in die chroot eingeklinkt und ein bisschen probiert:

bash-4.1# whoami

whoami: cannot find name for user ID 0


bash-4.1# su user

su: Cannot determine your user name.


bash-4.1# sudo -u user

sudo: unknown uid: 0


bash-4.1# cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
ts3:x:5001:5001::/home/ts3:/bin/bash


bash-4.1# cat /etc/shadow

root:!:14637:0:99999:7:::
ts3:!:14690:0:99999:7:::


bash-4.1# cat /etc/group

root:x:0:
ts3:x:5001:


bash-4.1# cat /etc/nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis


bash-4.1# ls -la /etc

total 40
drwxr-xr-x  2    0    0 4096 Jan  4 14:30 .
drwxr-xr-x 10 5001 5001 4096 Jan  4 13:20 ..
-rw-r--r--  1    0    0   37 May 28  2009 fstab
-rw-r--r--  1    0    0   22 Jan  4 14:46 group
-rw-r--r--  1    0    0    7 Jul 11 23:03 hostname
-rwxr-xr-x  1    0    0  166 May 13  2010 hosts
-rw-r--r--  1    0    0   60 Jan  4 15:57 networks
-rw-r--r--  1    0    0  475 Jan  4 14:30 nsswitch.conf
-rw-r--r--  1    0    0   69 Jan  4 14:00 passwd
-rw-r--r--  1    0    0  210 Jan  4 11:00 resolv.conf
-rw-r--r--  1    0    0   51 Jan  4 14:33 shadow

Ich habe echt keine Ahnung, was da schief läuft.

Aufgesetzt habe ich das chroot-Verzeichnis für /dev mit Hardlinks und mkdirs, die restlichen Verzeichnisse mit einem simplen mkdir und im Falle von tmp mit chmod 1777. Die Verzeichnisse gehören root (bis auf das home-Verzeichnis von user). Und die nötigen bins habe ich einfach kopiert, die libs jeweils mit ldd ermittelt und ebenfalls kopiert.

Als Plattform dient ein linux-vserver.


Kann mir da wer einen Denkanstoß geben?
Vielen Dank im Voraus!

 

[Joe User]

Unabhängig von Deinem Problem: Hardlinks in ein Chroot machen dieses sinnfrei, da man über die Hardlinks bequem ausbrechen kann.

 

[Artimis]

Unabhängig von Deinem Problem: Hardlinks in ein Chroot machen dieses sinnfrei, da man über die Hardlinks bequem ausbrechen kann

Danke für den Hinweis!
Da unter linux-vserver aber wede rmknod noch mount laufen, muss ich mit diesem Risiko leben. Besser ein chroot mit diesem kleinen Leck als kein chroot.
Aus diesem Grund habe ich aber natürlich davon abgesehen, aus Bequemlichkeit und Sparsamkeit an Ressourcen Hardlinks zu den bins und libs zu erstellen, und habe diese statt dessen kopiert.

Aber schön, dass man hier aufpasst und nicht blind dem Fragesteller eine Lösung hinwirft, die zwar seine Frage beantwortet, jedoch weitsichtig alles andere als hilfreich ist.

 

[Cenic]

Wenn du den Prozeß unter strace startest, kannst du vielleicht sehen, was der Prozeß vor Ausgabe der Fehlermeldung probiert.

Ich würde aus dem Bauch auf eine fehlende /etc/nsswitch.conf oder die zugehörigen Bibliotheken /lib/libnss* tippen. Da die dynamisch geladen werden, sind die nämlich nicht mit ldd zu sehen.

 

[Artimis]

Hallo Cenic!
Danke für deine Antwort.

Die /etc/nsswitch.conf ist vorhanden und mit dem Inhalt im ersten Post gefüllt. Es ist gleich der erste Block beim Scrollen.

Ich habe nun einmal wie angeraten /lib/libnss* kopiert, erhalte jedoch immer noch obige Fehlermeldungen.

Beim strace su user ist mir aufgefallen, dass er sehr hartnäckig nach einer libnsl.so.1 sucht, die ich dann auch gleich kopierte.

Das Resultat ist eine neue Fehlermeldung: su: pam_start: error 26

Ein weiteres strace, ein weiteres Kopieren von /etc/localtime und /etc/pam.conf, neue Fehlermeldung: su: Permission denied

Ein weiteres strace: Das Verzeichnis /etc/pam.d fehlt ebenfalls. Kopiert und auch gleich die /etc/login.defs mitgenommen, neue Fehlermeldung: su: Module is unknown

Ah, natürlich. Die /etc/shells fehlt. Aber daran hapert es nicht, sondern an dem Verzeichnis /lib/security. Nach Kopieren nun endlich keine Fehlermeldung. Ein whoami sagt: user


Meine Güte, da habe ich richtig auf dem Schlauch gestanden. Wie das manchmal so ist, man sieht den Wald vor lauter Bäumen nicht. Danke, Cenic, dass du mich auf strace gebracht hast!


=> Problem gelöst!