FUSE su Mac grazie a Google

Il colosso di Mountain View rilascia un'implementazione di FUSE - Filesytem in User Space - per il sistema operativo Mac OS X
di Andrea Bai pubblicata il 15 Gennaio 2007, alle 16:58 nel canale AppleGoogleMac OS X
Il colosso di Mountain View rilascia un'implementazione di FUSE - Filesytem in User Space - per il sistema operativo Mac OS X
di Andrea Bai pubblicata il 15 Gennaio 2007, alle 16:58 nel canale Apple
16 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infose mi scarico il codice di HFS, lo modifico in modo tale da far apparire che sono sempre root (ad esempio), lo compilo e lo faccio funzionare da fuse... ho accesso a tutto il FS da root?
è una cosa che mi sono sempre chiesto... i filesystem funzionano con dei permessi ma alla fine se tu prendi gli stessi algoritmi (o ne riproduci altri che facciano la stessa cosa ovviamente) "tralasciando" la questione permessi... bypassi i permessi?
Fai prima: parti da MacOS 9 su un mac che te lo consente... e addio permessi!
Per fare questo però devi avere un accesso fisico alla macchina.
Se vuoi l'HD inviolabile anche con un accesso fisico DEVI criptare i dati, non c'è OS e filesystem che tenga. Cioè usare FileVault nel caso di OSX.
es. (in fstab)
/dev/sda1 /mountpoint ntfs-3g defaults,.......
o da linea di comando (root)
mount -t ntfs3g /dev/... /mountpoint -o options...
se mi scarico il codice di HFS, lo modifico in modo tale da far apparire che sono sempre root (ad esempio), lo compilo e lo faccio funzionare da fuse... ho accesso a tutto il FS da root?
Se puoi avere accesso in scrittura al disco raw, allora puoi fare tranquillamente una cosa del genere; ma normalmente un account non privilegiato NON ha tale livello d'accesso.
Altrimenti, se entri da un altro OS (es. con un live cd) di solito puoi tranquillamente bypassare le protezioni senza doverti modificare l'HFS. I diritti di accesso ad un certo file su un filesystem sono normalmente letti dal filesystem, ma imposti a livello di kernel (almeno sugli FS non criptati); se tu cambi il kernel facendo il boot con un altro os, o usando un modulo che ignori tali diritti, puoi farci quello che vuoi.
Per questo, se hai un pc 'pubblico' che vuoi sia completamente sicuro, i passi sono molti, es. devi impostare una configurazione di boot rigida (boot sempre dal primo hd) e una password del bios così come del bootloader, devi mettere qualche sigillo/sistema di intrusion alert per impedire che qualcuno possa aprire il case senza che tu te ne accorga, ecc.
Spero di aver chiarito i tuoi dubbi!
Anche io sarei interessato a saperlo...
basta usare ntfs-3g invece che ntfs per montare l'unità. Se poi c'è un problema di diritti non saprei aiutarvi, visto che non ho mai usato moltissimo i Mac, ma su Linux non ci sono grandi problemi.
Occhio che l'unità dev'essere pulita (=smontata correttamente con una chiusura di sistema regolare, non spenta dopo un crash o dopo un suspend/hibernate), altrimenti viene montata forzatamente in readonly.
Se avete problemi in scrittura, potreste provare a settare in maniera manuale il parametro umask o usare il force, anche se può essere rischioso.
qui ci sono le altre opzioni:
http://www.die.net/doc/linux/man/man8/ntfs-3g.8.html
controllate anche che l'utente che usate sia nel gruppo fuse.
due domande:
1) ma non mi serve solo la lettura?
2) ma se vado a lavorare a livello di I/O, ovvero allo stesso livello a cui lavora il driver, come fa l'os a bloccarmi? negli x86 suppongo che ciò avvenga a livello di processore, essendo che il codice user space viene eseguito in ring 3 (mmm non trovo un doc dove mi vengano dette le istruzioni che non si possono eseguire in ring 3... per capire se effettivamente basta, anche se suppongo di si, altrimenti a che serve?
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".