On 22.10.2015 16:51, Martin Basti wrote:
> 
> 
> On 22.10.2015 16:35, Petr Spacek wrote:
>> On 22.10.2015 16:13, Martin Basti wrote:
>>> On 22.10.2015 10:44, Martin Babinsky wrote:
>>>> https://fedorahosted.org/freeipa/ticket/5181
>>>>
>>>>
>>>>
>>> Thank you for the patch.
>>>
>>> 1)
>>> +OPTIONAL_SERVICES = {
>>> +    'DNS',
>>> +    'CA',
>>> +    'KRA',
>>> +    'ADTRUST',
>>> +    'EXTID',
>>> +    'DNSKeyExporter',
>>> +    'DNSSEC',
>>> +    'DNSKeySync',
>>> +}
>>>
>>> This did not scale well, maybe we should improve it to use some general
>>> solution for whole IPA to distinct mandratory and optionl service, but I do
>>> not know how (or if it is possible)
>> Personally I would not create 'generic' solution until necessary. We have too
>> much 'generic' code which was never tested outside the single use-case we
>> have. Let's generalize it when needed.
>>
>>
>>> 2)
>>> +        search_filter=('(&(objectclass=ipaConfigObject)'
>>> +                       '(ipaConfigString=enabledService))')
>>>
>>> Common user cannot read ipaConfigString, so this will work only for admins, 
>>> I
>>> do not see any limitations of access in code for other users.
>> I think that this is okay. The user will see exactly what LDAP ACI allows him
>> to see, i.e. nothing. We do the same with DNS, for example.
> I disagree:
> 
> [root@vm-065 ~]# kinit commonuser
> 
> [root@vm-065 ~]# ldapsearch -Y GSSAPI -b
> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com'
> ...
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
> ...
> # CA, vm-065.example.com, masters, ipa, etc,  example.com
> dn: cn=CA,cn=vm-065.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com
> objectClass: top
> objectClass: nsContainer
> objectClass: ipaReplTopoManagedServer
> objectClass: ipaConfigObject
> objectClass: ipaSupportedDomainLevelConfig
> cn: CA
> 
> 
> [root@vm-065 ~]# ldapsearch -Y GSSAPI -b
> 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com' 
> '(ipaConfigString=enabledService)'
> ...
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=example,dc=com> with scope subtree
> # filter: (ipaConfigString=enabledService)
> # requesting: ALL
> #
> 
> # search result
> search: 4
> result: 0 Success
> 
> So as I said, a common user has no access to ipaConfigString attribute

I agree with you - and I believe that current behavior is not a problem.

$ ipa server-show will display the same information about enabled services as
LDAP search - i.e. no information :-)

In other words, ordinary user cannot see if the component is enabled or not,
and because the user cannot judge this we will not show the information to
him. I'm fine with that.

Petr^2 Spacek


>> 4) Could you extend ipa server-find with an option to search for servers with
>> a particular optional service? I think that it would be handy to do
>> something like
>> $ ipa server-find --service=CA
>> to see list of CA servers.
>>
>> Thank you!

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to