Bug 1232425
| Summary: | D-Bus interface for InfoPipe.GetUserAttr returns base64 encoded values for octetString attributes | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Petr Spacek <pspacek> |
| Component: | sssd | Assignee: | SSSD Maintainers <sssd-maint> |
| Status: | CLOSED UPSTREAM | QA Contact: | Namita Soman <nsoman> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mzidek, pbrezina |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-07 20:13:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The tentative plan is to keep returning everything as string, but mark clearly in the returned string representation that the value should be decoded. Upstream ticket: https://fedorahosted.org/sssd/ticket/2684 Jakub, could you be more specific? I'm not sure what you meant by 'mark clearly in the returned string representation that the value should be decoded'. Something like "values starting with two colons are encoded with base64 and the caller should decode them on their own". I feel that the proposal over-complicates a simple thing, i.e. an API which is supposed to return string stored in LDAP. What if the actual string value starts with two colons? Will you base64 encode all IA5Strings starting with :: just to make sure that the right value can be obtained by decoding it? Seriously? What am I missing? Why not fix it properly, e.g. to always return arbitrary blob (or always base64 encode it if arbitrary blob is not an option for some reason)? I do not understand it, sorry. (In reply to Petr Spacek from comment #6) > I feel that the proposal over-complicates a simple thing, i.e. an API which > is supposed to return string stored in LDAP. > > What if the actual string value starts with two colons? Will you base64 > encode all IA5Strings starting with :: just to make sure that the right > value can be obtained by decoding it? > > Seriously? > > What am I missing? > > Why not fix it properly, e.g. to always return arbitrary blob Because D-Bus is typed. So the arbitrary blob would be 'array of bytes' with specified length, which is inconvenient. > (or always > base64 encode it if arbitrary blob is not an option for some reason)? That would work and would be similar to the 'arbitrary blob' you propose, but would complicate matters for 90% of attributes. Sorry, but I do not see the benefit of doing so. Even in your scheme users cannot rely on fact that the value will not be base64 encoded. Any code which depends on that check will blow up as soon as someone mistyped a value in LDAP and added space to the beginning of a string or did something similarly stupid. I'm sorry to say that but that it is really a poor design for an API. I mean, 'any code which depends on that *property*', i.e. relying on fact that the value will certainly not be base64 encoded. Thank you for filing this bug report. Since fixing this bug requires work in the upstream SSSD project which is not scheduled for the immediate future, I added a conditional development nack, pending upstream availability. Thank you for filing this bug report. Since this bug is being tracked in the upstream issue tracker and the fix would only make its way to RHEL pending upstream availability, I'm closing this bugzilla with the resolution of UPSTREAM. Please reopen if you think this issue needs to be tracked here in the Red Hat Bugzilla. |
Description of problem: Values obtained using D-Bus call org.freedesktop.sssd.infopipe.GetUserAttr() are base64 encoded if the attribute in LDAP has octetString syntax. Version-Release number of selected component (if applicable): sssd-dbus-1.12.2-58.el7_1.6.x86_64 How reproducible: 100 % Steps to Reproduce: 0. Add LDAP schema with an octetString attribute: E.g. ( 2.16.840.1.113730.3.8.11.31 NAME 'ipaSshPubKey' DESC 'SSH public key' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN ( 'IPA v3' 'user defined' ) ) 1. Configure IFP to return a attribute which has syntax octetString. /etc/sssd/sssd.conf: [domain/redhat.com] ldap_user_extra_attrs = mail, givenname, sn, ipaSshPubKey [ifp] allowed_uids = root user_attributes = +mail, +givenname, +sn, +ipaSshPubKey 2. Populate the attributes with some data. 3. Request values of the attribute with octetString syntax over D-Bus: #!/bin/python import dbus def get_keys_from_server(username): bus = dbus.SystemBus() infopipe_obj = bus.get_object("org.freedesktop.sssd.infopipe", "/org/freedesktop/sssd/infopipe") ifp = dbus.Interface(infopipe_obj, dbus_interface='org.freedesktop.sssd.infopipe') result = ifp.GetUserAttr(username, ["ipaSshPubKey"]) ssh_keys = [] if result: for sshpubkey in result["ipaSshPubKey"]: print(sshpubkey) Actual results: The returned value is base64 encoded. Expected results: Raw value is returned.