Errore di 'dispositivo non configurato' di OpenBSD nell'ambiente chroot-ed


2

Ho fatto questa domanda su StackOverflow ma ho dato il commentare lì sembra che si adatti meglio qui.

Questo è quasi certamente un problema di configurazione del sistema: non hai impostato correttamente la prigione, piuttosto che una versione di Python. Puoi testarlo molto facilmente semplicemente vedendo cosa succede quando corri, per esempio, head -c16 / dev / urandom o dd if = / dev / urandom bs = 16 count = 1 dall'interno della prigione. Se ottieni lo stesso errore, vai a chiedere su SuperUser o ServerFault o su un altro forum generale Unix o OpenBSD. - abarnert

Ecco cosa ho fatto:

Voglio eseguire alcuni script cgi (scritti in Python) sul mio server OpenBSD. Dato che il server web su OpenBSD gira in una prigione, ho ricreato l'intera struttura della cartella (/ bin / dev / usr / usr / local / lib ecc. Ecc.) Ma sto ancora ricevendo '500 Errore interno del server' quando I ' Sto cercando di importare alcuni moduli Python che richiedono l'accesso a / dev / urandom device.

Ho creato i file speciali del dispositivo usando mknod.

ls -la /dev/*random
ls -la /dev/{null,zero}

Ho ottenuto il seguente risultato

crw-r--r--  1 root  wheel   45,   3 Sep 13 11:09 /dev/arandom
crw-r--r--  1 root  wheel   45,   0 Jul 15 19:02 /dev/random
crw-r--r--  1 root  wheel   45,   1 Jul 15 19:02 /dev/srandom
crw-r--r--  1 root  wheel   45,   2 Jul 15 19:02 /dev/urandom

e

crw-rw-rw-  1 root  wheel    2,   2 Sep 16 01:30 /dev/null
crw-rw-rw-  1 root  wheel    2,  12 Jul 15 19:02 /dev/zero

Così ho eseguito i seguenti comandi nella cartella / var / www / dev (il server web OpenBSD funziona in chroot -u www / var / www)

mknod -m 666 null c 2 2
mknod -m 666 zero c 2 12
mknod -m 644 random 45 0
mknod -m 644 srandom 45 1
mknod -m 644 urandom 45 2
mknod -m 644 arandom 45 3

Tuttavia, Python riporta ancora che il

OSError: [Errno 6] Device not configured '/dev/urandom'

Lo stesso codice funziona bene in un ambiente non chroot.

import os
import cgitb
cgitb.enable()

Dato il consiglio su StackOverflow corro

chroot -u www /var/www dd if=/dev/urandom bs=16 count=1

e ho ottenuto lo stesso risultato

dd: /dev/urandom: Device not configured

cioè è sicuramente un errore di configurazione. Qualcuno può far luce su dove posso sbagliare? Qualsiasi aiuto sarebbe veramente apprezzato!


1
Hai montato / dev al tuo ambiente chroot usando mount -o bind? Questa risposta ha una concisa panoramica del motivo per cui è necessario dev
jam

Ho provato a farlo ma OpenBSD non ha l'opzione bind... C'è un equivalente? Leggo in giro e apparentemente si potrebbe farlo con mount_null ma che è stato rimosso ... Posso usare mount -o sync /dev anziché?
TDrabas

1
Ho trovato il colpevole (parzialmente ...). Non è necessario montare il dispositivo. Inoltre, come ho detto prima, in OpenBSD non ho potuto trovare mount -o bind equivalente. Seguendo il consiglio dei commenti di questo sito è sufficiente per mknod (come ho fatto prima) e rimuovere nodev a partire dal /etc/fstab dove il sistema si monta \var. Anche se il mio script continua a non funzionare, non riporta più Dispositivo non configurato
TDrabas

1
Solo per finire - il _hashlib.so (chiamato da import cgitb ) dipende da una libreria condivisa libcrypto.so. Questo era il problema con il mio script non in esecuzione ... Grazie a tutti per il vostro aiuto!
TDrabas

Sono contento che tu abbia risolto il problema, scusa se ti ho portato in una buca del coniglio specifica per Linux :) Puoi postarla come risposta, ti permetterà di accettarla dopo un giorno o giù di lì credo.
jam

Risposte:


2

Ho trovato il colpevole.

Seguendo il consiglio dalla sezione commenti di questo sito è sufficiente per mknod (come ho fatto prima) e rimuovere nodev a partire dal /etc/fstab dove il sistema si monta /var. Rimuove il flag di "nessun dispositivo" /var.

Per far funzionare il mio script, dovevo finalmente copiare tutti gli oggetti condivisi di Python cgitb modulo (beh, infatti, _hashlib.so ) dipende da - vale a dire libcrypto.so.

Per trovare ciò che è tuo _hashlib.so dipende dalla corsa ldd _hashlib.so - Il mio si trova in /usr/local/lib/python2.7/lib-dynload/_hashlib.so. Nota: troverai questa libreria se OpenSSL è installato sul tuo sistema. Se non lo fai, _hashlib.so carichi ad es. _md5.so ecc. che può essere trovato solo se tu

  1. Non avere OpenSSL
  2. Configurato e costruito con Python --with-pydebug bandiera (controllare questa risposta per ulteriori dettagli)

Spero che questo ti aiuti!


-1

Ho avuto un problema simile con Django in FreeBSD e OPENBSD. Il mio problema era che il processo gunicorn era in esecuzione come root mentre gli script erano nella home / directory degli utenti esterni.

tl; dr - & gt; controlla se il processo è in esecuzione con l'utente giusto

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.