On Wed, Nov 14, 2018 at 11:32 AM Florence Blanc-Renaud <[email protected]> wrote: > > On 11/13/18 10:20 PM, Rob Crittenden via FreeIPA-devel wrote: > > Petr Vobornik via FreeIPA-devel wrote: > >> On Mon, Nov 12, 2018 at 6:28 PM François Cami via FreeIPA-devel > >> <[email protected]> wrote: > >>> > >>> Hi, > >>> > >>> While investigating why non-admin users having access to a shared > >>> vault got an error that stemmed from them not being able to find the > >>> KRA server to query (*), I found out that by changing the ldapsearch > >>> query normal users could, in fact, get the list of KRA servers. > >>> > >>> (*) https://pagure.io/freeipa/issue/7691 > >>> > >>> E.g. the query built from select_any_master(ldap2, service='CA') does > >>> not return any server when run by a non-admin user: > >>> ############## > >>> # ldapsearch -Y GSSAPI -b > >>> cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org > >>> '(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=KRA))' > >>> (...) > >>> ############## > >>> > >>> but removing (ipaConfigString=enabledService) from the query works: > >>> ############## > >>> # ldapsearch -Y GSSAPI -b > >>> cn=masters,cn=ipa,cn=etc,dc=laptop,dc=example,dc=org > >>> '(&(objectClass=ipaConfigObject)(cn=KRA))' > >>> # KRA, idm0.laptop.example.org, masters, ipa, etc, laptop.example.org > >>> dn: > >>> cn=KRA,cn=idm0.laptop.example.org,cn=masters,cn=ipa,cn=etc,dc=laptop,dc=ex > >>> ample,dc=org > >>> objectClass: nsContainer > >>> objectClass: ipaConfigObject > >>> objectClass: top > >>> cn: KRA > >>> ############## > >>> > >>> So it looks like once we're past logging an exception when we can't > >>> find a KRA master ( https://github.com/freeipa/freeipa/pull/2553 ), we > >>> have to decide what to do: > >>> * should users be able to see more data in LDAP by default - it looks > >>> like by using ldapsearch they already can find the information they > >>> need anyway - so allow all users to read status of services > >> > >> After the ping on IRC I gave it bit more thought > >> > >> I'd actually prefer to allow reading of ipaconfig string attr to all > >> authenticated users as I don't think we are revealing any new > >> information and it would make logic simpler and would support possible > >> RFE of standby replica. > >> > >> Some thinking behind it, maybe I have missed something: > >> > >> If a service is present is visible by the presence of the container, > >> e.g. KRA(as pointed out by Francois) - this is done via permission > >> "Read access to masters" bind to all. > >> > >> For values which are stored in ipaConfigString: > >> * enabledService - IPA doesn't support uninstallation, so except for > >> interim state in install this will be mostly present in each service > >> container and can be mostly read from SRV records + it's the point of > >> all this. > >> * startOrder - this information is not interesting and all servers > >> should have the same value > >> * dnssecVersion 1 - I think it can be inferred from DNS > >> * caRenewalMaster - I don't know exactly how this attr is being > >> consumed by a consumer but we also announce all CA servers and it is > >> clear that it is one of them. Also readable by all IPA managed hosts > >> (as any ipaConfigString in masters tree). > >> * kdcProxyEnabled - enabled by default > >> * pkinitEnabled - is obtainable via another way > > > > Seems well-reasoned to me, +1. > > > > rob > Also agree, we can make ipaconfigstring readable by all authenticated users. > flo
Thanks Petr, Rob, Flo, I'll make it so. François _______________________________________________ FreeIPA-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
