Newsgroup: it.comp.os.linux.sys
Titolo: ls linkato staticamente non funziona con ftp

Debian Woody, ftpd-ssl.
Dovendo chrootare un certo numero di utenti, mi trovo a dover inserire nella
home di ciascuno di loro una /bin contenente un ls, altrimenti gli utenti
rimangono ciechi.
Creando una coppia /bin + /lib e copiandoci tutti i file necessari
(eseguibile e librerie) funziona tutto bene; io pero' vorrei usare un solo
eseguibile, linkato staticamente, come del resto suggerisce anche la man
page di ftpd-ssl.
Mi sono scaricato i sorgenti delle fileutils e ho creato una versione
statica del file, che funziona egregiamente. Ho creato un hard link al file,
che ho messo un sola esecuzione (711) - cosi' come in sola esecuzione e'
l'ls originale, ed in sola esecuzione e' anche la cartella: devono
lanciarlo, non scaricarselo...
Risultato di tutto il lavoro: non vedo piu' i file quando faccio un ls via
ftp.
Rimettendo l'ls dinamico tutto funziona regolarmente.
Idee?
TIA,
*

 page di ftpd-ssl.
e' probabile che un link simbolico in chroot non funzioni ... in quanto 
puo' darsi che punti ad un path irragiungibile per l'utente (prova a 
fare un linnk a qualcos'altro, piuttosto che ls. Dopo lanci un ls e 
magari scoprirai che ti apparira' come brokne link.)
--
Massimiliano.

 un ls e magari scoprirai che ti apparira' come brokne link.)
Non e' un symlink, e' un *hard* link.
Se copio una shell nella ~/bin, mi chrooto li' dentro e lancio un ls vedo i
file regolarmente.
Ciaotutti,
*

 
Si ma se ti chrooti sei root.
i permessi di /bin o / come sono, nel chroot?
Max


Sono gli stessi che uso per l'ls linkato dinamicamente, che funziona. E ho
gia' provato a mettere 777 sia alla dir sia al file.
L'unica differenza tra i due file e' la dimensione (quello linkato
staticamente pesa un 600k in piu').
Ciaotutti,
*


OK, ora capisco sempre meno: lo stesso eseguibile, messo nella root vera al
posto di ls, funziona, anche per l'ftp, pero' continua a non funzionare per
utenti che non siano chrootati nella / effettiva...
Riassunto:
lrwxrwxrwx    1 root     root            9 May  4 17:02 ls -> ls.static
-rwx--x--x    2 root     root        43784 Mar 18  2002 ls.dynamic
-rwx--x--x    1 root     root       638524 May  4 17:02 ls.static
Questo e' vero sia per la / sia per la ~ (la home dell'utente che non e'
chrootato in /).
La / e' 755, la ~ e' 775; l'utente chrootato in / non e' root, e non e'
quindi owner della sua home; l'utente chrootato in ~ e' membro del gruppo
della sua home, ma non ne e' l'owner. La situazione e' quindi abbastanza
simile, semmai l'utente in ~ dovrebbe avere *piu'* permessi...
Se l'utente ha come home la / (e quindi e' chrootato in /), vede i file e
puo' operare tranquillamente; se invece ha come home una cartella diversa,
non vede niente.
Puo' ancora creare, modificare e cancellare file nella sua home (che e' 775,
quindi puo' scriverci in quanto membro del gruppo), ma l'ls fallisce.
Sta cosa mi sta tirando scemo...
Ciaotutti,
*

Risolto... ma non ci crederete mai.
Vuole /dev/null.
Se non c'e' una directory /dev, contenente il file speciale null, non va.
L'ho scoperto con un strace dell'eseguibile sulla macchina di sviluppo...
Lo apre, riceve un "not a directory" e a quanto pare non ci fa niente, ma se
non c'e' si ferma.
Vai a capire...
Ciaotutti,
*