On 22.10.2015 16:56, Petr Spacek wrote:
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

Okay, I missed your point, I understand now and I'm agree that only admin or more privileged users are able to see services.


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