swift icon indicating copy to clipboard operation
swift copied to clipboard

Panic calling DynamicLargeObjectCreateFile with unauthenticated connection

Open EtienneM opened this issue 4 years ago • 3 comments

Lib version used: v1.0.52

Hi,

I'm not sure if it's an issue or me wrongly using the lib. The Authenticate documentation states that:

If you don't call it before calling one of the connection methods then it will be called for you on the first access.

Hence, I assumed it's not needed to call the Authenticate method as it's automatically called if needed. but in my code I'm doing the following:

conn := new(swift.Connection)
err := conn.ApplyEnvironment()
object, err := conn.DynamicLargeObjectCreateFile(&swift.LargeObjectOpts{})

The code panics with the following logs:

github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).storage(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0xf54736, 0x4, 0x0, 0x0, 0xc00033c840, ...)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:816 +0x7d
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).objectBase(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2089 +0xf6
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).Object.func1(0x37e11d600, 0xc00050a190, 0xc000049000, 0xc000417040)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2078 +0xa9
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.withLORetry(0x0, 0xc0005f7110, 0x0, 0x0)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/largeobjects.go:285 +0xa3
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).Object(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2077 +0xfc
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).largeObjectCreate(0xc0005be540, 0xc0005f7470, 0xc0, 0x11e, 0x5b)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/largeobjects.go:138 +0x92
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).DynamicLargeObjectCreateFile(0xc0005be540, 0xc0005f7470, 0x5b, 0xc0003768c0, 0x133, 0x0)
	/opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/dlo.go:18 +0x39

If I update my code like that, it works:

conn := new(swift.Connection)
err := conn.ApplyEnvironment()
err = conn.Authenticate()
object, err := conn.DynamicLargeObjectCreateFile(&swift.LargeObjectOpts{})

I don't know if the fix is for the lib to call Authenticate if needed. Or maybe prevent the panic and return a proper error?

Thanks a lot for the lib :)

EtienneM avatar Jun 12 '20 13:06 EtienneM

Thanks for reporting this.

I would say it is a bug!

I see you are using

err := conn.ApplyEnvironment()

I could see how this could happen if you have a storage URL and an auth token in there?

Is that the case?

I can see several mistakes in the auth code now I look at it! I think that bit of code was amongst my first bits of Go code written in 2014 2fd9fd32d665d493927c923efb39fce07d2588c5

The problem is that the mutex went from an inline one to a pointer. This is so that the Connection can be copied without problems fb21762ca71c5da5958efd8426cbbd67df8f7ba9 however not all the places it is used got updated to initialise it.

ncw avatar Jun 12 '20 17:06 ncw

I could see how this could happen if you have a storage URL and an auth token in there?

Here is the list of environment variables:

OS_USERNAME
OS_PASSWORD
OS_REGION_NAME
OS_AUTH_URL
OS_IDENTITY_API_VERSION=3
OS_USER_DOMAIN_NAME
OS_PROJECT_DOMAIN_NAME
OS_PROJECT_ID
OS_PROJECT_NAME

EtienneM avatar Jun 15 '20 07:06 EtienneM

Can you have a go with the fix-160-auth-panic branch? I think this will fix it.

I decided I needed to revert #154 which is the underlying cause of the problem.

ncw avatar Jun 16 '20 10:06 ncw