On 02/20/2013 12:31 PM, Tomas Babej wrote:
> On 02/19/2013 10:33 PM, Rob Crittenden wrote:
>> Tomas Babej wrote:
>>> On 02/06/2013 07:57 PM, Rob Crittenden wrote:
>>>> Tomas Babej wrote:
>>>>> this pair of patches improves HBAC rule handling in selinuxusermap
>>>>> Patch 0031 deals with:
>>>>> Patch 0032 takes care of:
>>>>> and is to be applied on top of Patch 0031.
>>>>> See commit messages for detailed info.
>>>> ACK for patch 0032.
>>>> For patch 0031 we can't change the data type of an existing attribute.
>>>> It will break backwards compatibility. Can you test with an older
>>>> client to see if it cares (it may not care about the name of the
>>>> type). If older clients will work then this is probably ok.
>>>> I gather that seealso detected as a DN attribute and converted into a
>>>> DN class and this is blowing up the Str validator?
>>> Yes, that was exactly the case.
>>> I added a workaround for older client versions, tested it with
>>> freeipa-client/admintools 2.2, works as expeceted.
>>> However, this only should be issue if there is older admintools package
>>> on the client than on the server.
>>> Outline is such as follows: I added a new flag for DNParam seelalso
>>> attribute, called 'allow_malformed' that allows any string to be passed
>>> to DNParam. Its value gets wrapped in 'malformed=yes,value=<value>'.
>>> This allows to parse out the string in selinuxusermap-add/mod
>>> pre_callback out of the DN and search for the rule with such name so
>>> that it's DN gets in LDAP instead.
>>> Updated patch attached.
>> I like where you're going with this, just a couple of comments:
>> 1. Should we come up with a more universal name for allow_malformed? Is this
>> something that we should allow at a higher level? I was thinking allow_raw,
>> or allow_non_dn, or something like that.
> To me, allow_non_dn sounds is just as specific as allow_malformed,
> they both refer to DN specifically.
> I'd go with allow_raw, if need for such pattern may eventually arise for
> other parameter classes than DNParam.
> What do you mean by higher level, turning this hack into a feature
> Param class? I don't see how this would work, each parameter
> class that implements its own type validation as DNParam needs
> to override _convert_scalar(). And in every such class we would need
> to wrap our raw value so that it is represented in the type of this parameter,
> as we do with DN(('malformed','yes'),('value',value)) now.
> Maybe we could skip type validation in _convert_scalar default
> implementation or catch the error raised somehow, and let the type be
> invalid, but I'm not aware of the consenquences. I would need to investigate.
> Wouldn't it cause failure deeper in the framework?
> Or did you by higher level mean simply picking a more general name for the
> flag so it can be reused in other parameter classes with the same name?
>> 2. I think that if a bad dn is passed in as a Str the conversion into a DN
>> won't be handled:
>> + if 'allow_malformed' in self.flags:
>> + dn = DN(('malformed','yes'),('value',value))
>> Should this be wrapped in a try/except to raise a ConversionError if it
> Yes, thanks for that catch.
Is it just me, or does the 0031 look overengineered? I think this is a general
problem for each Str parameter which we then process/convert to DN in our
selinuxusermap is one example where this does not work. This fix leaves other
examples not working:
# ipa trustconfig-mod --setattr "ipantfallbackprimarygroup=cn=Default SMB
ipa: ERROR: invalid 'ipantfallbackprimarygroup': must be Unicode text
I would rather propose to not automatically encode DN of known attributes set
diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py
index 1ebbe7a..e4b9834 100644
@@ -768,12 +768,6 @@ last, after all sets and adds."""),
# None means "delete this attribute"
value = None
- if ldap.has_dn_syntax(attr):
- value = DN(value)
- except ValueError:
- raise errors.InvalidSyntax(attr=attr)
if attr in newdict:
if type(value) in (tuple,):
newdict[attr] += list(value)
I think this conversion is just done too early as this Str param is processed
and converted later in the pre_callback, when needed. The code above introduced
inconsistent processing of IPA attributes with DN syntax coming from regular
option and from *attr option - Str
When I did this change, both selinuxusermap-mod and trustconfig-mod started
# ipa selinuxusermap-mod foo
Modified SELinux User Map "foo"
Rule name: foo
SELinux User: unconfined_u:s0-s0:c0.c1023
HBAC Rule: allow_all
# ipa selinuxusermap-mod foo --setattr=seealso=allow_all
ipa: ERROR: no modifications to be performed
# ipa selinuxusermap-mod foo --hbacrule=allow_all
ipa: ERROR: no modifications to be performed
You would just need to investigate if this change would not have other
Freeipa-devel mailing list