Bug 670673

Summary:	[doc bug] no data validation for filter in "ipa permissin-add" command
Product:	[Retired] freeIPA	Reporter:	Yi Zhang <yzhang>
Component:	Documentation	Assignee:	David O'Brien <daobrien>
Status:	CLOSED DEFERRED	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	medium	Docs Contact:
Priority:	low
Version:	2.0	CC:	benl, dpal, jgalipea
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	670897 (view as bug list)		Environment:
Last Closed:	2011-02-02 14:34:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	670897

Description Yi Zhang 2011-01-18 23:19:25 UTC

Description of problem:

yi zhang wrote:
> Hi:
>
> The following ipa command returns success:
> ipa permission-add TestPermission --desc "fortest" --attrs=gidunumber
> --permissions=read --filter=cn=
>
> Please notice that "filter" has "cn=" as parameter.
>
> My question is, is this legal? (In another words: is this a bug?)
> Do we do data validation for "filter"? I know that we do validation for
> "attrs" and "memberof".
>
> Thanks!
>

It is a bug but not one I have found a way to fix. I can't find a mechanism in python-ldap to validate a filter. At this point we just have to say "thar be dragons" and let the buyer beware.

rob 

Version-Release number of selected component (if applicable):ipa-server-2.0-0.2011011115gitc778919.fc14.i686


Additional info:
Based on Rob's opinion, i log this as a "doc" bug so we can put it in release-notes (if we end up not fixing it)

Comment 1 Dmitri Pal 2011-02-02 14:32:39 UTC

https://fedorahosted.org/freeipa/ticket/902

Comment 2 Dmitri Pal 2011-02-02 14:34:31 UTC

I am going to close this issue as a bug.
The doc bug is already open and the ticket for 2.1 is filed upstream.
This bug however would not be addressed in 2.0 thus closing as DEFERRED. 
In future the bugs should be risen against a different component.