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

[kvaes]

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"

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]

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

[kvaes]

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]

@kvaes thanks for the update!

[jiacfan]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[jacobw125]

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]

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]

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

[munael]

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

[akihiro-inui]

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

[zezha-msft]

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.