#1112 Comma in member attribute causes parsing error
Closed: Fixed None Opened 13 years ago by edewata.

Comma in member attribute will cause parsing error in CLI and UI.

  1. In CLI the values of member attribute have to be joined with a comma and specified in a parameter. A single value that contains comma will be incorrectly parsed into multiple values.

Add the following role and privileges:

% ipa role-add "Test Role" --desc="Test Role"
% ipa privilege-add "Test Privilege" --desc="Test Privilege"
% ipa privilege-add "Write, Add and Delete Members" --desc="Test Privilege"

Add the privileges into the role:

% ipa role-add-privilege "Test Role" --privileges="Write, Add and Delete Members, Test Privilege"
  Role name: test role
  Description: Test Role
  Privileges: test privilege
  Failed members:
    privilege: write: privilege not found
    privilege: add and delete members: privilege not found

To solve this problem there needs to be a way to escape the comma.

  1. In UI the values of member attribute have to be joined with a comma and sent as a single string value. A single value that contains comma will be incorrectly parsed into multiple values.

    {
    "method": "role_add_privilege",
    "params": [
    [ "Test Role" ],
    {
    "privilege": "Write, Add and Delete Members, Test Privilege"
    }
    ]
    }

To solve this the problem the values should be sent as an array. Currently the server doesn't accept array in member attribute.

{
    "method": "role_add_privilege",
    "params": [
        [ "Test Role" ],
        {
            "privilege": [ "Write, Add and Delete Members", "Test Privilege" ]
        }
    ]
}

There might be a similar problem in the CLI but in case of CLI the issue would be in the CLI parsing on the client side.

It might be a separate issue.

Not sure if we want to open a new ticket for every comma-problem discovered but while testing the patches I found a new issue:

ipa permission-add --type=user --permissions=add '1,2,3'

This creates an aci that grants access to the group cn=1,2,3,cn=permissions,cn=pbac

This is, of course, a very broken DN.

The aci parser extracts the target and determines what type of target it is, it may be ldap:///anyone, ldap:///[dn], etc. The dn-handling is rather poor. This also constructs dns based on the permission name, that too uses raw values.

Pushed patches adding new DN class and escape character:

master:

- commit d9d00f152267780d8251ee6e935645f397f2c0d7
- commit 8c95eb68d2315217ff1d2564b5b300aa106f4bbd
- commit 032b77ac23f2b92283e72cc7efcf787d22565abc
- commit 4c1bfdb9198bcf831282244b6666d9776529ab37
- commit 1a7d05cc0f8c06a6f59d0db75361fa1a06189bee

ipa-2-0:

- commit 2718d7b79064f42d5a63c75185e8116461d95de8
- commit d3658a3bd5ceed64cae2e580aec1ea019fe6e814
- commit 8e086fd7b8c1edd0ccfec527c0699d396a7954f9
- commit c341d764c5badcf2e2ee191917cf54db52d470fc
- commit c4c089f0b0024231548a770340c22fc12ff43b21

Note that the test cases outlined in the original report still fail the same way, the commas now need to be escaped.

Metadata Update from @edewata:
- Issue assigned to jdennis
- Issue set to the milestone: FreeIPA 2.1 - 2011/06

7 years ago

Login to comment on this ticket.

Metadata