Sense intenció de crear polèmica, si el client ja té (o vol) les dades Azure poc importa fer servir el binari. Per altra banda, si no vaig errat, aquesta utilitat és amb llicència MIT i aquí està el codi font https://github.com/Azure/azure-storage-azcopy.
Salut,
Aquí tens una explicació de les ubicacions típiques:
https://wiki.gilug.org/FHS
De tota manera no hi ha més o menys exposició a raó d'on d'ubiqui un
executable, sinó a raó de per quin usuari sigui l'execució, i doncs
quins permisos té aquest usuari a accedir a coses del sistema.
Si l'executes així:
$ sudo azcopy bla bla
aleshores s'executarà amb permisos de «root» i podrà accedir i manipular
tot.
Si l'executes com a «joan»:
$ azcopy bla bla
aleshores podrà fer allò què ja pot fer «joan» sense «sudo».
Hi ha situacions en què programa chroot pot ser útil per a engabiar
l'execució d'un programa en un directori, i què no vegi res fora
d'aquell directori. I probablement hi ha coses més avançades amb la
mateixa finalitat.
El 25/8/25 a les 17:25, Joan ha escrit:
> Bon dia,
>
> Un client em demana que per fer la transferència/sincronització de les
> còpies de seguretat, que estan a una debian, usi Azcopy, un binari de
> Microsoft per "entendre's" amb el seu espai d'Azure.
>
> Com és obvi, Micro$oft ofereix un binari, i en aquesta guia parla de
> posar-lo a l' /usr/local/bin/
>
> https://linuxvox.com/blog/install-azcopy-on-linux/
>
> Jo en principi no tinc gaires ganes de posar un binari de codi tancat
> al meu sistema, i suposo que el puc posar en algun subdirectori d'un
> usuari /home/azure/bin/ per exemple, i executar-lo amb aquell usuari
> sense permisos especials. I m'imagino que així mitigo l'exposició del
> meu sistema al codi tancat de MS. I ja m'imagino que si tinc el mode
> alèrgic OFF, doncs puc pasar de tot i posar-lo al /usr/local/bin i
> santes pasqües.
>
> Tot aquest rollo us el comento per si teniu experiència / suggeriments
> / comentaris amb aquest tema...
>
--
Narcis Garcia
__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should remove and omit any @, dot and mailto combinations against
automated addresses collectors.