Vraag Google Drive Access. ocamlfuse prima. Is het veilig?


Vandaag heb ik twee methoden geprobeerd om toegang te krijgen tot Google Drive-opslag in Ubuntu 17.04. Mijn bureaublad is XFCE4.

De eerste, met Gnome Online Accounts, werkt niet goed. Ik zie dezelfde prestatie- en toestemmingsproblemen in Thunar en Nautilus (er, Files). Ik volgde hier instructies:

http://www.webupd8.org/2016/03/use-gnome-318-google-drive-integration.html

Ik kan bestanden in Google Drive zien en ze hernoemen, maar 1) het staat niet toe dat bestanden worden verwijderd, verplaatst of gekopieerd in Bestandsbeheer, 2) het maakt geen interactie met de Terminal-bron, de bestandsnamen geven een lange versleutelde dingen, en 3) er zijn lange "hang" -tijden waarbij de bestandsbeheerder en de pop-upmenu's die hij maakt bevroren zijn.

De tweede methode die ik heb geprobeerd, een FUSE-gebaseerde tool genaamd google-drive-ocamlfuse, werkt prima! instructies:

http://www.omgubuntu.co.uk/2017/04/mount-google-drive-ocamlfuse-linux

Ze hebben gelijk. Dit is meer "performant".

De PPA biedt dat programma, het is niet langer nodig om het voor jezelf te compileren, en tot nu toe werkt het alleen maar. Ik kan de map koppelen en slagen in de volledige interactie met bestanden, zoals bekijken, hernoemen, verplaatsen en kopiëren. Al met al was het een grote overwinning.

Nu vraag ik me af ...

Vraag 1. Is dit veilig?

google-drive-ocamlfuse lijkt de authenticatie van Google 2-factoren te omzeilen. Hoe kan dat zijn? Toen ik de Gnome Drive-methode gebruikte, volgde het de authenticatie met twee factoren en stuurde ik een sms naar mijn telefoon. Is de computer bezig met het herinneren van de verificatie van de Gnome-sessie wanneer ik de CLI gebruik om te koppelen met ocamlfuse?

Vraag 2. Mogelijk om automatisch te ontkoppelen?

Er is een reëel gevaar dat ik zal vergeten te rennen fusermount -u op de Google Drive. Als ik de opschorting van de laptop automatisch zou kunnen ontkoppelen, zou dat goed zijn.

In eerdere ervaringen met sshf's merk ik dat als ik vergeet te fusermount -u te ontkoppelen, dan is het hele besturingssysteem erg traag na een onderbreking / hervatten. Het besturingssysteem probeert de verbinding met bestanden in het nu opgeheven bestandsysteem opnieuw tot stand te brengen).

Een ander ding dat het vermelden waard is. Het is niet zo eenvoudig om het Gnome-account op te ruimen. Ik wou dat ik dit gedeelte had begrepen voordat ik het probeerde. Gnome heeft veel pakketten geïnstalleerd en ik moest wat chique dansen om mijn Google-info in Gnome Online-account te plaatsen. Het is eenvoudig genoeg om de pakketten te verwijderen, maar het opschonen van de accountgegevens is niet automatisch. Ik heb hier advies voor gevonden:

Hoe Google virtueel mount-station te verwijderen van Ubuntu 16.04?

maar ik vrees dat ik nooit alle verborgen bestanden zal verwijderen.

Hier zijn alle pakketten die zijn binnengekomen tijdens dit Gnome-avontuur trouwens:

$ sudo apt-get install gnome-control-center gnome-online-accounts
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  apg dconf-cli dleyna-server gir1.2-ibus-1.0 gkbd-capplet gnome-bluetooth
  gnome-control-center-data gnome-settings-daemon gnome-user-share ibus
  libcolord-gtk1 libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-3
  libgeocode-glib0 libgnome-bluetooth13 libgnomekbd-common libgnomekbd8
  libgoa-backend-1.0-1 libgupnp-av-1.0-2 libgupnp-dlna-2.0-3 libgweather-3-6
  libgweather-common libnss-myhostname mousetweaks realmd
  ubuntu-system-service unity-control-center-faces
Suggested packages:
  libcanberra-gtk-module apache2-bin libapache2-mod-dnssd ibus-clutter
  ibus-doc
The following NEW packages will be installed:
  apg dconf-cli dleyna-server gir1.2-ibus-1.0 gkbd-capplet gnome-bluetooth
  gnome-control-center gnome-control-center-data gnome-online-accounts
  gnome-settings-daemon gnome-user-share ibus libcolord-gtk1
  libdleyna-connector-dbus-1.0-1 libdleyna-core-1.0-3 libgeocode-glib0
  libgnome-bluetooth13 libgnomekbd-common libgnomekbd8 libgoa-backend-1.0-1
  libgupnp-av-1.0-2 libgupnp-dlna-2.0-3 libgweather-3-6 libgweather-common
  libnss-myhostname mousetweaks realmd ubuntu-system-service
  unity-control-center-faces
0 upgraded, 29 newly installed, 0 to remove and 24 not upgraded.
Need to get 6,153 kB of archives.
After this operation, 30.2 MB of additional disk space will be used.

2
2017-11-15 06:55


oorsprong


Zou je alsjeblieft kunnen adviseren of het woks goed voor je is? Krijgt u een lage snelheid? Probeer het en deel uw invoer. dd if = / dev / urandom of = mnt / GDrive / testing / testfile count = 10000 bs - Ramesh Chand
ja, het werkt goed. Als je een wat verfijndere snelheidstest wilt, probeer ik het misschien. Dat dd commando is voor mij niet logisch, doet niks, "dd: niet-herkende operand 'bs'". Ik denk dat als je tijdtests wilt, je een nieuwe thread moet beginnen. - pauljohn32
Ok Bedankt voor de update Ik ben hier met de nieuwe thread begonnen. askubuntu.com/questions/993019/... Stuur me alsjeblieft daarheen. - Ramesh Chand


antwoorden:


Deze vraag zou in 2 vragen moeten worden verdeeld. Ik raad aan om de vraag te bewerken en alleen Q1 te behouden en Q2 naar een afzonderlijke vraag te verplaatsen.

Is google-drive-ocamlfuse beveiligd ?:

Dat is moeilijk te beantwoorden, maar ik vermoed dat je bedoelt, is de manier waarop het authenticatie doet, in principe veilig? En het antwoord is: het hangt ervan af.

Er zijn twee manieren waarop u kunt verifiëren: de ene is minder veilig dan de andere. De primaire manier om te verifiëren is minder veilig dan het alternatief.

  1. De primaire manier maakt gebruik van een webapp die wordt geschreven en gehost door astrada op de google app-engine en deze loopt door uw OAuth-tokens naar u. Dit is raar omdat we vertrouwen op een derde partij om die tokens veilig te houden. In theorie zou die pass-through-app schadelijk kunnen zijn, of zou kunnen worden gehackt door een 3de partij.

  2. De tweede manier is om het proces van het genereren en verifiëren van een nieuw OAuth-token via google's api (instructies gekoppeld aan de onderkant) te doorlopen. Dit is veel meer betrokken, maar is in theorie veiliger omdat je geen vertrouwde bron / niet-verifieerbare web-app van derden hoeft te vertrouwen om met je tokens om te gaan.

Documentatie: https://github.com/astrada/google-drive-ocamlfuse/wiki/Authorization


0
2017-07-11 19:45