Bug 1085837

Eli, isn't password field of 50 chars? How is it possible it fails with 48 chars?

(In reply to Sandro Bonazzola from comment #1)
> Eli, isn't password field of 50 chars? How is it possible it fails with 48
> chars?

I guess that this because of our incorrect use of PK encryption. Instead of encrypting using cipher and encrypt only cipher key, we encrypt using PK.

This adds to the fact that we actually store the password and not the hash.

This[1] should replace the internal provider, so we can remove these issues at least from the aaa module.

[1] http://www.ovirt.org/Features/AAA_JDBC

(In reply to Alon Bar-Lev from comment #2)
> (In reply to Sandro Bonazzola from comment #1)
> > Eli, isn't password field of 50 chars? How is it possible it fails with 48
> > chars?
> 
> I guess that this because of our incorrect use of PK encryption. Instead of
> encrypting using cipher and encrypt only cipher key, we encrypt using PK.
> 
> This adds to the fact that we actually store the password and not the hash.
> 
> This[1] should replace the internal provider, so we can remove these issues
> at least from the aaa module.
> 
> [1] http://www.ovirt.org/Features/AAA_JDBC

So this doesn't look like an engine-setup issue and should be reported in a separate BZ. I've checked engine-setup code and we don't validate password length there. So is 50 the right length to be checked?

(In reply to Sandro Bonazzola from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> > (In reply to Sandro Bonazzola from comment #1)
> > > Eli, isn't password field of 50 chars? How is it possible it fails with 48
> > > chars?
> > 
> > I guess that this because of our incorrect use of PK encryption. Instead of
> > encrypting using cipher and encrypt only cipher key, we encrypt using PK.
> > 
> > This adds to the fact that we actually store the password and not the hash.
> > 
> > This[1] should replace the internal provider, so we can remove these issues
> > at least from the aaa module.
> > 
> > [1] http://www.ovirt.org/Features/AAA_JDBC
> 
> So this doesn't look like an engine-setup issue and should be reported in a
> separate BZ. I've checked engine-setup code and we don't validate password
> length there. So is 50 the right length to be checked?

We should check that what we encrypt is max of len(pubkey)-5, but this is 250 bytes, I was confused by factor of 10... sorry.

Looking at the log, the password is rejected at the level of http, so it may be api issue or jboss issue that is not accepting long basic authentication header, not directly related to the setup, although if there is a true limitation of basic authentication header password then we should limit this somehow.

Juan, any limitation in password length while using http authentication at API or JBoss level?

The problem is in the Python SDK, it generates the authentication header using the "base64.encodestring" method, which may generate several new line characters. When there are more than one we only remove the last, thus generating an incorrect header.

ovirt-engine-sdk-python-3.4.0.7-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ovirt-engine-sdk-python-3.4.0.7-1.fc20

Packages containing this fix are available here:

  http://jhernand.fedorapeople.org/rpms/ovirt-engine-sdk-python/3.4.0.7-1

Sandro, to completely fix this issue for users I would suggest that the engine packaging is changed to require at least version 3.4.0.7 of the Python SDK.

I'm pushing patches to all packages I maintain requiring python sdk.
Thanks!

ok, av6.1

$ apg -m 111 -n 1
BacBicyeuccekbocOadjuOdGafcayffEeHufrucBubjimAwkEagasidVoifjuWelRayRiesjirredAmtyeajCirminhigawfacAnepyanUtgod?

put as admin password during setup.

# engine-setup
...snip...
[ INFO  ] Stage: Termination
[ INFO  ] Execution of setup completed successfully

and then i was able to login via Admin Portal.

"This bug happens when one calls the Python SDK, and it is called only if using the allinone setup. In addition the fix isn't included in av6.1."

Thus putting back on ON_QA and waiting for next build provided by CI.

To verify this run a simple Python SDK script, for example this one:

---8<---
#!/usr/bin/python

import ovirtsdk.api
import ovirtsdk.xml

api = ovirtsdk.api.API(
  url="https://ovirt.example.com/ovirt-engine/api",
  username="admin@internal",
  password="BacBicyeuccekbocOadjuOdGafcayffEeHufrucBubjimAwkEagasidVoifjuWelRayRiesjirredAmtyeajCirminhigawfacAnepyanUtgod?",
  ca_file="/etc/pki/ovirt-engine/ca.pem",
  insecure=False
)

api.disconnect()
--->8---

Without the fix it will throw an exception:

---8<--
Traceback (most recent call last):
  File "./test-longpass.py", line 11, in <module>
    insecure=False
  File "/usr/lib/python2.7/site-packages/ovirtsdk/api.py", line 145, in __init__
    url=''
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 118, in request
    persistent_auth=self._persistent_auth)
  File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 140, in __doRequest
    persistent_auth=persistent_auth
  File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line 134, in doRequest
    raise RequestError, response
ovirtsdk.infrastructure.errors.RequestError: 
status: 400
reason: Bad Request
detail: 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Request header field is missing ':' separator.<br />
<pre>
amltQXdrRWFnYXNpZFZvaWZqdVdlbFJheVJpZXNqaXJyZWRBbXR5ZWFqQ2lybWluaGlnYXdmYWNB</pre>
</p>
</body></html>
--->8---

With the fix it will finish successfully and silently.

ovirt-engine-sdk-python-3.4.0.7-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

ok, av7. Tested with python code from #13.

*** Bug 1094406 has been marked as a duplicate of this bug. ***

This is an automated message

oVirt 3.4.1 has been released:
 * should fix your issue
 * should be available at your local mirror within two days.

If problems still persist, please make note of it in this bug report.