azcopy login - ADLS Gen2 - "failed to perform login command, failed to get keyring during saving token, function not implemented"

kvaes commented 5 years ago

Which version of the AzCopy was used? 10.0.7

Which platform are you using? Linux (Ubuntu WSL)

What command did you run? azcopy login

What problem was encountered?

"failed to perform login command, failed to get keyring during saving token, function not implemented"

2019-02-03 21_58_51-sign in to azure storage azcopy 2019-02-03 21_59_06-kvaes desktop-ogoso3d_ _azcopy_azcopy_linux_amd64_10 0 7

Next expected steps ;

azcopy cp /tmp/tmp_exe92r3 https://*myadlsaccount*.dfs.core.windows.net/test/tmp_exe92r3 Scanning...

failed to perform copy command due to error: OAuth token or shared key should be provided for Blob FS

Have you found a mitigation/solution? No

zezha-msft commented 5 years ago

Hi @kvaes, thanks for reaching out! We'll try to repro this issue and get back to you shortly.

kvaes commented 5 years ago

FYI - Attempted the same on a similar non-WSL-based Ubuntu and that one works as expected. So it seems to be WSL related...

zezha-msft commented 5 years ago

@kvaes thanks for the update!

jiacfan commented 5 years ago

@kvaes thanks for reaching us, this is a issue related to WSL as discussed in #172, where Linux embedded keyring cannot be properly used even with keyctl. Temporarily, please use standard Linux distro, and we'll further follow up and see if WSL can be supported later.

Best Regards, Jiachen

brent-robinson commented 5 years ago

I'm also experiencing this on an Ubuntu 18.04 based container running on Docker Desktop (Windows).

azcopy login --tenant-id *********

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ********* to authenticate.
Error: failed to perform login command, failed to get keyring during saving token, operation not permitted
... <usage omitted for brevity> ...
failed to perform login command, failed to get keyring during saving token, operation not permitted

jiacfan commented 5 years ago

Hi, @brent-robinson

Thanks for reaching us and providing feedback, would you try keyctl on the environment you described, and see if it can manipulate session keyring properly?

Best Regards, Jiachen

brent-robinson commented 5 years ago

It seems keyctl isn't available in my environment running on the image mcr.microsoft.com/powershell:ubuntu-18.04.

# keyctl
/bin/sh: 1: keyctl: not found

Edit: It looks like Docker blocks keyctl by default.

Second edit: az works well in a container though. Could azcopy leverage the same capability az uses for authentication?

Final edit: For anyone looking for a workaround, I generated a SAS token with az and passed that to azcopy as needed.

adreed-msft commented 5 years ago

FYI - Attempted the same on a similar non-WSL-based Ubuntu and that one works as expected. So it seems to be WSL related...

This is a WSL issue as far as I know. Under all WSL distributions (even custom ones like Arch Linux), this occurs, even when keyctl is present. This could be related to any number of syscalls not being present on WSL (for instance, this is why said arch distribution comes with fakeroot-tcp, rather than the default distribution of fakeroot)

Frankly, I'd like to see this reproduced on a physical Linux machine.

benc-uk commented 5 years ago

Same problem here with WSL I can't beleive this wasn't tested under WSL, which is used by a lot of developers and lot of my customers

adreed-msft commented 5 years ago

I can't beleive this wasn't tested under WSL, which is used by a lot of developers and lot of my customers

Apologies we didn't test this-- However, I also don't think that much of the AzCopy team was aware of the differences between a standard Linux install and WSL. I'll try to find a valid workaround or solution we can attain in the meantime though.

JohnRusk commented 5 years ago

Actually, @benc-uk , it was tested in WSL back in February (as you can see from the dates earlier in this thread). And its been on our backlog to resolve the issue since then, but unfortunately other issues have taken priority for getting the recent GA out the door.

adreed-msft commented 5 years ago

Since the Linux embedded keyring isn't available on WSL, we should discuss some alternatives.

We could use the GNOME keyring, but not every Linux install or whatever has that, and it'd be doubtful that any WSL installation has it due to the fact that WSL is primarily used via CLI. As a result, this wouldn't be very portable.
We could also encrypt the file with a keypair generated from system-specific salt. As a result, this could be used on any system that we have a way to obtain this kind of information on (question being, what would serve as the fingerprint for the salt? Hardware, kernel version, and otherwise would make sense in my opinion, since those don't change often and can be fairly hard to reproduce exactly. Atop that, what would we make use of to obtain this salt?)

Thoughts on any others? I basically want to avoid adding dependencies as much as we can.

adreed-msft commented 5 years ago

(FYI it is on the backlog but we don't have a release date yet)

jacobw125 commented 5 years ago

I experienced a similar issue with azcopy v10.2.1 on CentOS. An otherwise successful authentication would fail with "Failed to perform login command: failed to get keyring during saving token, key has been revoked". At that point, 'keyctl list @s' also returned the error message 'keyctl_read_alloc: Key has been revoked'

My workaround was to recreate the session keyring with "keyctl session". That seems to have resolved the issue, but it still worries me that something about Azcopy caused the session keyring to be messed up in the first place.

JohnRusk commented 5 years ago

This (@jacobw125 's comment) is similar to the issue I commented on in #452 . IIRC, in my investigation on SLES 12, the issue seemed to be a difference in session key ring behavior at OS level.

dreamflasher commented 4 years ago

I can reproduce on Ubuntu 18.04. keyctl is not installed, requires sudo apt install keyutils. After keyctl session it works.

munael commented 4 years ago

This's still an issue. The workaround isn't very convenient as it messes with terminal session management.

akihiro-inui commented 3 years ago

I'm still having the same issue with azcopy 10.7.0. Does anyone have a solution rather than using keyctl?

zezha-msft commented 3 years ago

Hi @munael @akihiro-inui, yes! We've recently added support for in-memory secret store, which doesn't need the keyring. Please learn more from this wiki.

vaclav-stummer commented 2 years ago

In newer versions of the az (currently 2.38.0) there are usually alternatives to the azcopy. I recommend going through all the options in https://docs.microsoft.com/en-us/cli/azure/storage?view=azure-cli-latest

Azure / azure-storage-azcopy