From pspacek at redhat.com Mon Jun 2 07:45:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Jun 2014 09:45:28 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140530134748.GO30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> <20140530134748.GO30381@localhost.localdomain> Message-ID: <538C2B98.3080901@redhat.com> On 30.5.2014 15:47, Sumit Bose wrote: > On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: >> On 05/30/2014 03:04 AM, Sumit Bose wrote: >>> On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: >>>> On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >>>>> On 29.5.2014 13:48, Sumit Bose wrote: >>>>>> == slapi-nis plugin/compat tree == >>>>>> The compat tree offers a simplified LDAP tree with user and group data >>>>>> for legacy clients. No data for this tree is stored on disk but it is >>>>>> always created on the fly. It has to be noted that legacy clients might >>>>>> be one of the major users of the user-views because chances are that >>>>>> they were attached to the legacy systems with legacy ID management which >>>>>> should be replaced by IPA. >>>>>> >>>>>> In contrast to the extdom plugin it is not possible to determine the >>>>>> client based on the DN because connection might be anonymous. The >>>>>> Slapi_PBlock contains the IP address of the client in >>>>>> SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>>>>> tree requires a reverse-DNS lookup which might be unreliable. If the >>>>>> reverse-DNS lookup was successful the slapi-nos plugin can follow the >>>>>> same steps as the extdom plugin to lookup up and apply the view. >>>>> Do we really want to base security decisions on reverse DNS resolution? >>>> No we do not want to play these games. >>>> >>>>> That >>>>> will be insecure. Attacker could tamper with reverse DNS to change UID/GID >>>>> mapping ... Maybe we can store IP->view mapping in the LDAP database. That >>>>> should be reliable if we assume that only TCP is used for connection to LDAP >>>>> database. >>>> It is not just about it being insecure, it is about it being wrong. >>>> As soon as you have a bunch of clients behind a NAT this pans goes belly >>>> up. >>> I do not like this one either. I just wanted to list to options I could >>> think of because I think supporting user-views on legacy clients is one >>> of the major use-cases for this feature. >>> >>> bye, >>> Sumit >>> >>>>>> As a alternative slapi-nis can provide one tree for each view. >>>> This is the only alternative, if we decide to pursue it. >>>> >>>> Simo. >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Please correct me as I might be confused. >> We have the compat tree now for legacy clients. It is also used by latest >> SSSD clients to do special lookups, right? > > no, we discussed this with Alexander some time ago and he asked not to > use the compat tree from SSSD but the extdom plugin because of the given > limitations of the slapi-nis plugin. > >> The data in this tree comes from the SSSD on the server running in server >> mode. >> I wonder if we can say: here are replicas A, B, C that have vanilla "default >> view", here are replicas K, L, M where the data is overwritten with a >> special view (i.e. UID/GID fro ma special area) and then we have replicas >> X,Y,Z that have a different overlay view. >> It will be assumed that replicas A,B,C, serve clients in one "zone", new and >> legacy, while K, L, M serve another zone and X, Y, Z serve the other one. >> Would that work? > > Besides that it is very confusing it would be possible as long as the > overrides from the special views are done by slapi-nis because SSSD on > servers and replicas will always and only deliver the default view. Also, this would completely break DNS-based fail-over (based on SRV records) because different replicas would provide different data. In theory, it could be done with DNS-locations (which we repeatedly decided not to support). In all cases, it requires re-configuration on client side because support for 'locations' has to be explicitly enabled in SSSD. References: http://www.freeipa.org/page/V3/DNS_Location_Mechanism https://fedorahosted.org/freeipa/ticket/2008 -- Petr^2 Spacek From sbose at redhat.com Mon Jun 2 08:11:05 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 2 Jun 2014 10:11:05 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <538C2B98.3080901@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> <20140530134748.GO30381@localhost.localdomain> <538C2B98.3080901@redhat.com> Message-ID: <20140602081105.GU30381@localhost.localdomain> On Mon, Jun 02, 2014 at 09:45:28AM +0200, Petr Spacek wrote: > On 30.5.2014 15:47, Sumit Bose wrote: > >On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: > >>On 05/30/2014 03:04 AM, Sumit Bose wrote: > >>>On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: > >>>>On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > >>>>>On 29.5.2014 13:48, Sumit Bose wrote: > >>>>>>== slapi-nis plugin/compat tree == > >>>>>>The compat tree offers a simplified LDAP tree with user and group data > >>>>>>for legacy clients. No data for this tree is stored on disk but it is > >>>>>>always created on the fly. It has to be noted that legacy clients might > >>>>>>be one of the major users of the user-views because chances are that > >>>>>>they were attached to the legacy systems with legacy ID management which > >>>>>>should be replaced by IPA. > >>>>>> > >>>>>>In contrast to the extdom plugin it is not possible to determine the > >>>>>>client based on the DN because connection might be anonymous. The > >>>>>>Slapi_PBlock contains the IP address of the client in > >>>>>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > >>>>>>tree requires a reverse-DNS lookup which might be unreliable. If the > >>>>>>reverse-DNS lookup was successful the slapi-nos plugin can follow the > >>>>>>same steps as the extdom plugin to lookup up and apply the view. > >>>>>Do we really want to base security decisions on reverse DNS resolution? > >>>>No we do not want to play these games. > >>>> > >>>>>That > >>>>>will be insecure. Attacker could tamper with reverse DNS to change UID/GID > >>>>>mapping ... Maybe we can store IP->view mapping in the LDAP database. That > >>>>>should be reliable if we assume that only TCP is used for connection to LDAP > >>>>>database. > >>>>It is not just about it being insecure, it is about it being wrong. > >>>>As soon as you have a bunch of clients behind a NAT this pans goes belly > >>>>up. > >>>I do not like this one either. I just wanted to list to options I could > >>>think of because I think supporting user-views on legacy clients is one > >>>of the major use-cases for this feature. > >>> > >>>bye, > >>>Sumit > >>> > >>>>>>As a alternative slapi-nis can provide one tree for each view. > >>>>This is the only alternative, if we decide to pursue it. > >>>> > >>>>Simo. > >>>> > >>>>-- > >>>>Simo Sorce * Red Hat, Inc * New York > >>>> > >>>>_______________________________________________ > >>>>Freeipa-devel mailing list > >>>>Freeipa-devel at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>_______________________________________________ > >>>Freeipa-devel mailing list > >>>Freeipa-devel at redhat.com > >>>https://www.redhat.com/mailman/listinfo/freeipa-devel > >> > >>Please correct me as I might be confused. > >>We have the compat tree now for legacy clients. It is also used by latest > >>SSSD clients to do special lookups, right? > > > >no, we discussed this with Alexander some time ago and he asked not to > >use the compat tree from SSSD but the extdom plugin because of the given > >limitations of the slapi-nis plugin. > > > >>The data in this tree comes from the SSSD on the server running in server > >>mode. > >>I wonder if we can say: here are replicas A, B, C that have vanilla "default > >>view", here are replicas K, L, M where the data is overwritten with a > >>special view (i.e. UID/GID fro ma special area) and then we have replicas > >>X,Y,Z that have a different overlay view. > >>It will be assumed that replicas A,B,C, serve clients in one "zone", new and > >>legacy, while K, L, M serve another zone and X, Y, Z serve the other one. > >>Would that work? > > > >Besides that it is very confusing it would be possible as long as the > >overrides from the special views are done by slapi-nis because SSSD on > >servers and replicas will always and only deliver the default view. > > Also, this would completely break DNS-based fail-over (based on SRV records) > because different replicas would provide different data. Good point. Additionally please note that the compat tree is for legacy clients where DNS-locations might not work at all. bye, Sumit > > In theory, it could be done with DNS-locations (which we repeatedly decided > not to support). In all cases, it requires re-configuration on client side > because support for 'locations' has to be explicitly enabled in SSSD. > > References: > http://www.freeipa.org/page/V3/DNS_Location_Mechanism > https://fedorahosted.org/freeipa/ticket/2008 > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Mon Jun 2 08:22:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Jun 2014 10:22:48 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140602081105.GU30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> <20140530134748.GO30381@localhost.localdomain> <538C2B98.3080901@redhat.com> <20140602081105.GU30381@localhost.localdomain> Message-ID: <538C3458.20905@redhat.com> On 2.6.2014 10:11, Sumit Bose wrote: > On Mon, Jun 02, 2014 at 09:45:28AM +0200, Petr Spacek wrote: >> On 30.5.2014 15:47, Sumit Bose wrote: >>> On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: >>>> On 05/30/2014 03:04 AM, Sumit Bose wrote: >>>>> On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: >>>>>> On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >>>>>>> On 29.5.2014 13:48, Sumit Bose wrote: >>>>>>>> == slapi-nis plugin/compat tree == >>>>>>>> The compat tree offers a simplified LDAP tree with user and group data >>>>>>>> for legacy clients. No data for this tree is stored on disk but it is >>>>>>>> always created on the fly. It has to be noted that legacy clients might >>>>>>>> be one of the major users of the user-views because chances are that >>>>>>>> they were attached to the legacy systems with legacy ID management which >>>>>>>> should be replaced by IPA. >>>>>>>> >>>>>>>> In contrast to the extdom plugin it is not possible to determine the >>>>>>>> client based on the DN because connection might be anonymous. The >>>>>>>> Slapi_PBlock contains the IP address of the client in >>>>>>>> SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>>>>>>> tree requires a reverse-DNS lookup which might be unreliable. If the >>>>>>>> reverse-DNS lookup was successful the slapi-nos plugin can follow the >>>>>>>> same steps as the extdom plugin to lookup up and apply the view. >>>>>>> Do we really want to base security decisions on reverse DNS resolution? >>>>>> No we do not want to play these games. >>>>>> >>>>>>> That >>>>>>> will be insecure. Attacker could tamper with reverse DNS to change UID/GID >>>>>>> mapping ... Maybe we can store IP->view mapping in the LDAP database. That >>>>>>> should be reliable if we assume that only TCP is used for connection to LDAP >>>>>>> database. >>>>>> It is not just about it being insecure, it is about it being wrong. >>>>>> As soon as you have a bunch of clients behind a NAT this pans goes belly >>>>>> up. >>>>> I do not like this one either. I just wanted to list to options I could >>>>> think of because I think supporting user-views on legacy clients is one >>>>> of the major use-cases for this feature. >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>>>>>> As a alternative slapi-nis can provide one tree for each view. >>>>>> This is the only alternative, if we decide to pursue it. >>>>>> >>>>>> Simo. >>>>>> >>>>>> -- >>>>>> Simo Sorce * Red Hat, Inc * New York >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> Please correct me as I might be confused. >>>> We have the compat tree now for legacy clients. It is also used by latest >>>> SSSD clients to do special lookups, right? >>> >>> no, we discussed this with Alexander some time ago and he asked not to >>> use the compat tree from SSSD but the extdom plugin because of the given >>> limitations of the slapi-nis plugin. >>> >>>> The data in this tree comes from the SSSD on the server running in server >>>> mode. >>>> I wonder if we can say: here are replicas A, B, C that have vanilla "default >>>> view", here are replicas K, L, M where the data is overwritten with a >>>> special view (i.e. UID/GID fro ma special area) and then we have replicas >>>> X,Y,Z that have a different overlay view. >>>> It will be assumed that replicas A,B,C, serve clients in one "zone", new and >>>> legacy, while K, L, M serve another zone and X, Y, Z serve the other one. >>>> Would that work? >>> >>> Besides that it is very confusing it would be possible as long as the >>> overrides from the special views are done by slapi-nis because SSSD on >>> servers and replicas will always and only deliver the default view. >> >> Also, this would completely break DNS-based fail-over (based on SRV records) >> because different replicas would provide different data. > > Good point. Additionally please note that the compat tree is for legacy > clients where DNS-locations might not work at all. It is designed in a way which is compatible with any standard-compliant client using DNS SRV records. SSSD is only one of them. See http://www.freeipa.org/page/V3/DNS_Location_Mechanism if you are interested in details. Petr^2 Spacek > > bye, > Sumit > >> >> In theory, it could be done with DNS-locations (which we repeatedly decided >> not to support). In all cases, it requires re-configuration on client side >> because support for 'locations' has to be explicitly enabled in SSSD. >> >> References: >> http://www.freeipa.org/page/V3/DNS_Location_Mechanism >> https://fedorahosted.org/freeipa/ticket/2008 >> >> -- >> Petr^2 Spacek From sbose at redhat.com Mon Jun 2 08:33:16 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 2 Jun 2014 10:33:16 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <538C3458.20905@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> <20140530134748.GO30381@localhost.localdomain> <538C2B98.3080901@redhat.com> <20140602081105.GU30381@localhost.localdomain> <538C3458.20905@redhat.com> Message-ID: <20140602083316.GV30381@localhost.localdomain> On Mon, Jun 02, 2014 at 10:22:48AM +0200, Petr Spacek wrote: > On 2.6.2014 10:11, Sumit Bose wrote: > >On Mon, Jun 02, 2014 at 09:45:28AM +0200, Petr Spacek wrote: > >>On 30.5.2014 15:47, Sumit Bose wrote: > >>>On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: > >>>>On 05/30/2014 03:04 AM, Sumit Bose wrote: > >>>>>On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: > >>>>>>On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: > >>>>>>>On 29.5.2014 13:48, Sumit Bose wrote: > >>>>>>>>== slapi-nis plugin/compat tree == > >>>>>>>>The compat tree offers a simplified LDAP tree with user and group data > >>>>>>>>for legacy clients. No data for this tree is stored on disk but it is > >>>>>>>>always created on the fly. It has to be noted that legacy clients might > >>>>>>>>be one of the major users of the user-views because chances are that > >>>>>>>>they were attached to the legacy systems with legacy ID management which > >>>>>>>>should be replaced by IPA. > >>>>>>>> > >>>>>>>>In contrast to the extdom plugin it is not possible to determine the > >>>>>>>>client based on the DN because connection might be anonymous. The > >>>>>>>>Slapi_PBlock contains the IP address of the client in > >>>>>>>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA > >>>>>>>>tree requires a reverse-DNS lookup which might be unreliable. If the > >>>>>>>>reverse-DNS lookup was successful the slapi-nos plugin can follow the > >>>>>>>>same steps as the extdom plugin to lookup up and apply the view. > >>>>>>>Do we really want to base security decisions on reverse DNS resolution? > >>>>>>No we do not want to play these games. > >>>>>> > >>>>>>>That > >>>>>>>will be insecure. Attacker could tamper with reverse DNS to change UID/GID > >>>>>>>mapping ... Maybe we can store IP->view mapping in the LDAP database. That > >>>>>>>should be reliable if we assume that only TCP is used for connection to LDAP > >>>>>>>database. > >>>>>>It is not just about it being insecure, it is about it being wrong. > >>>>>>As soon as you have a bunch of clients behind a NAT this pans goes belly > >>>>>>up. > >>>>>I do not like this one either. I just wanted to list to options I could > >>>>>think of because I think supporting user-views on legacy clients is one > >>>>>of the major use-cases for this feature. > >>>>> > >>>>>bye, > >>>>>Sumit > >>>>> > >>>>>>>>As a alternative slapi-nis can provide one tree for each view. > >>>>>>This is the only alternative, if we decide to pursue it. > >>>>>> > >>>>>>Simo. > >>>>>> > >>>>>>-- > >>>>>>Simo Sorce * Red Hat, Inc * New York > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Freeipa-devel mailing list > >>>>>>Freeipa-devel at redhat.com > >>>>>>https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>>>_______________________________________________ > >>>>>Freeipa-devel mailing list > >>>>>Freeipa-devel at redhat.com > >>>>>https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>> > >>>>Please correct me as I might be confused. > >>>>We have the compat tree now for legacy clients. It is also used by latest > >>>>SSSD clients to do special lookups, right? > >>> > >>>no, we discussed this with Alexander some time ago and he asked not to > >>>use the compat tree from SSSD but the extdom plugin because of the given > >>>limitations of the slapi-nis plugin. > >>> > >>>>The data in this tree comes from the SSSD on the server running in server > >>>>mode. > >>>>I wonder if we can say: here are replicas A, B, C that have vanilla "default > >>>>view", here are replicas K, L, M where the data is overwritten with a > >>>>special view (i.e. UID/GID fro ma special area) and then we have replicas > >>>>X,Y,Z that have a different overlay view. > >>>>It will be assumed that replicas A,B,C, serve clients in one "zone", new and > >>>>legacy, while K, L, M serve another zone and X, Y, Z serve the other one. > >>>>Would that work? > >>> > >>>Besides that it is very confusing it would be possible as long as the > >>>overrides from the special views are done by slapi-nis because SSSD on > >>>servers and replicas will always and only deliver the default view. > >> > >>Also, this would completely break DNS-based fail-over (based on SRV records) > >>because different replicas would provide different data. > > > >Good point. Additionally please note that the compat tree is for legacy > >clients where DNS-locations might not work at all. > > It is designed in a way which is compatible with any standard-compliant > client using DNS SRV records. SSSD is only one of them. > > See http://www.freeipa.org/page/V3/DNS_Location_Mechanism if you are > interested in details. yes, my point was that afaik e.g. pam_ldap or the Solaris LDAP utility cannot be configured to use SRV records to find a LDAP server, but expects plain DNS names or IP addresses. bye, Sumit > > Petr^2 Spacek > > > > >bye, > >Sumit > > > >> > >>In theory, it could be done with DNS-locations (which we repeatedly decided > >>not to support). In all cases, it requires re-configuration on client side > >>because support for 'locations' has to be explicitly enabled in SSSD. > >> > >>References: > >>http://www.freeipa.org/page/V3/DNS_Location_Mechanism > >>https://fedorahosted.org/freeipa/ticket/2008 > >> > >>-- > >>Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tbordaz at redhat.com Mon Jun 2 08:34:19 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 02 Jun 2014 10:34:19 +0200 Subject: [Freeipa-devel] User life cycle: plugins scope for staged users In-Reply-To: <5386D0F5.5040706@redhat.com> References: <537E0AAA.5090100@redhat.com> <538696D1.1000002@redhat.com> <5386D0F5.5040706@redhat.com> Message-ID: <538C370B.1010105@redhat.com> On 05/29/2014 08:17 AM, Martin Kosek wrote: > On 05/29/2014 04:09 AM, Dmitri Pal wrote: >> On 05/22/2014 10:33 AM, thierry bordaz wrote: >>> Hello, >>> >>> In order to provision staged users (account inactivated) with >>> there initial values: >>> >>> /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 >>> ----------------- >>> Added user "tb20" >>> ----------------- >>> User login: tb20 >>> First name: tb20 >>> Last name: tb20 >>> Full name: tb20 tb20 >>> Display name: tb20 tb20 >>> Initials: tt >>> Home directory: /home/tb20 >>> GECOS: tb20 tb20 >>> Login shell: /bin/sh >>> Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM >>> Email address: tb20 at idm.lab.bos.redhat.com >>> UID: -1 >>> GID: -1 >>> Account disabled: true >>> Password: False >>> Kerberos keys available: False >>> >>> ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager" >>> -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20 >>> dn: uid=tb20,cn=staged >>> users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, >>> dc=redhat,dc=com >>> displayName: tb20 tb20 >>> cn: tb20 tb20 >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalperson >>> objectClass: inetorgperson >>> objectClass: inetuser >>> objectClass: posixaccount >>> objectClass: krbprincipalaux >>> objectClass: krbticketpolicyaux >>> objectClass: ipaobject >>> objectClass: ipasshuser >>> objectClass: ipaSshGroupOfPubKeys >>> loginShell: /bin/sh >>> uidNumber: -1 >>> ipaUniqueID: autogenerate >>> gidNumber: -1 >>> gecos: tb20 tb20 >>> sn: tb20 >>> homeDirectory: /home/tb20 >>> uid: tb20 >>> mail: tb20 at idm.lab.bos.redhat.com >>> krbPrincipalName: tb20 at IDM.LAB.BOS.REDHAT.COM >>> givenName: tb20 >>> initials: tt >>> >>> I needed to resctrict the scope of the following plugins: >>> >>> dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config >>> nsslapd-pluginarg1: >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi >>> ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >>> Plugin,cn=plugins,cn=config >>> dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> dn: cn=MemberOf Plugin,cn=plugins,cn=config >>> memberofentryscope: >>> cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >>> >>> In fact I need them to not modify the added entry when it is added >>> under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX". >>> Now is it possible to limit those plugins scope to the >>> 'cn=accounts' part of the tree ? I guess not. >>> If it is not possible, a solution is to make the scope >>> multi-valued attributes or to introduce a new config attribute >>> '*notInScope' also multi-valued. >>> A problem is the 'cn=ipaUniqueID uniqueness' that rely on the >>> 'attribute uniqueness' plugin with a argv[ ], not really >>> convenient to pass 2 multivalued attributes. >>> >>> If anyone is having others solutions it would help me a lot :-) >>> >>> thanks >>> thierry >>> >>> >> The easiest solution IMO is to not treat staging area as an account area, i.e >> instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, >> cn=staging, dc=... > Actually, this almost exactly the DN I wrote in the RFE: > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status > > Proposed containers are: > > cn=staged users,cn=accounts,cn=provisioning,$SUFFIX > cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX I believe we want to enforce that attribute like 'uid' and 'ipaUniqueID' are unique in both cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX and cn=accounts,$SUFFIX A solution is to make attribute uniqueness covering both parts. But is that enough ? For example is it required that attribute uniqueness run also on 'cn=alt,$SUFFIX' ? An other solution is to exclude some parts. Like exlude 'cn=staged users,cn=account,cn=provisioning, $SUFFIX'. > >> This way if in future we will have some staging for other objects (for whatever >> reason) we will create containers under common "staging" area. >> I would also argue that "deleted" should not be under accounts. > Agreed. This will also make the plugin configuration (tree exclusion) easier. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From lkrispen at redhat.com Mon Jun 2 08:46:46 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 02 Jun 2014 10:46:46 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree Message-ID: <538C39F6.2080006@redhat.com> Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree There has been some discussion in comments in the ticket, but I'd like to open the discussion to a wider audience to get an agreement on what should be implemented, before writing a design spec. The implementation requires a new IPA plugin for 389 DS and eventually an enhancement of the 389 replication plugin (which depends on some decisions below). In the following I will use the terms ?topology plugin? for the new plugin and ?replication plugin? for the existing 389 multimaster replication plugin. Lets start with the requirements: What should be achieved by this RFE ? In my opinion there are three different levels of features to implement with this request - providing all replication configuration information consistent across all deployed servers on all servers, eg to easily visualize the replication topology. - Allowing to do sanity checks on replication configuration, denying modifications which would break replication topology or issue warnings. - Use the information in the shared tree to trigger changes to the replication configuration in the corresponding servers, this means to allow to completely control replication configuration with modifications of entries in the shared tree The main questions are 1] which information is needed in the shared tree (eg what params in the repl config should be modifiable) 2] how is the information organized and stored (layout of the repl config information shared tree) 3] how is the interaction of the info in the shared tree and configuration in cn=config and the interaction between the topology plugin and the replication plugin ad 1] to verify the topology, eg connectivity info about all existing replication agreements is needed, the replication agreements only contain info about the target, and the parameters for connection to the target, but not about the origin. If the data have to evaluated on any server, information about the origin has to be added, eg replicaID, serverID,... In addition, if agreement config has to be changed based on the shared tree all required parameters need to be present, eg replicatedAttributeList, strippedAttrs, replicationEnabled, ..... Replication agreements only provide information on connections where replication is configured, if connectivity is to be checked independent info about all deployed serevers/replicas is needed. If topology should be validated, do we need params definig requirements, eg each replica to be connected to 1,2,3,... others, type of topology (ring, mesh, star,.) ? ad 2] the data required are available in the replicationAgreement (and eventually replica) entries, but the question is if there should be a 1:1 relationship to entries in the shared tree or a condensed representation, if there should be a server or connection oriented view. In my opinion a 1:1 relation is straight forward, easy to handle and easy to extend (not the full data of a repl agreement need to be present, other attributes are possible). The downside may be a larger number of entries, but this is no problem for the directory server and replication and the utilities eg to visualize a topology will handle this. If the number of entries should be reduced information on multiple replication agreements would have to be stored in one entry, and the problem arises ho to group data belonging to one agreement. LDAP does not provide a simple way to group attribute values in one entry, so all the info related to one agreement (origin, target, replicated attrs and other repl configuration info) could be stored in a single attribute, which will make the attribute as nicely readable and managable as acis. If topology verification and connectivity check is an integral part of the feature, I think a connection oriented view is not sufficient, it might be incomplete, so a server view is required, the server entry would then have the connection information as subentries or as attributes. Ad 3] The replication configuration is stored under cn=config and can be modified either by ldap operations or by editing the dse.ldif. With the topology plugin another source of configuration changes comes into play. The first question is: which information has precendence ? I think if there is info in the shared tree it should be used, and the information in cn=config should be updated. This also means that the topology plugin needs to intercept all mods to the entries in cn=config and have them ignored and handle all updates to the shared tree and trigger changes to the cn=config entries, which then would trigger rebuilds of the in memory replication objects. Next question: How to handle changes directly done in the dse.ldif, if everything should be done by the topology plugin it would have to verify and compare the info in cn=config and in the shared tree at every startup of the directory server, which might be complicated by the fact that the replication plugin might already be started and repl agreemnts are active before the topology plugin is started and could do its work. (plugin starting order and dependencies need to be checked). Next next question: should there be a ?bootstrapping? of the config information in the shared tree ? I think yes, the topology plugin could check at startup if there is a representation of the config info in the shared tree and if not construct it, so after deployment and enabling of the topology plugin the information in the shared tree would be initialized. I think that not every part of the feature has to be handled in the topology plugin, we could also ask for enhancements in the 389 replication plugin itself. There could be an extension to the replica and replication agreement entries to reference an entry in the shared tree. The replication plugin could check at startup if these entries contain replication configuration attributes and if so use them, otherwise use the values in cn=config. The presence of the reference indicates to the topolgy plugin that initialization is done. In my opinion this would simplify the coordination at startup and avoid unnecessary revaluations and other deployments could benefit from this new feature in directory server (one could eg have one entry for replication argreements containing the fractional replication configuration ? and it would be identical on all servers) So my proposal would contain the following components 1] Store replication configuration in the shared tree in a combination of server and connection view (think we need both) and map replication configuration to these entries. I would prefer a direct mapping (with a subset of the cn=config attributes and required additions) 2] provide a topology plugin to do consistency checks and topology verification, handle updates to trigger modification changes in cn=config, intercept and reject direct mods to cn=config entries At startup verify if shared tree opbjects are present, initialize them if not, apply to cn=config if required 3] enhance replication plugin to handle config information in the shared tree. This would allow to consistently handle config changes either applied to the shared config, cn=config mods or des.ldif changes. This feature might also be interesting to other DS deployments From abokovoy at redhat.com Mon Jun 2 09:58:00 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Jun 2014 12:58:00 +0300 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140530082434.GB23849@redhat.com> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <538807D9.6080905@redhat.com> <20140530072009.GL30381@localhost.localdomain> <20140530082434.GB23849@redhat.com> Message-ID: <20140602095800.GI23849@redhat.com> On Fri, 30 May 2014, Alexander Bokovoy wrote: >On Fri, 30 May 2014, Sumit Bose wrote: >>On Fri, May 30, 2014 at 12:23:53AM -0400, Dmitri Pal wrote: >>>On 05/29/2014 01:31 PM, Simo Sorce wrote: >>>>On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >>>>>On 29.5.2014 13:48, Sumit Bose wrote: >>>>>>== slapi-nis plugin/compat tree == >>>>>>The compat tree offers a simplified LDAP tree with user and group data >>>>>>for legacy clients. No data for this tree is stored on disk but it is >>>>>>always created on the fly. It has to be noted that legacy clients might >>>>>>be one of the major users of the user-views because chances are that >>>>>>they were attached to the legacy systems with legacy ID management which >>>>>>should be replaced by IPA. >>>>>> >>>>>>In contrast to the extdom plugin it is not possible to determine the >>>>>>client based on the DN because connection might be anonymous. The >>>>>>Slapi_PBlock contains the IP address of the client in >>>>>>SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>>>>>tree requires a reverse-DNS lookup which might be unreliable. If the >>>>>>reverse-DNS lookup was successful the slapi-nos plugin can follow the >>>>>>same steps as the extdom plugin to lookup up and apply the view. >>>>>Do we really want to base security decisions on reverse DNS resolution? >>>>No we do not want to play these games. >>>> >>>>>That >>>>>will be insecure. Attacker could tamper with reverse DNS to change UID/GID >>>>>mapping ... Maybe we can store IP->view mapping in the LDAP database. That >>>>>should be reliable if we assume that only TCP is used for connection to LDAP >>>>>database. >>>>It is not just about it being insecure, it is about it being wrong. >>>>As soon as you have a bunch of clients behind a NAT this pans goes belly >>>>up. >>>> >>>>>>As a alternative slapi-nis can provide one tree for each view. >>>>This is the only alternative, if we decide to pursue it. >>>> >>>>Simo. >>>> >>>Can we at least do something like CoS and use the base compat tree and >>>overwrite just uid/gid on the fly instead of using the whole another view? >>>That would reduce the size of the additional views significantly and would >>>save cycles used for keeping each view in sync with underlying DB. In this >>>case there will be still one view and dynamic overwrite in the search >>>results. >> >>If we do not want to support all configured views what about making it >>configurable which view are delivered in separate trees by slapi-nis? >>- >>I do not know much about the slap-nis internal, but I could image that >>the memory requirement for a two layer cache (one global for the data >>from SSSD (default view) and one for each view with the override data) >>might be an issue. It would be nice if Alexander or Nalin can explain >>some of the current bottlenecks in slap-nis to see were it will get >>worse when supporting user-views in multiple trees? >Pretty bad. > >slapi-nis only serves the entries that were not found with the normal >search path. This implies there is always cost of a search over the main >tree. If a base DN is too generic, slapi-nis will happily return >everything what is cached and fits the filter. > >Now, we cannot rely on a client connection properties to segregate >the connections to different cached sub-trees. Reverse DNS is bad, IP >address handling is unreliable. The only way to differentiate would be >to have different base DN supplied by each client, maybe in the form of >multi-valued RDN (cn=compat+view=viewname,$SUFFIX). However, that would >add complication to slapi-nis map cache as data is evaluated once and >then inserted into the map cache while in this case a different view >would mean need to re-evaluate part of the entry or partially modify >returned object on the fly. > >Technically the latter is possible. Suppose on the first hit to >slapi-nis for a uid=foo we would insert its entry into the map cache >where each uidNumber/gidNumber has view name appended: > >uidNumber: 12344556 >gidNumber: 12344556 >uidNumber_legacy_client1: 110000 >gidNumber_legacy_client1: 110001 >uidNumber_legacy_client2: 210000 >gidNumber_legacy_client2: 210001 >uidNumber_legacy_client3: 310000 >gidNumber_legacy_client3: 310001 > >And then have a filter for the resulting object fetched from the >map cache prior to pushing it out to the client. > >The main trouble here is that we have to post process the data in map >cache and also the fact that we'll have more triggers to invalidate >cached objects, including the ones coming from nss requests which >officially have no DN in the main tree to get a trigger for them. > > >>Maybe running a separate 389ds instance for the user-views might be an >>alternative here as well? Alexanders work for the Global Catalog might >>come handy here because it sets up and configures a separate instance >>which reads data from the main one. >I don't think it makes problem any easier as we really have to solve the >issue of addressing client connection differences first. Whether the >data is served by a separate instance or not is irrelevant here. Additionally, there is design issue for SSSD interactions. For legacy clients, if we rely on the base DN, there is no need to guess the view as described above. For SSSD clients coming to extdom plugin, we have SASL GSSAPI DN (SLAPI_CONN_DN property) which we can uniquely map to the host because every host/foo.bar.zz service is implemented as the host object. Now, if the host has link to the view, everything is good but managing that is hard for admins (every host needs to have view set separately). If the host belongs to some hostgroup and then hostgroup has link to the view, we get possible ambiguity due to the fact that we don't know which hostgroup is considered prime one here. Admins will have to make sure there is only single hostgroup the host belongs to with a view set in the host group. -- / Alexander Bokovoy From pspacek at redhat.com Mon Jun 2 10:00:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Jun 2014 12:00:18 +0200 Subject: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup In-Reply-To: <20140602083316.GV30381@localhost.localdomain> References: <20140529114809.GJ30381@localhost.localdomain> <5387656A.2080605@redhat.com> <1401384664.3590.19.camel@willson.li.ssimo.org> <20140530070411.GK30381@localhost.localdomain> <538883EE.3090207@redhat.com> <20140530134748.GO30381@localhost.localdomain> <538C2B98.3080901@redhat.com> <20140602081105.GU30381@localhost.localdomain> <538C3458.20905@redhat.com> <20140602083316.GV30381@localhost.localdomain> Message-ID: <538C4B32.1000205@redhat.com> On 2.6.2014 10:33, Sumit Bose wrote: > On Mon, Jun 02, 2014 at 10:22:48AM +0200, Petr Spacek wrote: >> On 2.6.2014 10:11, Sumit Bose wrote: >>> On Mon, Jun 02, 2014 at 09:45:28AM +0200, Petr Spacek wrote: >>>> On 30.5.2014 15:47, Sumit Bose wrote: >>>>> On Fri, May 30, 2014 at 09:13:18AM -0400, Dmitri Pal wrote: >>>>>> On 05/30/2014 03:04 AM, Sumit Bose wrote: >>>>>>> On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote: >>>>>>>> On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote: >>>>>>>>> On 29.5.2014 13:48, Sumit Bose wrote: >>>>>>>>>> == slapi-nis plugin/compat tree == >>>>>>>>>> The compat tree offers a simplified LDAP tree with user and group data >>>>>>>>>> for legacy clients. No data for this tree is stored on disk but it is >>>>>>>>>> always created on the fly. It has to be noted that legacy clients might >>>>>>>>>> be one of the major users of the user-views because chances are that >>>>>>>>>> they were attached to the legacy systems with legacy ID management which >>>>>>>>>> should be replaced by IPA. >>>>>>>>>> >>>>>>>>>> In contrast to the extdom plugin it is not possible to determine the >>>>>>>>>> client based on the DN because connection might be anonymous. The >>>>>>>>>> Slapi_PBlock contains the IP address of the client in >>>>>>>>>> SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA >>>>>>>>>> tree requires a reverse-DNS lookup which might be unreliable. If the >>>>>>>>>> reverse-DNS lookup was successful the slapi-nos plugin can follow the >>>>>>>>>> same steps as the extdom plugin to lookup up and apply the view. >>>>>>>>> Do we really want to base security decisions on reverse DNS resolution? >>>>>>>> No we do not want to play these games. >>>>>>>> >>>>>>>>> That >>>>>>>>> will be insecure. Attacker could tamper with reverse DNS to change UID/GID >>>>>>>>> mapping ... Maybe we can store IP->view mapping in the LDAP database. That >>>>>>>>> should be reliable if we assume that only TCP is used for connection to LDAP >>>>>>>>> database. >>>>>>>> It is not just about it being insecure, it is about it being wrong. >>>>>>>> As soon as you have a bunch of clients behind a NAT this pans goes belly >>>>>>>> up. >>>>>>> I do not like this one either. I just wanted to list to options I could >>>>>>> think of because I think supporting user-views on legacy clients is one >>>>>>> of the major use-cases for this feature. >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>>>>>> As a alternative slapi-nis can provide one tree for each view. >>>>>>>> This is the only alternative, if we decide to pursue it. >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>>> -- >>>>>>>> Simo Sorce * Red Hat, Inc * New York >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-devel mailing list >>>>>>>> Freeipa-devel at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> Please correct me as I might be confused. >>>>>> We have the compat tree now for legacy clients. It is also used by latest >>>>>> SSSD clients to do special lookups, right? >>>>> >>>>> no, we discussed this with Alexander some time ago and he asked not to >>>>> use the compat tree from SSSD but the extdom plugin because of the given >>>>> limitations of the slapi-nis plugin. >>>>> >>>>>> The data in this tree comes from the SSSD on the server running in server >>>>>> mode. >>>>>> I wonder if we can say: here are replicas A, B, C that have vanilla "default >>>>>> view", here are replicas K, L, M where the data is overwritten with a >>>>>> special view (i.e. UID/GID fro ma special area) and then we have replicas >>>>>> X,Y,Z that have a different overlay view. >>>>>> It will be assumed that replicas A,B,C, serve clients in one "zone", new and >>>>>> legacy, while K, L, M serve another zone and X, Y, Z serve the other one. >>>>>> Would that work? >>>>> >>>>> Besides that it is very confusing it would be possible as long as the >>>>> overrides from the special views are done by slapi-nis because SSSD on >>>>> servers and replicas will always and only deliver the default view. >>>> >>>> Also, this would completely break DNS-based fail-over (based on SRV records) >>>> because different replicas would provide different data. >>> >>> Good point. Additionally please note that the compat tree is for legacy >>> clients where DNS-locations might not work at all. >> >> It is designed in a way which is compatible with any standard-compliant >> client using DNS SRV records. SSSD is only one of them. >> >> See http://www.freeipa.org/page/V3/DNS_Location_Mechanism if you are >> interested in details. > > yes, my point was that afaik e.g. pam_ldap or the Solaris LDAP utility > cannot be configured to use SRV records to find a LDAP server, but > expects plain DNS names or IP addresses. Oh, in that case we are not adding any new problem (from configuration point of view) because it already is a nightmare :-) You can either: - use DNS locations - and have functional fail-over with ability to add/remove replicas as needed (without further reconfiguration on client side) or - use replica-name/IP address directly - then you don't have any problem with SRV records Petr^2 Spacek > > bye, > Sumit > >> >> Petr^2 Spacek >> >>> >>> bye, >>> Sumit >>> >>>> >>>> In theory, it could be done with DNS-locations (which we repeatedly decided >>>> not to support). In all cases, it requires re-configuration on client side >>>> because support for 'locations' has to be explicitly enabled in SSSD. >>>> >>>> References: >>>> http://www.freeipa.org/page/V3/DNS_Location_Mechanism >>>> https://fedorahosted.org/freeipa/ticket/2008 >>>> >>>> -- >>>> Petr^2 Spacek From tbordaz at redhat.com Mon Jun 2 10:19:57 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 02 Jun 2014 12:19:57 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <53888859.2060202@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> <53888670.4090605@redhat.com> <53888859.2060202@redhat.com> Message-ID: <538C4FCD.2070204@redhat.com> On 05/30/2014 03:32 PM, Jan Cholasta wrote: > On 30.5.2014 15:24, Petr Viktorin wrote: >> On 05/30/2014 08:37 AM, Martin Kosek wrote: >>> On 05/29/2014 08:14 PM, Dmitri Pal wrote: >>>> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>>>> This, I believe, has already been covered, but I'm concerned >>>>>>>>>> with the >>>>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>>>> >>>>>>>>>> I think use of "inactive" and "active" to describe users >>>>>>>>>> might be >>>>>>>>>> confusing since there is already an account enable/disable >>>>>>>>>> command. >>>>>>>>>> This >>>>>>>>>> on top of unlock, are there now 3 possible boolean states a >>>>>>>>>> user can >>>>>>>>>> be >>>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>>>> deleted/active and staged/active? >>>>>>>>>> >>>>>>>>> Agree, we should only have "ipa user-unstage " and not >>>>>>>>> call >>>>>>>>> this operations with words like active/inactive. >>>>>>>>> >>>>>>>>> User's in the staging area are not inactive, they are *not* >>>>>>>>> users yet in >>>>>>>>> the first place. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>> Ok. Let us consolidate the decisions, I think we are now running >>>>>>>> in circles. >>>>>>>> Let me start from Petr3's API proposal which was a functionally >>>>>>>> complete >>>>>>>> proposal and start from there: >>>>>>>> >>>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>>>> ... >>>>>>>>> My proposal would be that the move commands use the verb for the >>>>>>>>> target >>>>>>>>> and an >>>>>>>>> option for the source, and add/mod use an option for the >>>>>>>>> container: >>>>>>>>> >>>>>>>>> 1) adding a new user >>>>>>>>> (to active) ipa user-add tuser ... >>>>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>>>> Ok. >>>>>>>> >>>>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>>>> Not needed. >>>>>>>> >>>>>>>>> 2) moving to main >>>>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>>>> (from del) ipa user-activate tuser --deleted >>>>>>>> We need both, alternative is Simo's proposal: >>>>>>>> >>>>>>>> ipa user-unstage >>>>>>>> ipa user-undelete >>>>>>>> >>>>>>>> I personally like unstage and undelete commands, I would go with >>>>>>>> those. >>>>>>> Sorry for coming late to the party. >>>>>>> I strongly do not like "unstage" >>>>>>> This suggests that the user will be removed from staged but does >>>>>>> not indicate >>>>>>> that the full user will be created. >>>>>>> As I suggested elsewhere provision-user or user-provision (or may >>>>>>> be even >>>>>>> user-add --from-stage) would be better. >>>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating >>>>>> unstaging operation >>>>>> could get messy and would not create the right API. Using a >>>>>> separate call would >>>>>> be cleaner. As we see, choosing the right action term has proven >>>>>> very difficult >>>>>> - everyone has strong opinion on the command name :-) >>>>>> >>>>>> I already saw user-activate and user-unstage to be trashed so I am >>>>>> thinking >>>>>> what we are left with. I am still fan of user-unstage, >>>>>> user-provision is not >>>>>> telling me much more than user-unstage. >>>>>> >>>>>>>>> 3) moving to deleted >>>>>>>>> (from active) ipa user-del tuser >>>>>>>> Ok. >>>>>>>> >>>>>>>>> (from stage) ipa user-del tuser --staged >>>>>>>> IMO staged deleted users should not be moved to deleted >>>>>>>> container, but simply >>>>>>>> permanently deleted. As Simo noted, staged user are not real >>>>>>>> users, just >>>>>>>> incomplete users. >>>>>>>> >>>>>>>>> 4) moving to stage >>>>>>>>> (from active) ipa user-stage tuser >>>>>>> >>>>>>> This was suggested for completeness. >>>>>>> I think we are cutting corners but I would not insist here. >>>>>>> >>>>>>>>> (from del) ipa user-stage tuser --deleted >>>>>>>> None of the commands are needed for the basic workflow. >>>>>>> But this is a valid use case. I created a user, deleted it and >>>>>>> want to rebuild >>>>>>> it becuase something got corrupted in the original entry. I agree >>>>>>> it is not a >>>>>>> primary use case but then we should have a ticket to track this >>>>>>> RFE for >>>>>>> future. >>>>>> This was not about cutting corners, this was about what operation >>>>>> makes sense >>>>>> and what we should support. Stage was defined as a tree with >>>>>> incomplete user, >>>>>> thus this proposal - Simo was not very OK with this workflow. >>>>>> >>>>>>>>> 5) modifying >>>>>>>>> (in active) ipa user-mod tuser ... >>>>>>>> Ok. >>>>>>>> >>>>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>>>> Simo did not like this command, I would personally add it. As >>>>>>>> long as we have >>>>>>>> "ipa user-add --staged", we should also have an option to delete >>>>>>>> and modify >>>>>>>> user in staged area. >>>>>>>> >>>>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>>>> Not needed. >>>>>>>> >>>>>>>> Is this acceptable for everyone? If yes, the next step would be >>>>>>>> for Thierry >>>>>>>> to update the design page with new proposals. >>>>>>>> >>>>>>>> Martin >>>>>> Let me try to consolidate again the proposals and changes for the >>>>>> workflow&API >>>>>> we have so far: >>>>>> >>>>>> 1) Manipulating staged users >>>>>> - staged users must have UID RDN >>>>>> - UID uniqueness plugin should not be enforcing in staging area >>>>>> - we do not want it in user plugin as it requires different >>>>>> parameters and >>>>>> objectclasses >>>>>> - API: >>>>>> ipa stage-user-add >>>>>> ipa stage-user-mod >>>>>> ipa stage-user-find >>>>>> ipa stage-user-del >>>>>> >>>>>> 2) Activating staged user >>>>>> - activation will not do MODRDN, it will create a new user in >>>>>> active container >>>>>> and then delete the old one (to create right structural objectclass >>>>>> set) >>>>>> - for now, we need to allow operator delete any user in staged and >>>>>> add any user >>>>>> in active tree >>>>>> - API >>>>>> ipa stage-user-activate >>>>>> - other options mentioned in the past were user-unstage and >>>>>> user-activate >>>>>> >>>>>> 3) Manipulating deleted users >>>>>> - deletion and undeletion will do MODRDN and will use the ACI that >>>>>> Thierry >>>>>> implemented >>>>>> - API >>>>>> ipa user-del >>>>>> ipa user-undel OR ipa user-undelete >>>>>> - Dmitri mentioned that he would like to see the move from deleted >>>>>> to staged. I >>>>>> would do it via flag: >>>>>> ipa user-undel --to-stage >>>>>> >>>>>> >>>>>> Does that look better now? Thanks, >>>>> Yes, although I do not see the need for --to-stage honestly. >>>> I agree we can just leave it as a future ticket. >>> >>> I think Simo's thoughts were different - he did not opposed to this >>> part >>> because it is too much work (it shouldn't be), but because he did not >>> want that >>> part of the workflow. Given the simplicity of this part, I see 2 >>> options: >>> 1) Do it and do it together with other API is it just one MODRDN >>> command >>> 2) Decide we do not want to do it, i.e. do not file any RFE >>> >>>> Rest looks OK. >>> >>> It should be fine, just one command could done differently to confine >>> it better >>> as per Honza's idea: >>> >>> ipa stageduser-add --from-deleted username >> >> Do we want that to take all of stageduser-add's options? >> Should we use somrthing like stageduser-undel instead? > > stageduser-undel suggests it's opposite of stageduser-del, which it is > not. An alternative would be something like > stageduser-add-from-deleted, but that's really long, hence my proposal > to use stageduser-add. I have also a preference for '--from-deleted' option rather than a new verb. IMHO 'Delete' -> 'Stage' would be a quite rare and using an option shows that it is a special case. Regarding generate attribute, Delete users have final unique value (ipaUniqueID, uidNumber..) should we return the values to standard "staging" values ('autogenerate', -1) ? I believe yes. Also a Deleted user is booking an ipaUniqueID/uidNumber value, so an other active entry can not use these values. If we move that user out of the scope of attribute uniqueness, an other staging entry may pick up these values. Is it a risk ? For example, if on a machine I authenticate with entry A that contains values identical from old entry B, may I get the entry B authorisations on an other machine (where deletion of entry B has not yet occur) ? > >> >>> >>> Thierry, you know what to do :-) >>> >>> Martin >>> >> >> > > From mkosek at redhat.com Mon Jun 2 10:32:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Jun 2014 12:32:01 +0200 Subject: [Freeipa-devel] User life cycle: question regarding the design In-Reply-To: <538C4FCD.2070204@redhat.com> References: <537B821F.1000901@redhat.com> <537BBB4D.8030000@redhat.com> <537CB1BD.80707@redhat.com> <1400696063.7561.31.camel@willson.li.ssimo.org> <537CF952.60301@redhat.com> <537D0866.60706@redhat.com> <537DFD21.7040704@redhat.com> <1400779674.7561.97.camel@willson.li.ssimo.org> <537EE125.20404@redhat.com> <537EEB9E.4050306@redhat.com> <537F5799.9060906@redhat.com> <1400856930.7561.129.camel@willson.li.ssimo.org> <5382D607.5070407@redhat.com> <5386AA1E.3050505@redhat.com> <5386E51C.4020704@redhat.com> <1401367153.3590.8.camel@willson.li.ssimo.org> <538778F2.6000504@redhat.com> <53882718.1040907@redhat.com> <53888670.4090605@redhat.com> <53888859.2060202@redhat.com> <538C4FCD.2070204@redhat.com> Message-ID: <538C52A1.5020600@redhat.com> On 06/02/2014 12:19 PM, thierry bordaz wrote: > On 05/30/2014 03:32 PM, Jan Cholasta wrote: >> On 30.5.2014 15:24, Petr Viktorin wrote: >>> On 05/30/2014 08:37 AM, Martin Kosek wrote: >>>> On 05/29/2014 08:14 PM, Dmitri Pal wrote: >>>>> On 05/29/2014 08:39 AM, Simo Sorce wrote: >>>>>> On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote: >>>>>>> On 05/29/2014 05:31 AM, Dmitri Pal wrote: >>>>>>>> On 05/26/2014 01:49 AM, Martin Kosek wrote: >>>>>>>>> On 05/23/2014 04:55 PM, Simo Sorce wrote: >>>>>>>>>> On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote: >>>>>>>>>>> This, I believe, has already been covered, but I'm concerned >>>>>>>>>>> with the >>>>>>>>>>> (over)use of active/inactive in this discussion. >>>>>>>>>>> >>>>>>>>>>> I think use of "inactive" and "active" to describe users might be >>>>>>>>>>> confusing since there is already an account enable/disable >>>>>>>>>>> command. >>>>>>>>>>> This >>>>>>>>>>> on top of unlock, are there now 3 possible boolean states a >>>>>>>>>>> user can >>>>>>>>>>> be >>>>>>>>>>> in? locked/unlocked, enabled/disabled, active/inactive, plus >>>>>>>>>>> deleted/active and staged/active? >>>>>>>>>>> >>>>>>>>>> Agree, we should only have "ipa user-unstage " and not >>>>>>>>>> call >>>>>>>>>> this operations with words like active/inactive. >>>>>>>>>> >>>>>>>>>> User's in the staging area are not inactive, they are *not* >>>>>>>>>> users yet in >>>>>>>>>> the first place. >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>>> >>>>>>>>> Ok. Let us consolidate the decisions, I think we are now running >>>>>>>>> in circles. >>>>>>>>> Let me start from Petr3's API proposal which was a functionally >>>>>>>>> complete >>>>>>>>> proposal and start from there: >>>>>>>>> >>>>>>>>> On 05/22/2014 10:47 AM, Petr Viktorin wrote: >>>>>>>>>> ... >>>>>>>>>> My proposal would be that the move commands use the verb for the >>>>>>>>>> target >>>>>>>>>> and an >>>>>>>>>> option for the source, and add/mod use an option for the container: >>>>>>>>>> >>>>>>>>>> 1) adding a new user >>>>>>>>>> (to active) ipa user-add tuser ... >>>>>>>>>> (to stage) ipa user-add tuser --staged ... >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>>> (to deleted) ipa user-add tuser --deleted ... (*) >>>>>>>>> Not needed. >>>>>>>>> >>>>>>>>>> 2) moving to main >>>>>>>>>> (from stage) ipa user-activate tuser (**) >>>>>>>>>> (from del) ipa user-activate tuser --deleted >>>>>>>>> We need both, alternative is Simo's proposal: >>>>>>>>> >>>>>>>>> ipa user-unstage >>>>>>>>> ipa user-undelete >>>>>>>>> >>>>>>>>> I personally like unstage and undelete commands, I would go with >>>>>>>>> those. >>>>>>>> Sorry for coming late to the party. >>>>>>>> I strongly do not like "unstage" >>>>>>>> This suggests that the user will be removed from staged but does >>>>>>>> not indicate >>>>>>>> that the full user will be created. >>>>>>>> As I suggested elsewhere provision-user or user-provision (or may >>>>>>>> be even >>>>>>>> user-add --from-stage) would be better. >>>>>>> As Petr3 already noted on 05/19/2014 03:19 PM, integrating >>>>>>> unstaging operation >>>>>>> could get messy and would not create the right API. Using a >>>>>>> separate call would >>>>>>> be cleaner. As we see, choosing the right action term has proven >>>>>>> very difficult >>>>>>> - everyone has strong opinion on the command name :-) >>>>>>> >>>>>>> I already saw user-activate and user-unstage to be trashed so I am >>>>>>> thinking >>>>>>> what we are left with. I am still fan of user-unstage, >>>>>>> user-provision is not >>>>>>> telling me much more than user-unstage. >>>>>>> >>>>>>>>>> 3) moving to deleted >>>>>>>>>> (from active) ipa user-del tuser >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>>> (from stage) ipa user-del tuser --staged >>>>>>>>> IMO staged deleted users should not be moved to deleted >>>>>>>>> container, but simply >>>>>>>>> permanently deleted. As Simo noted, staged user are not real >>>>>>>>> users, just >>>>>>>>> incomplete users. >>>>>>>>> >>>>>>>>>> 4) moving to stage >>>>>>>>>> (from active) ipa user-stage tuser >>>>>>>> >>>>>>>> This was suggested for completeness. >>>>>>>> I think we are cutting corners but I would not insist here. >>>>>>>> >>>>>>>>>> (from del) ipa user-stage tuser --deleted >>>>>>>>> None of the commands are needed for the basic workflow. >>>>>>>> But this is a valid use case. I created a user, deleted it and >>>>>>>> want to rebuild >>>>>>>> it becuase something got corrupted in the original entry. I agree >>>>>>>> it is not a >>>>>>>> primary use case but then we should have a ticket to track this >>>>>>>> RFE for >>>>>>>> future. >>>>>>> This was not about cutting corners, this was about what operation >>>>>>> makes sense >>>>>>> and what we should support. Stage was defined as a tree with >>>>>>> incomplete user, >>>>>>> thus this proposal - Simo was not very OK with this workflow. >>>>>>> >>>>>>>>>> 5) modifying >>>>>>>>>> (in active) ipa user-mod tuser ... >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>>> (in stage) ipa user-mod tuser --staged ... >>>>>>>>> Simo did not like this command, I would personally add it. As >>>>>>>>> long as we have >>>>>>>>> "ipa user-add --staged", we should also have an option to delete >>>>>>>>> and modify >>>>>>>>> user in staged area. >>>>>>>>> >>>>>>>>>> (in del) ipa user-mod tuser --deleted ... >>>>>>>>> Not needed. >>>>>>>>> >>>>>>>>> Is this acceptable for everyone? If yes, the next step would be >>>>>>>>> for Thierry >>>>>>>>> to update the design page with new proposals. >>>>>>>>> >>>>>>>>> Martin >>>>>>> Let me try to consolidate again the proposals and changes for the >>>>>>> workflow&API >>>>>>> we have so far: >>>>>>> >>>>>>> 1) Manipulating staged users >>>>>>> - staged users must have UID RDN >>>>>>> - UID uniqueness plugin should not be enforcing in staging area >>>>>>> - we do not want it in user plugin as it requires different >>>>>>> parameters and >>>>>>> objectclasses >>>>>>> - API: >>>>>>> ipa stage-user-add >>>>>>> ipa stage-user-mod >>>>>>> ipa stage-user-find >>>>>>> ipa stage-user-del >>>>>>> >>>>>>> 2) Activating staged user >>>>>>> - activation will not do MODRDN, it will create a new user in >>>>>>> active container >>>>>>> and then delete the old one (to create right structural objectclass >>>>>>> set) >>>>>>> - for now, we need to allow operator delete any user in staged and >>>>>>> add any user >>>>>>> in active tree >>>>>>> - API >>>>>>> ipa stage-user-activate >>>>>>> - other options mentioned in the past were user-unstage and >>>>>>> user-activate >>>>>>> >>>>>>> 3) Manipulating deleted users >>>>>>> - deletion and undeletion will do MODRDN and will use the ACI that >>>>>>> Thierry >>>>>>> implemented >>>>>>> - API >>>>>>> ipa user-del >>>>>>> ipa user-undel OR ipa user-undelete >>>>>>> - Dmitri mentioned that he would like to see the move from deleted >>>>>>> to staged. I >>>>>>> would do it via flag: >>>>>>> ipa user-undel --to-stage >>>>>>> >>>>>>> >>>>>>> Does that look better now? Thanks, >>>>>> Yes, although I do not see the need for --to-stage honestly. >>>>> I agree we can just leave it as a future ticket. >>>> >>>> I think Simo's thoughts were different - he did not opposed to this part >>>> because it is too much work (it shouldn't be), but because he did not >>>> want that >>>> part of the workflow. Given the simplicity of this part, I see 2 options: >>>> 1) Do it and do it together with other API is it just one MODRDN command >>>> 2) Decide we do not want to do it, i.e. do not file any RFE >>>> >>>>> Rest looks OK. >>>> >>>> It should be fine, just one command could done differently to confine >>>> it better >>>> as per Honza's idea: >>>> >>>> ipa stageduser-add --from-deleted username >>> >>> Do we want that to take all of stageduser-add's options? >>> Should we use somrthing like stageduser-undel instead? >> >> stageduser-undel suggests it's opposite of stageduser-del, which it is not. >> An alternative would be something like stageduser-add-from-deleted, but >> that's really long, hence my proposal to use stageduser-add. > > I have also a preference for '--from-deleted' option rather than a new verb. > IMHO 'Delete' -> 'Stage' would be a quite rare and using an option shows that > it is a special case. > > > > Regarding generate attribute, Delete users have final unique value > (ipaUniqueID, uidNumber..) should we return the values to standard "staging" > values ('autogenerate', -1) ? I believe yes. I do not think you want UID and GID reset when you undelete a user or move it to staging tree by default. When a person that left a company returns, you want him to be able to access his old files etc. Same for ipaUniqueID, I do not see value in resetting it when we are dealing with the same user. > Also a Deleted user is booking an ipaUniqueID/uidNumber value, so an other > active entry can not use these values. If we move that user out of the scope of > attribute uniqueness, an other staging entry may pick up these values. Is it a > risk ? It is a risk. But I am thinking that given that - the user should be in a staging area for a limited period time - DNA plugin will not re-use this number for new users anyway if not instructed differently - DS will prevent moving entry to active tree if there is another user with the same UID it is acceptable. > For example, if on a machine I authenticate with entry A that contains values > identical from old entry B, may I get the entry B authorisations on an other > machine (where deletion of entry B has not yet occur) ? I think we are over-complicating the issue. This should not happen if replication is OK. If replication is not OK, you could as well authenticate with entry A which was already deleted on other replica. Martin From mkosek at redhat.com Mon Jun 2 10:58:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Jun 2014 12:58:44 +0200 Subject: [Freeipa-devel] [PATCH] 0564 Add read permissions for automember tasks In-Reply-To: <5388810B.3010103@redhat.com> References: <5388810B.3010103@redhat.com> Message-ID: <538C58E4.2030308@redhat.com> On 05/30/2014 03:00 PM, Petr Viktorin wrote: > I've noticed tests failing because the admin has no access to automember tasks. > > This is because automember task admins don't have read access to the tasks, and > when the code doesn't find the task it assumes the task is already done. > > This adds the read permission both to the admins group, and to those with the > 'Automember Task Administrator' privilege. > Yup, this fixed the issues. I also tested a user with Automember Task Administrator privilege and task could be read without any problem. ACK. Martin From pviktori at redhat.com Mon Jun 2 11:07:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Jun 2014 13:07:51 +0200 Subject: [Freeipa-devel] [PATCH] 0564 Add read permissions for automember tasks In-Reply-To: <538C58E4.2030308@redhat.com> References: <5388810B.3010103@redhat.com> <538C58E4.2030308@redhat.com> Message-ID: <538C5B07.3090007@redhat.com> On 06/02/2014 12:58 PM, Martin Kosek wrote: > On 05/30/2014 03:00 PM, Petr Viktorin wrote: >> I've noticed tests failing because the admin has no access to automember tasks. >> >> This is because automember task admins don't have read access to the tasks, and >> when the code doesn't find the task it assumes the task is already done. >> >> This adds the read permission both to the admins group, and to those with the >> 'Automember Task Administrator' privilege. >> > > Yup, this fixed the issues. I also tested a user with Automember Task > Administrator privilege and task could be read without any problem. > > ACK. > > Martin > Thanks, pushed to master: 93ad23912e3bb73fc3e54d2b6734748a55fc933a -- Petr? From mbasti at redhat.com Mon Jun 2 11:50:18 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Jun 2014 13:50:18 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> Message-ID: <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> Rebased patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0029-5-Allows-to-sort-non-text-entries.patch Type: text/x-patch Size: 1845 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0030-5-DNSName-type.patch Type: text/x-patch Size: 4157 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0031-5-DNSNameParam-parameter.patch Type: text/x-patch Size: 5363 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0032-5-dns_name_values-capability-added.patch Type: text/x-patch Size: 4482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0034-5-get_ancestors_primary_keys-clone.patch Type: text/x-patch Size: 17348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0035-5-CLI-conversion-of-DNSName-type.patch Type: text/x-patch Size: 1140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0036-5-DNSName-conversion-in-ipaldap.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0037-5-Modified-has_output-attributes.patch Type: text/x-patch Size: 2925 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0038-5-Modified-dns-related-global-functions.patch Type: text/x-patch Size: 15371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0039-5-Modified-records-and-zone-parameters-to-use-DNSNameP.patch Type: text/x-patch Size: 45679 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0040-5-Modified-record-and-zone-class-to-support-IDN.patch Type: text/x-patch Size: 27672 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0041-5-_domain_name_validatord-moved-from-DNS-to-realmdomai.patch Type: text/x-patch Size: 2788 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0042-5-move-hostname-validation-from-DNS-to-hosts.patch Type: text/x-patch Size: 1840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0045-5-DNS-modified-tests.patch Type: text/x-patch Size: 57143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0046-5-DNS-new-tests.patch Type: text/x-patch Size: 34437 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0047-5-PTR-record-target-can-be-relative.patch Type: text/x-patch Size: 4147 bytes Desc: not available URL: From mbasti at redhat.com Mon Jun 2 11:57:43 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Jun 2014 13:57:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> Message-ID: <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> Rebased patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0052-2-Separate-master-and-forward-DNS-zones.patch Type: text/x-patch Size: 21569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0053-2-Prevent-commands-to-modify-different-type-of-a-zone.patch Type: text/x-patch Size: 11555 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-2-Create-BASE-zone-class.patch Type: text/x-patch Size: 39993 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0055-2-Tests-DNS-forward-zones.patch Type: text/x-patch Size: 29038 bytes Desc: not available URL: From simo at redhat.com Mon Jun 2 12:59:24 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jun 2014 08:59:24 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C39F6.2080006@redhat.com> References: <538C39F6.2080006@redhat.com> Message-ID: <1401713964.6654.29.camel@willson.usersys.redhat.com> First of all, very good summary, thanks a lot! Replies in line. On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote: > Ticket 4302 is a request for an enhancement: Move replication topology > to the shared tree > > > There has been some discussion in comments in the ticket, but I'd like > to open the discussion to a wider audience to get an agreement on what > should be implemented, before writing a design spec. > > The implementation requires a new IPA plugin for 389 DS and eventually > an enhancement of the 389 replication plugin (which depends on some > decisions below). In the following I will use the terms ?topology > plugin? for the new plugin and ?replication plugin? for the existing 389 > multimaster replication plugin. > > > Lets start with the requirements: What should be achieved by this RFE ? > > In my opinion there are three different levels of features to implement > with this request > > - providing all replication configuration information consistent across > all deployed servers on all servers, eg to easily visualize the > replication topology. > > - Allowing to do sanity checks on replication configuration, denying > modifications which would break replication topology or issue warnings. > > - Use the information in the shared tree to trigger changes to the > replication configuration in the corresponding servers, this means to > allow to completely control replication configuration with modifications > of entries in the shared tree > > > The main questions are > > 1] which information is needed in the shared tree (eg what params in the > repl config should be modifiable) > > 2] how is the information organized and stored (layout of the repl > config information shared tree) > > 3] how is the interaction of the info in the shared tree and > configuration in cn=config and the interaction between the topology > plugin and the replication plugin > > > ad 1] to verify the topology, eg connectivity info about all existing > replication agreements is needed, the replication agreements only > contain info about the target, and the parameters for connection to the > target, but not about the origin. If the data have to evaluated on any > server, information about the origin has to be added, eg replicaID, > serverID,... > > In addition, if agreement config has to be changed based on the shared > tree all required parameters need to be present, eg > replicatedAttributeList, strippedAttrs, replicationEnabled, ..... > > Replication agreements only provide information on connections where > replication is configured, if connectivity is to be checked independent > info about all deployed serevers/replicas is needed. > > If topology should be validated, do we need params definig requirements, > eg each replica to be connected to 1,2,3,... others, type of topology > (ring, mesh, star,.) ? Ok from a topology point of view you need the same elements you need to define a graph. That is: nodes and segments. We already have the list of masters in the cn=etc tree, so all we need is to add segments (ie connection objects). As for parameters my idea is that we have a general set of parameters (eg. replicatedAttributeList, strippedAttrs) in the general topology configuration, then we might override them on a per-connection basis if needed (should be very rare). Also note we may need multiple topology sets, because we may have to distinguish between the replication topology for the main shared tree and the replication topology for other databases. However we may want to be able to mark a topology for 'multiple' sets. For example we may want to have by default the same topology both for the main database and for the CA database. > ad 2] the data required are available in the replicationAgreement (and > eventually replica) entries, but the question is if there should be a > 1:1 relationship to entries in the shared tree or a condensed > representation, if there should be a server or connection oriented view. My answer is no, we need only one object per connection, but config entries are per direction (and different ones on different servers). > In my opinion a 1:1 relation is straight forward, easy to handle and > easy to extend (not the full data of a repl agreement need to be > present, other attributes are possible). The downside may be a larger > number of entries, but this is no problem for the directory server and > replication and the utilities eg to visualize a topology will handle this. We want a more abstract and easy to handle view for the topology plugin, in general. > If the number of entries should be reduced information on multiple > replication agreements would have to be stored in one entry, and the > problem arises ho to group data belonging to one agreement. LDAP does > not provide a simple way to group attribute values in one entry, so all > the info related to one agreement (origin, target, replicated attrs and > other repl configuration info) could be stored in a single attribute, > which will make the attribute as nicely readable and managable as acis. We can easily use subtypes if really needed, this info is quite core to the IPA code and will not be generally accessed by random clients. However, as I indicated above we really need one object per graph segment which represents a two-way connection, so we shouldn't have issues (but sharing topologies between different databases may reintroduce it :) > If topology verification and connectivity check is an integral part of > the feature, I think a connection oriented view is not sufficient, it > might be incomplete, so a server view is required, the server entry > would then have the connection information as subentries or as attributes. We already have the list of servers, so we need to add only the list of connections in the topology view. We may need to amend the servers objects to add additional data in some cases. For example indicate whether it is fully installed or not (on creation the topology plugin would complain the server is disconnected until we create the first segment, but that may actually be a good thing :-) > Ad 3] The replication configuration is stored under cn=config and can be > modified either by ldap operations or by editing the dse.ldif. With the > topology plugin another source of configuration changes comes into play. > > The first question is: which information has precendence ? I think if > there is info in the shared tree it should be used, and the information > in cn=config should be updated. This also means that the topology plugin > needs to intercept all mods to the entries in cn=config and have them > ignored and handle all updates to the shared tree and trigger changes to > the cn=config entries, which then would trigger rebuilds of the in > memory replication objects. Yes, I agree. > Next question: How to handle changes directly done in the dse.ldif, if > everything should be done by the topology plugin it would have to verify > and compare the info in cn=config and in the shared tree at every > startup of the directory server, which might be complicated by the fact > that the replication plugin might already be started and repl agreemnts > are active before the topology plugin is started and could do its work. > (plugin starting order and dependencies need to be checked). Why do we care which one starts first ? We can simply change replication agreements at any time, so the fact the replication topology (and therefore agreements) can change after startup should not be an issue. > Next next question: should there be a ?bootstrapping? of the config > information in the shared tree ? > > I think yes, the topology plugin could check at startup if there is a > representation of the config info in the shared tree and if not > construct it, so after deployment and enabling of the topology plugin > the information in the shared tree would be initialized. Nope, the topology plugin should simply log a loud warning in the error log and wait quietly until the topology is provided. This is needed to allow us to handle migrations gracefully and carefully construct the topology tree at install time w/o having the topology plugin interfere. We will probably need a big 'enabled/disabled' flag on the topology tree base object so we can construct a tree w/op waking up the plugin at every change in the install phase. > I think that not every part of the feature has to be handled in the > topology plugin, we could also ask for enhancements in the 389 > replication plugin itself. There could be an extension to the replica > and replication agreement entries to reference an entry in the shared > tree. The replication plugin could check at startup if these entries > contain replication configuration attributes and if so use them, > otherwise use the values in cn=config. The presence of the reference > indicates to the topolgy plugin that initialization is done. > > In my opinion this would simplify the coordination at startup and avoid > unnecessary revaluations and other deployments could benefit from this > new feature in directory server (one could eg have one entry for > replication argreements containing the fractional replication > configuration ? and it would be identical on all servers) I really do not want to touch the replication plugin. It works just fine as it is, and handling topology has nothing to do with handling the low level details of the replication. To each its own. If other deployments want to use the topology plugin, we can later move it to the 389ds codebase and generalize it. > So my proposal would contain the following components > > 1] Store replication configuration in the shared tree in a combination > of server and connection view (think we need both) and map replication > configuration to these entries. I would prefer a direct mapping (with a > subset of the cn=config attributes and required additions) Nack, we already have the list of servers, we just need 1 object per connection (graph segment) not one per agreement. > 2] provide a topology plugin to do consistency checks and topology > verification, handle updates to trigger modification changes in > cn=config, intercept and reject direct mods to cn=config entries At > startup verify if shared tree opbjects are present, initialize them if > not, apply to cn=config if required Ack > 3] enhance replication plugin to handle config information in the shared > tree. This would allow to consistently handle config changes either > applied to the shared config, cn=config mods or des.ldif changes. This > feature might also be interesting to other DS deployments Nack, leave the replication plugin alone, the topology plugin should do all the topology work, dealing with interactions between 2 plugins would tie them together and make things a lot more complicated than necessary. It would also bind the development of the topology plugin to 2 schedules (both 389ds and FreeIPA), making also the logistics of developing the topology plugin more complicated. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Mon Jun 2 13:03:19 2014 From: sbose at redhat.com (Sumit Bose) Date: Mon, 2 Jun 2014 15:03:19 +0200 Subject: [Freeipa-devel] [RFC] Sending group-memberships to SSSD clients Message-ID: <20140602130319.GY30381@localhost.localdomain> Hi, I'm preparing a design page for https://fedorahosted.org/freeipa/ticket/4031 "[RFE] Support initgroups for unauthenticated AD users". Since we are using SSSD in ipa-server-mode in the server, the IPA server is able to resolve group memberships even if the user is not authenticated. To make the information available to the client the extdom plugin should be enhanced to send the information from the server to the clients. My question is, what would be the best type of data to send to the clients. The obvious first answer is a list if GIDs. But since we have views this would require additional processing and LDAP lookups on the server side. As an alternative we can send a list of fully qualified group names or a list of SIDs (as long as we are only looking at trust to AD). Both are independent of the view, but would require additional lookups from the client for the GID if the group with the given fully qualified name or SID is not already in the cache. But this will basically only happen if the cache is empty, which the additional processing due to user-views on the server would happen on every request if we only send the list of GIDs. So, I'm tending to the list of fully qualified names. Does anyone has concerns or other suggestions? Thank you. bye, Sumit From simo at redhat.com Mon Jun 2 13:29:49 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jun 2014 09:29:49 -0400 Subject: [Freeipa-devel] [RFC] Sending group-memberships to SSSD clients In-Reply-To: <20140602130319.GY30381@localhost.localdomain> References: <20140602130319.GY30381@localhost.localdomain> Message-ID: <1401715789.1318.0.camel@willson.usersys.redhat.com> On Mon, 2014-06-02 at 15:03 +0200, Sumit Bose wrote: > Hi, > > I'm preparing a design page for > https://fedorahosted.org/freeipa/ticket/4031 "[RFE] Support initgroups > for unauthenticated AD users". > > Since we are using SSSD in ipa-server-mode in the server, the IPA server > is able to resolve group memberships even if the user is not > authenticated. To make the information available to the client the > extdom plugin should be enhanced to send the information from the server > to the clients. > > My question is, what would be the best type of data to send to the > clients. The obvious first answer is a list if GIDs. But since we have > views this would require additional processing and LDAP lookups on the > server side. As an alternative we can send a list of fully qualified > group names or a list of SIDs (as long as we are only looking at trust > to AD). Both are independent of the view, but would require additional > lookups from the client for the GID if the group with the given fully > qualified name or SID is not already in the cache. But this will > basically only happen if the cache is empty, which the additional > processing due to user-views on the server would happen on every request > if we only send the list of GIDs. > > So, I'm tending to the list of fully qualified names. Does anyone has > concerns or other suggestions? List of qualified group names only .. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon Jun 2 13:59:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 02 Jun 2014 15:59:20 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items Message-ID: <538C8338.1040502@redhat.com> Hi List, the purpose if this mail is to start a discussion about reorganization of navigation items. Users are not fond of such change so we should come up with a solution which would last for some time. Problem: UX recommendation is that one menu level should contain maximum of 7 items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. Basically we reached max. capacity of all 1st-level items. Solution: Introduce new 1st-level items and redistribute 2nd-level items. Initial Draft: Identity (6) - Users - Groups - Hosts - Hostgroups - Netgroups - Services Policy (5) some better name? - HBAC - SUDO - Automount - Automember - SELinux User Maps Authentication (4) - Radius Server Proxy - OTP Tokens - Password Policy - Kerberos Ticket Policy Infrastructure (6) some better name? - DNS - Realm Domains - Trust - Views - ID Ranges - Certificates Permissions (3) - Role Based Access Control - Self Service Permissions - Delegation Configuration (1) - Global Notes: * draft focuses only on first two levels of navigation * 'Permission' and 'Configuration' could be merged into old 'IPA Server' * 'Views' are related to Identity and Trust, they have no meaning without some kind of trust -> are next to 'Trusts' * it's weird to have 'Policy' item and items with "policy" in name to have in 'Authentication' Comments are welcome -- Petr Vobornik From lkrispen at redhat.com Mon Jun 2 14:05:34 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 02 Jun 2014 16:05:34 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401713964.6654.29.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> Message-ID: <538C84AE.5090009@redhat.com> On 06/02/2014 02:59 PM, Simo Sorce wrote: > First of all, very good summary, thanks a lot! > Replies in line. > > On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote: >> Ticket 4302 is a request for an enhancement: Move replication topology >> to the shared tree >> >> >> There has been some discussion in comments in the ticket, but I'd like >> to open the discussion to a wider audience to get an agreement on what >> should be implemented, before writing a design spec. >> >> The implementation requires a new IPA plugin for 389 DS and eventually >> an enhancement of the 389 replication plugin (which depends on some >> decisions below). In the following I will use the terms ?topology >> plugin? for the new plugin and ?replication plugin? for the existing 389 >> multimaster replication plugin. >> >> >> Lets start with the requirements: What should be achieved by this RFE ? >> >> In my opinion there are three different levels of features to implement >> with this request >> >> - providing all replication configuration information consistent across >> all deployed servers on all servers, eg to easily visualize the >> replication topology. >> >> - Allowing to do sanity checks on replication configuration, denying >> modifications which would break replication topology or issue warnings. >> >> - Use the information in the shared tree to trigger changes to the >> replication configuration in the corresponding servers, this means to >> allow to completely control replication configuration with modifications >> of entries in the shared tree >> >> >> The main questions are >> >> 1] which information is needed in the shared tree (eg what params in the >> repl config should be modifiable) >> >> 2] how is the information organized and stored (layout of the repl >> config information shared tree) >> >> 3] how is the interaction of the info in the shared tree and >> configuration in cn=config and the interaction between the topology >> plugin and the replication plugin >> >> >> ad 1] to verify the topology, eg connectivity info about all existing >> replication agreements is needed, the replication agreements only >> contain info about the target, and the parameters for connection to the >> target, but not about the origin. If the data have to evaluated on any >> server, information about the origin has to be added, eg replicaID, >> serverID,... >> >> In addition, if agreement config has to be changed based on the shared >> tree all required parameters need to be present, eg >> replicatedAttributeList, strippedAttrs, replicationEnabled, ..... >> >> Replication agreements only provide information on connections where >> replication is configured, if connectivity is to be checked independent >> info about all deployed serevers/replicas is needed. >> >> If topology should be validated, do we need params definig requirements, >> eg each replica to be connected to 1,2,3,... others, type of topology >> (ring, mesh, star,.) ? > Ok from a topology point of view you need the same elements you need to > define a graph. That is: nodes and segments. > > We already have the list of masters in the cn=etc tree, so all we need > is to add segments (ie connection objects). ok, was not aware you want to extend existing objects, but that's fine. For the segments, my idea was to represent it by two objects (one for each direction), but just having one entry per segment is also ok for me. I was just afraid you wanted to condense the complete topology into on entry > > As for parameters my idea is that we have a general set of parameters > (eg. replicatedAttributeList, strippedAttrs) in the general topology > configuration, then we might override them on a per-connection basis if > needed (should be very rare). > > Also note we may need multiple topology sets, because we may have to > distinguish between the replication topology for the main shared tree > and the replication topology for other databases. > > However we may want to be able to mark a topology for 'multiple' sets. > For example we may want to have by default the same topology both for > the main database and for the CA database. yes, having several levels of configurations, which could then be overwritten per database or per segment sounds good > >> ad 2] the data required are available in the replicationAgreement (and >> eventually replica) entries, but the question is if there should be a >> 1:1 relationship to entries in the shared tree or a condensed >> representation, if there should be a server or connection oriented view. > My answer is no, we need only one object per connection, but config > entries are per direction (and different ones on different servers). accepted :-) > >> In my opinion a 1:1 relation is straight forward, easy to handle and >> easy to extend (not the full data of a repl agreement need to be >> present, other attributes are possible). The downside may be a larger >> number of entries, but this is no problem for the directory server and >> replication and the utilities eg to visualize a topology will handle this. > We want a more abstract and easy to handle view for the topology plugin, > in general. > >> If the number of entries should be reduced information on multiple >> replication agreements would have to be stored in one entry, and the >> problem arises ho to group data belonging to one agreement. LDAP does >> not provide a simple way to group attribute values in one entry, so all >> the info related to one agreement (origin, target, replicated attrs and >> other repl configuration info) could be stored in a single attribute, >> which will make the attribute as nicely readable and managable as acis. > We can easily use subtypes if really needed, this info is quite core to > the IPA code and will not be generally accessed by random clients. > However, as I indicated above we really need one object per graph > segment which represents a two-way connection, so we shouldn't have > issues (but sharing topologies between different databases may > reintroduce it :) It's not as bad as I thought, if we have an entry per segment then only two directions need to be defined and we could use subtypes or distinguish the attrs by tehir name, from-..., to-.... > >> If topology verification and connectivity check is an integral part of >> the feature, I think a connection oriented view is not sufficient, it >> might be incomplete, so a server view is required, the server entry >> would then have the connection information as subentries or as attributes. > We already have the list of servers, so we need to add only the list of > connections in the topology view. We may need to amend the servers > objects to add additional data in some cases. For example indicate > whether it is fully installed or not (on creation the topology plugin > would complain the server is disconnected until we create the first > segment, but that may actually be a good thing :-) ok > >> Ad 3] The replication configuration is stored under cn=config and can be >> modified either by ldap operations or by editing the dse.ldif. With the >> topology plugin another source of configuration changes comes into play. >> >> The first question is: which information has precendence ? I think if >> there is info in the shared tree it should be used, and the information >> in cn=config should be updated. This also means that the topology plugin >> needs to intercept all mods to the entries in cn=config and have them >> ignored and handle all updates to the shared tree and trigger changes to >> the cn=config entries, which then would trigger rebuilds of the in >> memory replication objects. > Yes, I agree. > >> Next question: How to handle changes directly done in the dse.ldif, if >> everything should be done by the topology plugin it would have to verify >> and compare the info in cn=config and in the shared tree at every >> startup of the directory server, which might be complicated by the fact >> that the replication plugin might already be started and repl agreemnts >> are active before the topology plugin is started and could do its work. >> (plugin starting order and dependencies need to be checked). > Why do we care which one starts first ? > We can simply change replication agreements at any time, so the fact the > replication topology (and therefore agreements) can change after startup > should not be an issue. well, if the replication plugin starts first it also starts the replication agreements, which might late be changed at the startup of teh topology plugin. If eg the list of replicated attributes differes in the dse.ldif and the shared tree the agreements start and replicate with a different configuration. If this could be avoided would be good > >> Next next question: should there be a ?bootstrapping? of the config >> information in the shared tree ? >> >> I think yes, the topology plugin could check at startup if there is a >> representation of the config info in the shared tree and if not >> construct it, so after deployment and enabling of the topology plugin >> the information in the shared tree would be initialized. > Nope, the topology plugin should simply log a loud warning in the error > log and wait quietly until the topology is provided. This is needed to > allow us to handle migrations gracefully and carefully construct the > topology tree at install time w/o having the topology plugin interfere. well I thought the topology plugin could make itself more easy to use. If you deploy a toplogy, why not let it detect its configuration and then verify and change it, it wouldn't do harm and avoid config work > We will probably need a big 'enabled/disabled' flag on the topology tree > base object so we can construct a tree w/op waking up the plugin at > every change in the install phase. > >> I think that not every part of the feature has to be handled in the >> topology plugin, we could also ask for enhancements in the 389 >> replication plugin itself. There could be an extension to the replica >> and replication agreement entries to reference an entry in the shared >> tree. The replication plugin could check at startup if these entries >> contain replication configuration attributes and if so use them, >> otherwise use the values in cn=config. The presence of the reference >> indicates to the topolgy plugin that initialization is done. >> >> In my opinion this would simplify the coordination at startup and avoid >> unnecessary revaluations and other deployments could benefit from this >> new feature in directory server (one could eg have one entry for >> replication argreements containing the fractional replication >> configuration ? and it would be identical on all servers) > I really do not want to touch the replication plugin. It works just fine > as it is, and handling topology has nothing to do with handling the low > level details of the replication. To each its own. > If other deployments want to use the topology plugin, we can later move > it to the 389ds codebase and generalize it. I'm a bit of two minds here: If you rely on the replication plugin you need to have the right versionon all servers and adapt the configuration of the toplogy plugin to male use of it, so this would be a no. But on the other hand I thought some stuff would get easier to coordinate if the replciation plugin would 'help' > >> So my proposal would contain the following components >> >> 1] Store replication configuration in the shared tree in a combination >> of server and connection view (think we need both) and map replication >> configuration to these entries. I would prefer a direct mapping (with a >> subset of the cn=config attributes and required additions) > Nack, we already have the list of servers, we just need 1 object per > connection (graph segment) not one per agreement. ok > >> 2] provide a topology plugin to do consistency checks and topology >> verification, handle updates to trigger modification changes in >> cn=config, intercept and reject direct mods to cn=config entries At >> startup verify if shared tree opbjects are present, initialize them if >> not, apply to cn=config if required > Ack > >> 3] enhance replication plugin to handle config information in the shared >> tree. This would allow to consistently handle config changes either >> applied to the shared config, cn=config mods or des.ldif changes. This >> feature might also be interesting to other DS deployments > Nack, leave the replication plugin alone, the topology plugin should do > all the topology work, dealing with interactions between 2 plugins would > tie them together and make things a lot more complicated than necessary. > It would also bind the development of the topology plugin to 2 schedules > (both 389ds and FreeIPA), making also the logistics of developing the > topology plugin more complicated. hm, yes > > Simo. > From rcritten at redhat.com Mon Jun 2 14:08:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Jun 2014 10:08:46 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401713964.6654.29.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> Message-ID: <538C856E.8040905@redhat.com> Simo Sorce wrote: > First of all, very good summary, thanks a lot! > Replies in line. > > On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote: >> Ticket 4302 is a request for an enhancement: Move replication topology >> to the shared tree >> >> >> There has been some discussion in comments in the ticket, but I'd like >> to open the discussion to a wider audience to get an agreement on what >> should be implemented, before writing a design spec. >> >> The implementation requires a new IPA plugin for 389 DS and eventually >> an enhancement of the 389 replication plugin (which depends on some >> decisions below). In the following I will use the terms ?topology >> plugin? for the new plugin and ?replication plugin? for the existing 389 >> multimaster replication plugin. >> >> >> Lets start with the requirements: What should be achieved by this RFE ? >> >> In my opinion there are three different levels of features to implement >> with this request >> >> - providing all replication configuration information consistent across >> all deployed servers on all servers, eg to easily visualize the >> replication topology. >> >> - Allowing to do sanity checks on replication configuration, denying >> modifications which would break replication topology or issue warnings. >> >> - Use the information in the shared tree to trigger changes to the >> replication configuration in the corresponding servers, this means to >> allow to completely control replication configuration with modifications >> of entries in the shared tree >> >> >> The main questions are >> >> 1] which information is needed in the shared tree (eg what params in the >> repl config should be modifiable) >> >> 2] how is the information organized and stored (layout of the repl >> config information shared tree) >> >> 3] how is the interaction of the info in the shared tree and >> configuration in cn=config and the interaction between the topology >> plugin and the replication plugin >> >> >> ad 1] to verify the topology, eg connectivity info about all existing >> replication agreements is needed, the replication agreements only >> contain info about the target, and the parameters for connection to the >> target, but not about the origin. If the data have to evaluated on any >> server, information about the origin has to be added, eg replicaID, >> serverID,... >> >> In addition, if agreement config has to be changed based on the shared >> tree all required parameters need to be present, eg >> replicatedAttributeList, strippedAttrs, replicationEnabled, ..... >> >> Replication agreements only provide information on connections where >> replication is configured, if connectivity is to be checked independent >> info about all deployed serevers/replicas is needed. >> >> If topology should be validated, do we need params definig requirements, >> eg each replica to be connected to 1,2,3,... others, type of topology >> (ring, mesh, star,.) ? > > Ok from a topology point of view you need the same elements you need to > define a graph. That is: nodes and segments. > > We already have the list of masters in the cn=etc tree, so all we need > is to add segments (ie connection objects). > > As for parameters my idea is that we have a general set of parameters > (eg. replicatedAttributeList, strippedAttrs) in the general topology > configuration, then we might override them on a per-connection basis if > needed (should be very rare). > > Also note we may need multiple topology sets, because we may have to > distinguish between the replication topology for the main shared tree > and the replication topology for other databases. > > However we may want to be able to mark a topology for 'multiple' sets. > For example we may want to have by default the same topology both for > the main database and for the CA database. I think we should store them separately and making them the "same" would be applied by a tool, but the data would just reflect the connections. I was thinking the object DN would contain the LDAP database name (or some rough equivalent), so we would store the IPA connections separate from the CA connections. >> ad 2] the data required are available in the replicationAgreement (and >> eventually replica) entries, but the question is if there should be a >> 1:1 relationship to entries in the shared tree or a condensed >> representation, if there should be a server or connection oriented view. > > My answer is no, we need only one object per connection, but config > entries are per direction (and different ones on different servers). We also need to store the type, MMR, read-only, etc, for future-proofing. One entry per connection would mirror what we have now in the mapping tree (which is generally ok). I wonder if this would be limiting with other agreement types depending on the schema we use. >> In my opinion a 1:1 relation is straight forward, easy to handle and >> easy to extend (not the full data of a repl agreement need to be >> present, other attributes are possible). The downside may be a larger >> number of entries, but this is no problem for the directory server and >> replication and the utilities eg to visualize a topology will handle this. > > We want a more abstract and easy to handle view for the topology plugin, > in general. > >> If the number of entries should be reduced information on multiple >> replication agreements would have to be stored in one entry, and the >> problem arises ho to group data belonging to one agreement. LDAP does >> not provide a simple way to group attribute values in one entry, so all >> the info related to one agreement (origin, target, replicated attrs and >> other repl configuration info) could be stored in a single attribute, >> which will make the attribute as nicely readable and managable as acis. > > We can easily use subtypes if really needed, this info is quite core to > the IPA code and will not be generally accessed by random clients. > However, as I indicated above we really need one object per graph > segment which represents a two-way connection, so we shouldn't have > issues (but sharing topologies between different databases may > reintroduce it :) > >> If topology verification and connectivity check is an integral part of >> the feature, I think a connection oriented view is not sufficient, it >> might be incomplete, so a server view is required, the server entry >> would then have the connection information as subentries or as attributes. > > We already have the list of servers, so we need to add only the list of > connections in the topology view. We may need to amend the servers > objects to add additional data in some cases. For example indicate > whether it is fully installed or not (on creation the topology plugin > would complain the server is disconnected until we create the first > segment, but that may actually be a good thing :-) Not sure I grok the fully installed part. A server isn't added as a master until it is actually installed, so a prepared master shouldn't show here. >> Ad 3] The replication configuration is stored under cn=config and can be >> modified either by ldap operations or by editing the dse.ldif. With the >> topology plugin another source of configuration changes comes into play. >> >> The first question is: which information has precendence ? I think if >> there is info in the shared tree it should be used, and the information >> in cn=config should be updated. This also means that the topology plugin >> needs to intercept all mods to the entries in cn=config and have them >> ignored and handle all updates to the shared tree and trigger changes to >> the cn=config entries, which then would trigger rebuilds of the in >> memory replication objects. > > Yes, I agree. +1 > >> Next question: How to handle changes directly done in the dse.ldif, if >> everything should be done by the topology plugin it would have to verify >> and compare the info in cn=config and in the shared tree at every >> startup of the directory server, which might be complicated by the fact >> that the replication plugin might already be started and repl agreemnts >> are active before the topology plugin is started and could do its work. >> (plugin starting order and dependencies need to be checked). > > Why do we care which one starts first ? > We can simply change replication agreements at any time, so the fact the > replication topology (and therefore agreements) can change after startup > should not be an issue. Someone could delete an agreement, or worse, add one we don't know about. Does that matter? What happens to values in the mapping tree that aren't represented in our own topology view? > >> Next next question: should there be a ?bootstrapping? of the config >> information in the shared tree ? >> >> I think yes, the topology plugin could check at startup if there is a >> representation of the config info in the shared tree and if not >> construct it, so after deployment and enabling of the topology plugin >> the information in the shared tree would be initialized. > > Nope, the topology plugin should simply log a loud warning in the error > log and wait quietly until the topology is provided. This is needed to > allow us to handle migrations gracefully and carefully construct the > topology tree at install time w/o having the topology plugin interfere. > We will probably need a big 'enabled/disabled' flag on the topology tree > base object so we can construct a tree w/op waking up the plugin at > every change in the install phase. So when we do the migration to this version some script will be needed to create the initial topology from the agreements. Could we have a race condition? >> I think that not every part of the feature has to be handled in the >> topology plugin, we could also ask for enhancements in the 389 >> replication plugin itself. There could be an extension to the replica >> and replication agreement entries to reference an entry in the shared >> tree. The replication plugin could check at startup if these entries >> contain replication configuration attributes and if so use them, >> otherwise use the values in cn=config. The presence of the reference >> indicates to the topolgy plugin that initialization is done. >> >> In my opinion this would simplify the coordination at startup and avoid >> unnecessary revaluations and other deployments could benefit from this >> new feature in directory server (one could eg have one entry for >> replication argreements containing the fractional replication >> configuration ? and it would be identical on all servers) > > I really do not want to touch the replication plugin. It works just fine > as it is, and handling topology has nothing to do with handling the low > level details of the replication. To each its own. > If other deployments want to use the topology plugin, we can later move > it to the 389ds codebase and generalize it. My memory is fuzzy but I think that restarts are required when adding/deleting agreements. Is that right? What implications would that have for this? > >> So my proposal would contain the following components >> >> 1] Store replication configuration in the shared tree in a combination >> of server and connection view (think we need both) and map replication >> configuration to these entries. I would prefer a direct mapping (with a >> subset of the cn=config attributes and required additions) > > Nack, we already have the list of servers, we just need 1 object per > connection (graph segment) not one per agreement. > >> 2] provide a topology plugin to do consistency checks and topology >> verification, handle updates to trigger modification changes in >> cn=config, intercept and reject direct mods to cn=config entries At >> startup verify if shared tree opbjects are present, initialize them if >> not, apply to cn=config if required > > Ack > >> 3] enhance replication plugin to handle config information in the shared >> tree. This would allow to consistently handle config changes either >> applied to the shared config, cn=config mods or des.ldif changes. This >> feature might also be interesting to other DS deployments > > Nack, leave the replication plugin alone, the topology plugin should do > all the topology work, dealing with interactions between 2 plugins would > tie them together and make things a lot more complicated than necessary. > It would also bind the development of the topology plugin to 2 schedules > (both 389ds and FreeIPA), making also the logistics of developing the > topology plugin more complicated. > > Simo. > From lkrispen at redhat.com Mon Jun 2 14:19:14 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 02 Jun 2014 16:19:14 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C856E.8040905@redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> Message-ID: <538C87E2.6020003@redhat.com> On 06/02/2014 04:08 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> First of all, very good summary, thanks a lot! >> Replies in line. >> >> On Mon, 2014-06-02 at 10:46 +0200, Ludwig Krispenz wrote: >>> Ticket 4302 is a request for an enhancement: Move replication topology >>> to the shared tree >>> >>> >>> There has been some discussion in comments in the ticket, but I'd like >>> to open the discussion to a wider audience to get an agreement on what >>> should be implemented, before writing a design spec. >>> >>> The implementation requires a new IPA plugin for 389 DS and eventually >>> an enhancement of the 389 replication plugin (which depends on some >>> decisions below). In the following I will use the terms ?topology >>> plugin? for the new plugin and ?replication plugin? for the existing 389 >>> multimaster replication plugin. >>> >>> >>> Lets start with the requirements: What should be achieved by this RFE ? >>> >>> In my opinion there are three different levels of features to implement >>> with this request >>> >>> - providing all replication configuration information consistent across >>> all deployed servers on all servers, eg to easily visualize the >>> replication topology. >>> >>> - Allowing to do sanity checks on replication configuration, denying >>> modifications which would break replication topology or issue warnings. >>> >>> - Use the information in the shared tree to trigger changes to the >>> replication configuration in the corresponding servers, this means to >>> allow to completely control replication configuration with modifications >>> of entries in the shared tree >>> >>> >>> The main questions are >>> >>> 1] which information is needed in the shared tree (eg what params in the >>> repl config should be modifiable) >>> >>> 2] how is the information organized and stored (layout of the repl >>> config information shared tree) >>> >>> 3] how is the interaction of the info in the shared tree and >>> configuration in cn=config and the interaction between the topology >>> plugin and the replication plugin >>> >>> >>> ad 1] to verify the topology, eg connectivity info about all existing >>> replication agreements is needed, the replication agreements only >>> contain info about the target, and the parameters for connection to the >>> target, but not about the origin. If the data have to evaluated on any >>> server, information about the origin has to be added, eg replicaID, >>> serverID,... >>> >>> In addition, if agreement config has to be changed based on the shared >>> tree all required parameters need to be present, eg >>> replicatedAttributeList, strippedAttrs, replicationEnabled, ..... >>> >>> Replication agreements only provide information on connections where >>> replication is configured, if connectivity is to be checked independent >>> info about all deployed serevers/replicas is needed. >>> >>> If topology should be validated, do we need params definig requirements, >>> eg each replica to be connected to 1,2,3,... others, type of topology >>> (ring, mesh, star,.) ? >> Ok from a topology point of view you need the same elements you need to >> define a graph. That is: nodes and segments. >> >> We already have the list of masters in the cn=etc tree, so all we need >> is to add segments (ie connection objects). >> >> As for parameters my idea is that we have a general set of parameters >> (eg. replicatedAttributeList, strippedAttrs) in the general topology >> configuration, then we might override them on a per-connection basis if >> needed (should be very rare). >> >> Also note we may need multiple topology sets, because we may have to >> distinguish between the replication topology for the main shared tree >> and the replication topology for other databases. >> >> However we may want to be able to mark a topology for 'multiple' sets. >> For example we may want to have by default the same topology both for >> the main database and for the CA database. > I think we should store them separately and making them the "same" would > be applied by a tool, but the data would just reflect the connections. > > I was thinking the object DN would contain the LDAP database name (or > some rough equivalent), so we would store the IPA connections separate > from the CA connections. > >>> ad 2] the data required are available in the replicationAgreement (and >>> eventually replica) entries, but the question is if there should be a >>> 1:1 relationship to entries in the shared tree or a condensed >>> representation, if there should be a server or connection oriented view. >> My answer is no, we need only one object per connection, but config >> entries are per direction (and different ones on different servers). > We also need to store the type, MMR, read-only, etc, for future-proofing. > > One entry per connection would mirror what we have now in the mapping > tree (which is generally ok). I wonder if this would be limiting with > other agreement types depending on the schema we use. In the mapping tree you have a connection as a replicationagreement, but if I understand Simo correctly he wants on object per segment. If two servers are connected this could be one- or bidirectional > >>> In my opinion a 1:1 relation is straight forward, easy to handle and >>> easy to extend (not the full data of a repl agreement need to be >>> present, other attributes are possible). The downside may be a larger >>> number of entries, but this is no problem for the directory server and >>> replication and the utilities eg to visualize a topology will handle this. >> We want a more abstract and easy to handle view for the topology plugin, >> in general. >> >>> If the number of entries should be reduced information on multiple >>> replication agreements would have to be stored in one entry, and the >>> problem arises ho to group data belonging to one agreement. LDAP does >>> not provide a simple way to group attribute values in one entry, so all >>> the info related to one agreement (origin, target, replicated attrs and >>> other repl configuration info) could be stored in a single attribute, >>> which will make the attribute as nicely readable and managable as acis. >> We can easily use subtypes if really needed, this info is quite core to >> the IPA code and will not be generally accessed by random clients. >> However, as I indicated above we really need one object per graph >> segment which represents a two-way connection, so we shouldn't have >> issues (but sharing topologies between different databases may >> reintroduce it :) >> >>> If topology verification and connectivity check is an integral part of >>> the feature, I think a connection oriented view is not sufficient, it >>> might be incomplete, so a server view is required, the server entry >>> would then have the connection information as subentries or as attributes. >> We already have the list of servers, so we need to add only the list of >> connections in the topology view. We may need to amend the servers >> objects to add additional data in some cases. For example indicate >> whether it is fully installed or not (on creation the topology plugin >> would complain the server is disconnected until we create the first >> segment, but that may actually be a good thing :-) > Not sure I grok the fully installed part. A server isn't added as a > master until it is actually installed, so a prepared master shouldn't > show here. > >>> Ad 3] The replication configuration is stored under cn=config and can be >>> modified either by ldap operations or by editing the dse.ldif. With the >>> topology plugin another source of configuration changes comes into play. >>> >>> The first question is: which information has precendence ? I think if >>> there is info in the shared tree it should be used, and the information >>> in cn=config should be updated. This also means that the topology plugin >>> needs to intercept all mods to the entries in cn=config and have them >>> ignored and handle all updates to the shared tree and trigger changes to >>> the cn=config entries, which then would trigger rebuilds of the in >>> memory replication objects. >> Yes, I agree. > +1 > >>> Next question: How to handle changes directly done in the dse.ldif, if >>> everything should be done by the topology plugin it would have to verify >>> and compare the info in cn=config and in the shared tree at every >>> startup of the directory server, which might be complicated by the fact >>> that the replication plugin might already be started and repl agreemnts >>> are active before the topology plugin is started and could do its work. >>> (plugin starting order and dependencies need to be checked). >> Why do we care which one starts first ? >> We can simply change replication agreements at any time, so the fact the >> replication topology (and therefore agreements) can change after startup >> should not be an issue. > Someone could delete an agreement, or worse, add one we don't know > about. Does that matter? > > What happens to values in the mapping tree that aren't represented in > our own topology view? > >>> Next next question: should there be a ?bootstrapping? of the config >>> information in the shared tree ? >>> >>> I think yes, the topology plugin could check at startup if there is a >>> representation of the config info in the shared tree and if not >>> construct it, so after deployment and enabling of the topology plugin >>> the information in the shared tree would be initialized. >> Nope, the topology plugin should simply log a loud warning in the error >> log and wait quietly until the topology is provided. This is needed to >> allow us to handle migrations gracefully and carefully construct the >> topology tree at install time w/o having the topology plugin interfere. >> We will probably need a big 'enabled/disabled' flag on the topology tree >> base object so we can construct a tree w/op waking up the plugin at >> every change in the install phase. > So when we do the migration to this version some script will be needed > to create the initial topology from the agreements. Could we have a race > condition? > >>> I think that not every part of the feature has to be handled in the >>> topology plugin, we could also ask for enhancements in the 389 >>> replication plugin itself. There could be an extension to the replica >>> and replication agreement entries to reference an entry in the shared >>> tree. The replication plugin could check at startup if these entries >>> contain replication configuration attributes and if so use them, >>> otherwise use the values in cn=config. The presence of the reference >>> indicates to the topolgy plugin that initialization is done. >>> >>> In my opinion this would simplify the coordination at startup and avoid >>> unnecessary revaluations and other deployments could benefit from this >>> new feature in directory server (one could eg have one entry for >>> replication argreements containing the fractional replication >>> configuration ? and it would be identical on all servers) >> I really do not want to touch the replication plugin. It works just fine >> as it is, and handling topology has nothing to do with handling the low >> level details of the replication. To each its own. >> If other deployments want to use the topology plugin, we can later move >> it to the 389ds codebase and generalize it. > My memory is fuzzy but I think that restarts are required when > adding/deleting agreements. Is that right? What implications would that > have for this? > >>> So my proposal would contain the following components >>> >>> 1] Store replication configuration in the shared tree in a combination >>> of server and connection view (think we need both) and map replication >>> configuration to these entries. I would prefer a direct mapping (with a >>> subset of the cn=config attributes and required additions) >> Nack, we already have the list of servers, we just need 1 object per >> connection (graph segment) not one per agreement. >> >>> 2] provide a topology plugin to do consistency checks and topology >>> verification, handle updates to trigger modification changes in >>> cn=config, intercept and reject direct mods to cn=config entries At >>> startup verify if shared tree opbjects are present, initialize them if >>> not, apply to cn=config if required >> Ack >> >>> 3] enhance replication plugin to handle config information in the shared >>> tree. This would allow to consistently handle config changes either >>> applied to the shared config, cn=config mods or des.ldif changes. This >>> feature might also be interesting to other DS deployments >> Nack, leave the replication plugin alone, the topology plugin should do >> all the topology work, dealing with interactions between 2 plugins would >> tie them together and make things a lot more complicated than necessary. >> It would also bind the development of the topology plugin to 2 schedules >> (both 389ds and FreeIPA), making also the logistics of developing the >> topology plugin more complicated. >> >> Simo. >> From jcholast at redhat.com Mon Jun 2 14:21:06 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 02 Jun 2014 16:21:06 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> Message-ID: <538C8852.60508@redhat.com> On 2.6.2014 13:50, Martin Basti wrote: > Rebased patches attached > I got this test failure: ====================================================================== ERROR: test suite for ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run self.setUp() File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in try_run return func() File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_dns_plugin.py", line 214, in setUpClass force = True, File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 876, in forward return self._call_command(command, params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 853, in _call_command return command(*params) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 993, in _call return self.__request(name, args) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 987, in __request raise error_class(message=error['message']) DNSDataMismatch: DNS check failed: Expected {_kerberos.dnszone.test. 86400 IN TXT "IDM.LAB.BOS.REDHAT.COM"} got {None} Patch 31: + #compare if IDN normalized and original domain match + #there is N:1 mapping between unicode and IDNA names + #user should use normalized names to avoid mistakes + normalized_domain_name = encodings.idna.nameprep(value) + if value != normalized_domain_name: + error = _("domain name '%(domain)s' and normalized domain name" + " '%(normalized)s' do not match. Please use only" + " normalized domains") % {'domain': value, + 'normalized': normalized_domain_name} I thought we decided to drop this check, because of IDNA 2008? Patch 38: It seems you left out the normalize_zonemgr and normalize_zone modifications I have suggested. Is there a reason for this? -- Jan Cholasta From pviktori at redhat.com Mon Jun 2 14:19:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Jun 2014 16:19:59 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538C8338.1040502@redhat.com> References: <538C8338.1040502@redhat.com> Message-ID: <538C880F.2030009@redhat.com> On 06/02/2014 03:59 PM, Petr Vobornik wrote: > Hi List, > > the purpose if this mail is to start a discussion about reorganization > of navigation items. Users are not fond of such change so we should come > up with a solution which would last for some time. > > Problem: > UX recommendation is that one menu level should contain maximum of 7 > items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. > Basically we reached max. capacity of all 1st-level items. > > Solution: > Introduce new 1st-level items and redistribute 2nd-level items. > > Initial Draft: > > Identity (6) > - Users > - Groups > - Hosts > - Hostgroups > - Netgroups > - Services > > Policy (5) some better name? > - HBAC > - SUDO > - Automount > - Automember > - SELinux User Maps > > Authentication (4) > - Radius Server Proxy > - OTP Tokens > - Password Policy > - Kerberos Ticket Policy +1 for something starting with "A" :) > Infrastructure (6) some better name? > - DNS > - Realm Domains > - Trust > - Views > - ID Ranges > - Certificates > > Permissions (3) > - Role Based Access Control > - Self Service Permissions > - Delegation "Self Service Permissions" and "Delegation" should eventually become special cases of permissions, so I'd recommend listing the RBAC components here: Role Based Access Control (5) - Permissions - Privileges - Roles - Self Service Permissions - Delegation Either on the first level, or below Policy. > > Configuration (1) > - Global > > > Notes: > * draft focuses only on first two levels of navigation > * 'Permission' and 'Configuration' could be merged into old 'IPA Server' Or merge Infrastructure and Configuration into Server? > * 'Views' are related to Identity and Trust, they have no meaning > without some kind of trust -> are next to 'Trusts' > * it's weird to have 'Policy' item and items with "policy" in name to > have in 'Authentication' > > Comments are welcome -- Petr? From simo at redhat.com Mon Jun 2 14:38:00 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jun 2014 10:38:00 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C856E.8040905@redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> Message-ID: <1401719880.1318.15.camel@willson.usersys.redhat.com> On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > However we may want to be able to mark a topology for 'multiple' sets. > > For example we may want to have by default the same topology both for > > the main database and for the CA database. > > I think we should store them separately and making them the "same" would > be applied by a tool, but the data would just reflect the connections. > > I was thinking the object DN would contain the LDAP database name (or > some rough equivalent), so we would store the IPA connections separate > from the CA connections. Ok, we can debate about this, maybe we simply have a flag in the framework that 'links' two topologies and simply replicates any change from one to the other. The only reason I had to 'mark' stuff in a single topology in order to share it is that this way any change is atomic and the 2 topologies cannot diverge, as the objects are the same, if we think the chance of divergence is low or that it is not important because the topology plugin will always prevent disconnected states anyway then we may avoid it, and let the framework try to keep topologies in sync and just loudly warn if they somehow get out of sync (which will happen briefly every time replication of the topology objects happens :). > >> ad 2] the data required are available in the replicationAgreement (and > >> eventually replica) entries, but the question is if there should be a > >> 1:1 relationship to entries in the shared tree or a condensed > >> representation, if there should be a server or connection oriented view. > > > > My answer is no, we need only one object per connection, but config > > entries are per direction (and different ones on different servers). > > We also need to store the type, MMR, read-only, etc, for future-proofing. Store where ? > One entry per connection would mirror what we have now in the mapping > tree (which is generally ok). I wonder if this would be limiting with > other agreement types depending on the schema we use. My idea is that on the connection object you have a set of attributes that tells you how replication happen. So normally you'll have: dn: uuid? objectclass: ipaReplicationTopologySegment left: master-X right: master-Y direction: both || left-right || right-left (|| none ?) If we have other special types we change direction accordingly or add another attribute. > > We already have the list of servers, so we need to add only the list of > > connections in the topology view. We may need to amend the servers > > objects to add additional data in some cases. For example indicate > > whether it is fully installed or not (on creation the topology plugin > > would complain the server is disconnected until we create the first > > segment, but that may actually be a good thing :-) > > Not sure I grok the fully installed part. A server isn't added as a > master until it is actually installed, so a prepared master shouldn't > show here. Uhmm you may be right, if we can make this a non-problem, all the better. > >> Next question: How to handle changes directly done in the dse.ldif, if > >> everything should be done by the topology plugin it would have to verify > >> and compare the info in cn=config and in the shared tree at every > >> startup of the directory server, which might be complicated by the fact > >> that the replication plugin might already be started and repl agreemnts > >> are active before the topology plugin is started and could do its work. > >> (plugin starting order and dependencies need to be checked). > > > > Why do we care which one starts first ? > > We can simply change replication agreements at any time, so the fact the > > replication topology (and therefore agreements) can change after startup > > should not be an issue. > > Someone could delete an agreement, or worse, add one we don't know > about. Does that matter? Someone can do this at any time after startup, so we already need to handle this, why should it be a problem ? However I agree we want to avoid churn, so to answer to Ludwig as well I guess we just want to make sure the topology plugin always starts before the replication plugin and amends replication agreements accordingly. > What happens to values in the mapping tree that aren't represented in > our own topology view? I think we should ignore them if they reference a machine that is not a recognized master, I guess the main issue here is a case when a master got deleted and somehow the cn=config entry was not and we end up with an orphan agreement that the topology plugin initially created but does not recognize as its own. I see 2 options here: 1) We ignore it, and let the admin deal with the issue 2) We mark agreements with a special attribute that indicates they have been generated by the topology plugin, so the plugin can delete any it does not recognize as currently valid. The only problem here is initial migration, but that is not a huge issue IMO, the topology plugin may simply recognize the two sides of an existing agreement are 2 ipa masters, and just take over those entries. [..] > So when we do the migration to this version some script will be needed > to create the initial topology from the agreements. Could we have a race > condition? If we do the takeover thing I describe above maybe not ? > > I really do not want to touch the replication plugin. It works just fine > > as it is, and handling topology has nothing to do with handling the low > > level details of the replication. To each its own. > > If other deployments want to use the topology plugin, we can later move > > it to the 389ds codebase and generalize it. > > My memory is fuzzy but I think that restarts are required when > adding/deleting agreements. Is that right? What implications would that > have for this? We create (and change) agreements on the fly w/o ever restarting the server right now, so I would say not ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Mon Jun 2 14:53:30 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 02 Jun 2014 16:53:30 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C39F6.2080006@redhat.com> References: <538C39F6.2080006@redhat.com> Message-ID: <538C8FEA.6090401@redhat.com> On 06/02/2014 10:46 AM, Ludwig Krispenz wrote: > Ticket 4302 is a request for an enhancement: Move replication topology > to the shared tree > > > There has been some discussion in comments in the ticket, but I'd like > to open the discussion to a wider audience to get an agreement on what > should be implemented, before writing a design spec. > > The implementation requires a new IPA plugin for 389 DS and eventually > an enhancement of the 389 replication plugin (which depends on some > decisions below). In the following I will use the terms ?topology > plugin? for the new plugin and ?replication plugin? for the existing > 389 multimaster replication plugin. > > > Lets start with the requirements: What should be achieved by this RFE ? > > In my opinion there are three different levels of features to > implement with this request > > - providing all replication configuration information consistent > across all deployed servers on all servers, eg to easily visualize the > replication topology. > > - Allowing to do sanity checks on replication configuration, denying > modifications which would break replication topology or issue warnings. > > - Use the information in the shared tree to trigger changes to the > replication configuration in the corresponding servers, this means to > allow to completely control replication configuration with > modifications of entries in the shared tree > > > The main questions are > > 1] which information is needed in the shared tree (eg what params in > the repl config should be modifiable) > > 2] how is the information organized and stored (layout of the repl > config information shared tree) > > 3] how is the interaction of the info in the shared tree and > configuration in cn=config and the interaction between the topology > plugin and the replication plugin > > > ad 1] to verify the topology, eg connectivity info about all existing > replication agreements is needed, the replication agreements only > contain info about the target, and the parameters for connection to > the target, but not about the origin. If the data have to evaluated on > any server, information about the origin has to be added, eg > replicaID, serverID,... > > In addition, if agreement config has to be changed based on the shared > tree all required parameters need to be present, eg > replicatedAttributeList, strippedAttrs, replicationEnabled, ..... > > Replication agreements only provide information on connections where > replication is configured, if connectivity is to be checked > independent info about all deployed serevers/replicas is needed. > > If topology should be validated, do we need params definig > requirements, eg each replica to be connected to 1,2,3,... others, > type of topology (ring, mesh, star,.) ? > > > ad 2] the data required are available in the replicationAgreement (and > eventually replica) entries, but the question is if there should be a > 1:1 relationship to entries in the shared tree or a condensed > representation, if there should be a server or connection oriented view. > > In my opinion a 1:1 relation is straight forward, easy to handle and > easy to extend (not the full data of a repl agreement need to be > present, other attributes are possible). The downside may be a larger > number of entries, but this is no problem for the directory server and > replication and the utilities eg to visualize a topology will handle > this. > > If the number of entries should be reduced information on multiple > replication agreements would have to be stored in one entry, and the > problem arises ho to group data belonging to one agreement. LDAP does > not provide a simple way to group attribute values in one entry, so > all the info related to one agreement (origin, target, replicated > attrs and other repl configuration info) could be stored in a single > attribute, which will make the attribute as nicely readable and > managable as acis. > > If topology verification and connectivity check is an integral part of > the feature, I think a connection oriented view is not sufficient, it > might be incomplete, so a server view is required, the server entry > would then have the connection information as subentries or as > attributes. > > > Ad 3] The replication configuration is stored under cn=config and can > be modified either by ldap operations or by editing the dse.ldif. With > the topology plugin another source of configuration changes comes into > play. > > The first question is: which information has precendence ? I think if > there is info in the shared tree it should be used, and the > information in cn=config should be updated. This also means that the > topology plugin needs to intercept all mods to the entries in > cn=config and have them ignored and handle all updates to the shared > tree and trigger changes to the cn=config entries, which then would > trigger rebuilds of the in memory replication objects. If server parameters are changed (port number, repl_admin or DM password) will it trigger the corresponding modification on the shared tree on the remote server ? > > Next question: How to handle changes directly done in the dse.ldif, if > everything should be done by the topology plugin it would have to > verify and compare the info in cn=config and in the shared tree at > every startup of the directory server, which might be complicated by > the fact that the replication plugin might already be started and repl > agreemnts are active before the topology plugin is started and could > do its work. (plugin starting order and dependencies need to be checked). > > Next next question: should there be a ?bootstrapping? of the config > information in the shared tree ? > > I think yes, the topology plugin could check at startup if there is a > representation of the config info in the shared tree and if not > construct it, so after deployment and enabling of the topology plugin > the information in the shared tree would be initialized. > > > I think that not every part of the feature has to be handled in the > topology plugin, we could also ask for enhancements in the 389 > replication plugin itself. There could be an extension to the replica > and replication agreement entries to reference an entry in the shared > tree. The replication plugin could check at startup if these entries > contain replication configuration attributes and if so use them, > otherwise use the values in cn=config. The presence of the reference > indicates to the topolgy plugin that initialization is done. > > In my opinion this would simplify the coordination at startup and > avoid unnecessary revaluations and other deployments could benefit > from this new feature in directory server (one could eg have one entry > for replication argreements containing the fractional replication > configuration ? and it would be identical on all servers) > > > So my proposal would contain the following components > > 1] Store replication configuration in the shared tree in a combination > of server and connection view (think we need both) and map replication > configuration to these entries. I would prefer a direct mapping (with > a subset of the cn=config attributes and required additions) > > 2] provide a topology plugin to do consistency checks and topology > verification, handle updates to trigger modification changes in > cn=config, intercept and reject direct mods to cn=config entries At > startup verify if shared tree opbjects are present, initialize them if > not, apply to cn=config if required > > 3] enhance replication plugin to handle config information in the > shared tree. This would allow to consistently handle config changes > either applied to the shared config, cn=config mods or des.ldif > changes. This feature might also be interesting to other DS deployments > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Mon Jun 2 15:06:16 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jun 2014 11:06:16 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C8FEA.6090401@redhat.com> References: <538C39F6.2080006@redhat.com> <538C8FEA.6090401@redhat.com> Message-ID: <1401721576.1318.27.camel@willson.usersys.redhat.com> On Mon, 2014-06-02 at 16:53 +0200, thierry bordaz wrote: > If server parameters are changed (port number, repl_admin or DM > password) will it trigger the corresponding modification on the > shared > tree on the remote server ? Well in the IPA case we do not have these issues as those parameters either do not change or are not used. IE, port does not change, it is always the same for all servers repl admin does not change. DM password is not used (we use GSSAPI for auth). I guess we could add optional parameters like: left-port: 12345 left-admin: cn=foo right-password: ${SHA-256}ERGSERGDFSGDSF right-auth: PLAIN or similar, but I would defer adding 'non-standard' knobs to a later version. I think v1 should focus on the minimal set of options we need to make it work well in IPA. I want us to concentrate on getting the 'topology' part right and awesome, not bog ourselves down in 'compatibility' issues to broaden the usability of it. Once we get it working great within the IPA scope then we can try to make it more generally usable adding support for corner cases and so on. Keep in mind if you have special needs you will always be able to manually add replication agreements that are not managed by the plugin. Perhaps we can even add an attribute like: topology-exception: TRUE so that the topology plugin will explicitly avoid touching it even if it normally would be matching the normal topology criteria and the topology plugin would normally try to own it. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Jun 2 15:09:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Jun 2014 17:09:07 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <538C8852.60508@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> Message-ID: <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-02 at 16:21 +0200, Jan Cholasta wrote: > On 2.6.2014 13:50, Martin Basti wrote: > > Rebased patches attached > > > > I got this test failure: > > ====================================================================== > ERROR: test suite for 'ipatests.test_xmlrpc.test_dns_plugin.test_dns'> > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run > self.setUp() > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp > self.setupContext(ancestor) > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_dns_plugin.py", > line 214, in setUpClass > force = True, > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, > in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, > in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 876, in > forward > return self._call_command(command, params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 853, in > _call_command > return command(*params) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 993, in _call > return self.__request(name, args) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 987, in > __request > raise error_class(message=error['message']) > DNSDataMismatch: DNS check failed: Expected {_kerberos.dnszone.test. > 86400 IN TXT "IDM.LAB.BOS.REDHAT.COM"} got {None} This is caused by wait_for_dns option. Try to set larger time limit, at least 10sec. > > Patch 31: > > + #compare if IDN normalized and original domain match > + #there is N:1 mapping between unicode and IDNA names > + #user should use normalized names to avoid mistakes > + normalized_domain_name = encodings.idna.nameprep(value) > + if value != normalized_domain_name: > + error = _("domain name '%(domain)s' and normalized > domain name" > + " '%(normalized)s' do not match. Please use only" > + " normalized domains") % {'domain': value, > + 'normalized': normalized_domain_name} > > I thought we decided to drop this check, because of IDNA 2008? We decided not to change IDNA2003 to 2008, because registrators are more strictly than both of the RFC standards, and this is part of 2003 which makes it safer, and in some way more compatible with 2008 (like only small caps, etc) But German registrator allows only IDNA2008, Switzerland allows only IDNA2003, so we have problem with '?' character, because it is encoded differently. For the IDNA2008, we need extra library out of standard python libs. So we should support both, or use pure punycode algorithm to encode/decode, because it has no limitation instead of IDNA standard. I propose to file a new ticket. > > Patch 38: > > It seems you left out the normalize_zonemgr and normalize_zone > modifications I have suggested. Is there a reason for this? > I left there original code, which works with strings. I dont use normalize_zone in DNS plugin anymore. So it would be better to work only with string, no conversion string to object and back to string. Should I modify normalize_zonemgr then? Old version works good, and code will be little longer than your example. -- Martin^2 Basti From mbasti at redhat.com Mon Jun 2 15:29:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 02 Jun 2014 17:29:22 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> Message-ID: <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-02 at 17:09 +0200, Martin Basti wrote: > On Mon, 2014-06-02 at 16:21 +0200, Jan Cholasta wrote: > > On 2.6.2014 13:50, Martin Basti wrote: > > > Rebased patches attached > > > > > > > I got this test failure: > > > > ====================================================================== > > ERROR: test suite for > 'ipatests.test_xmlrpc.test_dns_plugin.test_dns'> > > ---------------------------------------------------------------------- > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run > > self.setUp() > > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp > > self.setupContext(ancestor) > > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in > > setupContext > > try_run(context, names) > > File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in > > try_run > > return func() > > File > > "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_dns_plugin.py", > > line 214, in setUpClass > > force = True, > > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, > > in __call__ > > ret = self.run(*args, **options) > > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, > > in run > > return self.forward(*args, **options) > > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, > > in forward > > return self.Backend.rpcclient.forward(self.name, *args, **kw) > > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 876, in > > forward > > return self._call_command(command, params) > > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 853, in > > _call_command > > return command(*params) > > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 993, in _call > > return self.__request(name, args) > > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 987, in > > __request > > raise error_class(message=error['message']) > > DNSDataMismatch: DNS check failed: Expected {_kerberos.dnszone.test. > > 86400 IN TXT "IDM.LAB.BOS.REDHAT.COM"} got {None} > This is caused by wait_for_dns option. Try to set larger time limit, at > least 10sec. > > > > > Patch 31: > > > > + #compare if IDN normalized and original domain match > > + #there is N:1 mapping between unicode and IDNA names > > + #user should use normalized names to avoid mistakes > > + normalized_domain_name = encodings.idna.nameprep(value) > > + if value != normalized_domain_name: > > + error = _("domain name '%(domain)s' and normalized > > domain name" > > + " '%(normalized)s' do not match. Please use only" > > + " normalized domains") % {'domain': value, > > + 'normalized': normalized_domain_name} > > > > I thought we decided to drop this check, because of IDNA 2008? > We decided not to change IDNA2003 to 2008, because registrators are more > strictly than both of the RFC standards, and this is part of 2003 which > makes it safer, and in some way more compatible with 2008 (like only > small caps, etc) > > But German registrator allows only IDNA2008, Switzerland allows only > IDNA2003, so we have problem with '?' character, because it is encoded > differently. > > For the IDNA2008, we need extra library out of standard python libs. > > So we should support both, or use pure punycode algorithm to > encode/decode, because it has no limitation instead of IDNA standard. > I propose to file a new ticket. > And also AD support IDNA2003. So we are compatible. > > > > Patch 38: > > > > It seems you left out the normalize_zonemgr and normalize_zone > > modifications I have suggested. Is there a reason for this? > > > I left there original code, which works with strings. > > I dont use normalize_zone in DNS plugin anymore. So it would be better > to work only with string, no conversion string to object and back to > string. > > Should I modify normalize_zonemgr then? Old version works good, and code > will be little longer than your example. > -- Martin^2 Basti From pvoborni at redhat.com Mon Jun 2 16:35:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 02 Jun 2014 18:35:04 +0200 Subject: [Freeipa-devel] [PATCH 0140] [PATCH 140/140] ipalib: Use DateTime parameter class for OTP token In-Reply-To: <52D547C3.4060309@redhat.com> References: <52CEC112.9010802@redhat.com> <52D4F674.5080302@redhat.com> <52D547C3.4060309@redhat.com> Message-ID: <538CA7B8.4050503@redhat.com> On 14.1.2014 15:20, Petr Viktorin wrote: > On 01/14/2014 09:33 AM, Jan Cholasta wrote: >> On 9.1.2014 16:32, Tomas Babej wrote: >>> Hi, >>> >>> For ipatokennotbefore and ipatokennotafter attributes use DateTime >>> parameter class instead of Str, since these are represented as >>> LDAP Generalized Time in LDAP. >>> >>> Tomas >>> >> >> ACK. > > This apparently depends on tbabej-0137, so let's not push it yet. > I've rebased the patch and wanted to push it but I found out, that in patch 138 - expose krbPrincipalExpiration we removed the "(UTC)" from labels [1]. We should do the same here. [1] http://www.redhat.com/archives/freeipa-devel/2014-April/msg00442.html -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0140-2-ipalib-Use-DateTime-parameter-class-for-OTP-token-ti.patch Type: text/x-patch Size: 6850 bytes Desc: not available URL: From rmeggins at redhat.com Mon Jun 2 18:02:48 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 02 Jun 2014 12:02:48 -0600 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C39F6.2080006@redhat.com> References: <538C39F6.2080006@redhat.com> Message-ID: <538CBC48.8060801@redhat.com> On 06/02/2014 02:46 AM, Ludwig Krispenz wrote: > Ticket 4302 is a request for an enhancement: Move replication topology > to the shared tree > > > There has been some discussion in comments in the ticket, but I'd like > to open the discussion to a wider audience to get an agreement on what > should be implemented, before writing a design spec. > > The implementation requires a new IPA plugin for 389 DS and eventually > an enhancement of the 389 replication plugin (which depends on some > decisions below). In the following I will use the terms ?topology > plugin? for the new plugin and ?replication plugin? for the existing > 389 multimaster replication plugin. > > > Lets start with the requirements: What should be achieved by this RFE ? > > In my opinion there are three different levels of features to > implement with this request > > - providing all replication configuration information consistent > across all deployed servers on all servers, eg to easily visualize the > replication topology. > > - Allowing to do sanity checks on replication configuration, denying > modifications which would break replication topology or issue warnings. > > - Use the information in the shared tree to trigger changes to the > replication configuration in the corresponding servers, this means to > allow to completely control replication configuration with > modifications of entries in the shared tree > > > The main questions are > > 1] which information is needed in the shared tree (eg what params in > the repl config should be modifiable) > > 2] how is the information organized and stored (layout of the repl > config information shared tree) > > 3] how is the interaction of the info in the shared tree and > configuration in cn=config and the interaction between the topology > plugin and the replication plugin I apologize that I have not yet finished reading through all of this thread and the comments/replies, so perhaps my following comment is out of line: Why not (selectively) replicate cn=config? We keep moving more and more stuff out of cn=config and into the main tree (dna, automember, etc.), to work around the problem that data underneath cn=config is not replicated. We already have customers who have asked for things like database configuration, index configuration, suffix configuration, and many other configurations, to be replicated. And, for a bonus, if we do this right, we might be able to leverage this work to do "real" schema replication. I will note that openldap syncrepl does allow cn=config to be replicated. > > > ad 1] to verify the topology, eg connectivity info about all existing > replication agreements is needed, the replication agreements only > contain info about the target, and the parameters for connection to > the target, but not about the origin. If the data have to evaluated on > any server, information about the origin has to be added, eg > replicaID, serverID,... > > In addition, if agreement config has to be changed based on the shared > tree all required parameters need to be present, eg > replicatedAttributeList, strippedAttrs, replicationEnabled, ..... > > Replication agreements only provide information on connections where > replication is configured, if connectivity is to be checked > independent info about all deployed serevers/replicas is needed. > > If topology should be validated, do we need params definig > requirements, eg each replica to be connected to 1,2,3,... others, > type of topology (ring, mesh, star,.) ? > > > ad 2] the data required are available in the replicationAgreement (and > eventually replica) entries, but the question is if there should be a > 1:1 relationship to entries in the shared tree or a condensed > representation, if there should be a server or connection oriented view. > > In my opinion a 1:1 relation is straight forward, easy to handle and > easy to extend (not the full data of a repl agreement need to be > present, other attributes are possible). The downside may be a larger > number of entries, but this is no problem for the directory server and > replication and the utilities eg to visualize a topology will handle > this. > > If the number of entries should be reduced information on multiple > replication agreements would have to be stored in one entry, and the > problem arises ho to group data belonging to one agreement. LDAP does > not provide a simple way to group attribute values in one entry, so > all the info related to one agreement (origin, target, replicated > attrs and other repl configuration info) could be stored in a single > attribute, which will make the attribute as nicely readable and > managable as acis. > > If topology verification and connectivity check is an integral part of > the feature, I think a connection oriented view is not sufficient, it > might be incomplete, so a server view is required, the server entry > would then have the connection information as subentries or as > attributes. > > > Ad 3] The replication configuration is stored under cn=config and can > be modified either by ldap operations or by editing the dse.ldif. With > the topology plugin another source of configuration changes comes into > play. > > The first question is: which information has precendence ? I think if > there is info in the shared tree it should be used, and the > information in cn=config should be updated. This also means that the > topology plugin needs to intercept all mods to the entries in > cn=config and have them ignored and handle all updates to the shared > tree and trigger changes to the cn=config entries, which then would > trigger rebuilds of the in memory replication objects. > > Next question: How to handle changes directly done in the dse.ldif, if > everything should be done by the topology plugin it would have to > verify and compare the info in cn=config and in the shared tree at > every startup of the directory server, which might be complicated by > the fact that the replication plugin might already be started and repl > agreemnts are active before the topology plugin is started and could > do its work. (plugin starting order and dependencies need to be checked). > > Next next question: should there be a ?bootstrapping? of the config > information in the shared tree ? > > I think yes, the topology plugin could check at startup if there is a > representation of the config info in the shared tree and if not > construct it, so after deployment and enabling of the topology plugin > the information in the shared tree would be initialized. > > > I think that not every part of the feature has to be handled in the > topology plugin, we could also ask for enhancements in the 389 > replication plugin itself. There could be an extension to the replica > and replication agreement entries to reference an entry in the shared > tree. The replication plugin could check at startup if these entries > contain replication configuration attributes and if so use them, > otherwise use the values in cn=config. The presence of the reference > indicates to the topolgy plugin that initialization is done. > > In my opinion this would simplify the coordination at startup and > avoid unnecessary revaluations and other deployments could benefit > from this new feature in directory server (one could eg have one entry > for replication argreements containing the fractional replication > configuration ? and it would be identical on all servers) > > > So my proposal would contain the following components > > 1] Store replication configuration in the shared tree in a combination > of server and connection view (think we need both) and map replication > configuration to these entries. I would prefer a direct mapping (with > a subset of the cn=config attributes and required additions) > > 2] provide a topology plugin to do consistency checks and topology > verification, handle updates to trigger modification changes in > cn=config, intercept and reject direct mods to cn=config entries At > startup verify if shared tree opbjects are present, initialize them if > not, apply to cn=config if required > > 3] enhance replication plugin to handle config information in the > shared tree. This would allow to consistently handle config changes > either applied to the shared config, cn=config mods or des.ldif > changes. This feature might also be interesting to other DS deployments > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Mon Jun 2 18:37:10 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Jun 2014 14:37:10 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538CBC48.8060801@redhat.com> References: <538C39F6.2080006@redhat.com> <538CBC48.8060801@redhat.com> Message-ID: <1401734230.6551.4.camel@willson.usersys.redhat.com> On Mon, 2014-06-02 at 12:02 -0600, Rich Megginson wrote: > Why not (selectively) replicate cn=config? Because we do not want to just replicate cn=config (which would be pointless anyway given each server has a completely different set of replication agreements). We want a much more abstract view that the topology plugin can then translate in replication agreements. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Jun 2 23:49:13 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 02 Jun 2014 17:49:13 -0600 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401719880.1318.15.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> Message-ID: <538D0D79.9080304@redhat.com> On 06/02/2014 08:38 AM, Simo Sorce wrote: > On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> However we may want to be able to mark a topology for 'multiple' sets. >>> For example we may want to have by default the same topology both for >>> the main database and for the CA database. >> I think we should store them separately and making them the "same" would >> be applied by a tool, but the data would just reflect the connections. >> >> I was thinking the object DN would contain the LDAP database name (or >> some rough equivalent), so we would store the IPA connections separate >> from the CA connections. > Ok, we can debate about this, maybe we simply have a flag in the > framework that 'links' two topologies and simply replicates any change > from one to the other. > > The only reason I had to 'mark' stuff in a single topology in order to > share it is that this way any change is atomic and the 2 topologies > cannot diverge, as the objects are the same, if we think the chance of > divergence is low or that it is not important because the topology > plugin will always prevent disconnected states anyway then we may avoid > it, and let the framework try to keep topologies in sync and just loudly > warn if they somehow get out of sync (which will happen briefly every > time replication of the topology objects happens :). > >>>> ad 2] the data required are available in the replicationAgreement (and >>>> eventually replica) entries, but the question is if there should be a >>>> 1:1 relationship to entries in the shared tree or a condensed >>>> representation, if there should be a server or connection oriented view. >>> My answer is no, we need only one object per connection, but config >>> entries are per direction (and different ones on different servers). >> We also need to store the type, MMR, read-only, etc, for future-proofing. > Store where ? > >> One entry per connection would mirror what we have now in the mapping >> tree (which is generally ok). I wonder if this would be limiting with >> other agreement types depending on the schema we use. > My idea is that on the connection object you have a set of attributes > that tells you how replication happen. > > So normally you'll have: > dn: uuid? > objectclass: ipaReplicationTopologySegment > left: master-X > right: master-Y > direction: both || left-right || right-left (|| none ?) > > If we have other special types we change direction accordingly or add > another attribute. > >>> We already have the list of servers, so we need to add only the list of >>> connections in the topology view. We may need to amend the servers >>> objects to add additional data in some cases. For example indicate >>> whether it is fully installed or not (on creation the topology plugin >>> would complain the server is disconnected until we create the first >>> segment, but that may actually be a good thing :-) >> Not sure I grok the fully installed part. A server isn't added as a >> master until it is actually installed, so a prepared master shouldn't >> show here. > Uhmm you may be right, if we can make this a non-problem, all the > better. > >>>> Next question: How to handle changes directly done in the dse.ldif, if >>>> everything should be done by the topology plugin it would have to verify >>>> and compare the info in cn=config and in the shared tree at every >>>> startup of the directory server, which might be complicated by the fact >>>> that the replication plugin might already be started and repl agreemnts >>>> are active before the topology plugin is started and could do its work. >>>> (plugin starting order and dependencies need to be checked). >>> Why do we care which one starts first ? >>> We can simply change replication agreements at any time, so the fact the >>> replication topology (and therefore agreements) can change after startup >>> should not be an issue. >> Someone could delete an agreement, or worse, add one we don't know >> about. Does that matter? > Someone can do this at any time after startup, so we already need to > handle this, why should it be a problem ? It shouldn't be a problem for replication, since everything is dynamic. > > However I agree we want to avoid churn, so to answer to Ludwig as well I > guess we just want to make sure the topology plugin always starts before > the replication plugin and amends replication agreements accordingly. +1 - I think this will avoid some problems. > >> What happens to values in the mapping tree that aren't represented in >> our own topology view? > I think we should ignore them if they reference a machine that is not a > recognized master, I guess the main issue here is a case when a master > got deleted and somehow the cn=config entry was not and we end up with > an orphan agreement that the topology plugin initially created but does > not recognize as its own. > I see 2 options here: > 1) We ignore it, and let the admin deal with the issue > 2) We mark agreements with a special attribute that indicates they have > been generated by the topology plugin, so the plugin can delete any it > does not recognize as currently valid. The only problem here is initial > migration, but that is not a huge issue IMO, the topology plugin may > simply recognize the two sides of an existing agreement are 2 ipa > masters, and just take over those entries. > > [..] > >> So when we do the migration to this version some script will be needed >> to create the initial topology from the agreements. Could we have a race >> condition? > If we do the takeover thing I describe above maybe not ? > >>> I really do not want to touch the replication plugin. It works just fine >>> as it is, and handling topology has nothing to do with handling the low >>> level details of the replication. To each its own. >>> If other deployments want to use the topology plugin, we can later move >>> it to the 389ds codebase and generalize it. >> My memory is fuzzy but I think that restarts are required when >> adding/deleting agreements. Is that right? What implications would that >> have for this? > We create (and change) agreements on the fly w/o ever restarting the > server right now, so I would say not ? Correct. Replication configuration is dynamic. > > Simo. > From npmccallum at redhat.com Tue Jun 3 03:07:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 02 Jun 2014 23:07:03 -0400 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support Message-ID: <1401764823.4161.4.camel@ipa.example.com> This HTTP call takes the following parameters: * user * password * first_code * second_code * token (optional) Using this information, the server will perform token synchronization. If the token is not specified, all tokens will be searched for synchronization. Otherwise, only the token specified will be searched. This patch depends on my patch #0054. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0055-Add-session-token_sync-POST-support.patch Type: text/x-patch Size: 9848 bytes Desc: not available URL: From npmccallum at redhat.com Tue Jun 3 03:08:17 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 02 Jun 2014 23:08:17 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command Message-ID: <1401764897.4161.6.camel@ipa.example.com> This command calls the token sync HTTP POST call in the server providing the CLI interface to synchronization. https://fedorahosted.org/freeipa/ticket/4260 This patch depends on my patch #0055. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0056-Add-otptoken-sync-command.patch Type: text/x-patch Size: 3568 bytes Desc: not available URL: From jcholast at redhat.com Tue Jun 3 06:24:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 03 Jun 2014 08:24:30 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> Message-ID: <538D6A1E.9010201@redhat.com> On 2.6.2014 17:29, Martin Basti wrote: > On Mon, 2014-06-02 at 17:09 +0200, Martin Basti wrote: >> On Mon, 2014-06-02 at 16:21 +0200, Jan Cholasta wrote: >>> On 2.6.2014 13:50, Martin Basti wrote: >>>> Rebased patches attached >>>> >>> >>> I got this test failure: >>> >>> ====================================================================== >>> ERROR: test suite for >> 'ipatests.test_xmlrpc.test_dns_plugin.test_dns'> >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run >>> self.setUp() >>> File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp >>> self.setupContext(ancestor) >>> File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in >>> setupContext >>> try_run(context, names) >>> File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in >>> try_run >>> return func() >>> File >>> "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/test_dns_plugin.py", >>> line 214, in setUpClass >>> force = True, >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, >>> in __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 758, >>> in run >>> return self.forward(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 779, >>> in forward >>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 876, in >>> forward >>> return self._call_command(command, params) >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 853, in >>> _call_command >>> return command(*params) >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 993, in _call >>> return self.__request(name, args) >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 987, in >>> __request >>> raise error_class(message=error['message']) >>> DNSDataMismatch: DNS check failed: Expected {_kerberos.dnszone.test. >>> 86400 IN TXT "IDM.LAB.BOS.REDHAT.COM"} got {None} >> This is caused by wait_for_dns option. Try to set larger time limit, at >> least 10sec. Oh, OK, thanks. >> >>> >>> Patch 31: >>> >>> + #compare if IDN normalized and original domain match >>> + #there is N:1 mapping between unicode and IDNA names >>> + #user should use normalized names to avoid mistakes >>> + normalized_domain_name = encodings.idna.nameprep(value) >>> + if value != normalized_domain_name: >>> + error = _("domain name '%(domain)s' and normalized >>> domain name" >>> + " '%(normalized)s' do not match. Please use only" >>> + " normalized domains") % {'domain': value, >>> + 'normalized': normalized_domain_name} >>> >>> I thought we decided to drop this check, because of IDNA 2008? >> We decided not to change IDNA2003 to 2008, because registrators are more >> strictly than both of the RFC standards, and this is part of 2003 which >> makes it safer, and in some way more compatible with 2008 (like only >> small caps, etc) >> >> But German registrator allows only IDNA2008, Switzerland allows only >> IDNA2003, so we have problem with '?' character, because it is encoded >> differently. >> >> For the IDNA2008, we need extra library out of standard python libs. >> >> So we should support both, or use pure punycode algorithm to >> encode/decode, because it has no limitation instead of IDNA standard. >> I propose to file a new ticket. >> > And also AD support IDNA2003. So we are compatible. What I mean is that with the check, we support only IDNA2003 and without it, we support both IDNA2003 and IDNA2008, so it might be better just to remove it. Yes, users can enter invalid names without the check, but there is only so much babysitting we should do. Maybe we can do a compromise and make it a warning instead? > > >>> >>> Patch 38: >>> >>> It seems you left out the normalize_zonemgr and normalize_zone >>> modifications I have suggested. Is there a reason for this? >>> >> I left there original code, which works with strings. >> >> I dont use normalize_zone in DNS plugin anymore. So it would be better >> to work only with string, no conversion string to object and back to >> string. >> >> Should I modify normalize_zonemgr then? Old version works good, and code >> will be little longer than your example. Yes please, just to be safe ;-) -- Jan Cholasta From mkosek at redhat.com Tue Jun 3 07:54:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jun 2014 09:54:06 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538C8338.1040502@redhat.com> References: <538C8338.1040502@redhat.com> Message-ID: <538D7F1E.2010802@redhat.com> On 06/02/2014 03:59 PM, Petr Vobornik wrote: > Hi List, > > the purpose if this mail is to start a discussion about reorganization of > navigation items. Users are not fond of such change so we should come up with a > solution which would last for some time. > > Problem: > UX recommendation is that one menu level should contain maximum of 7 items. We > have 10 items in Identity, 7 in Policy and 7 in IPA Server. Basically we > reached max. capacity of all 1st-level items. > > Solution: > Introduce new 1st-level items and redistribute 2nd-level items. > > Initial Draft: > > Identity (6) > - Users > - Groups > - Hosts > - Hostgroups > - Netgroups > - Services ok, though I have different division in mind. > Policy (5) some better name? > - HBAC > - SUDO > - Automount > - Automember > - SELinux User Maps I am not sure about Automount, SUDO and Automember as they are not so about policy related to users but rather about central storage for native Linux services - similarly to DNS. > Authentication (4) > - Radius Server Proxy > - OTP Tokens > - Password Policy > - Kerberos Ticket Policy Hm, "Policy" is indeed strange. > Infrastructure (6) some better name? > - DNS > - Realm Domains > - Trust > - Views > - ID Ranges > - Certificates > > Permissions (3) > - Role Based Access Control > - Self Service Permissions > - Delegation > > Configuration (1) > - Global Let me twist your proposal a bit and come to it from different way, i.e. thinking about what admin wants to do. If he wants to set up a user, he should not need to go to 2 different top level items. Users - Users - Groups - OTP Tokens - Password Policy - Automember Hosts - Hosts - Host groups - Netgroups - HBAC - SELinux User Maps Services - Services - SUDO - Automount Trusts - (future) Views - Trust configuration - Trusts Infrastructure - Certificates - DNS - Realm Domains - Kerberos Ticket Policy - (future) Replication topology Configuration - Global - RBAC - ID Ranges Does that make sense? Martin From pvoborni at redhat.com Tue Jun 3 08:27:16 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Jun 2014 10:27:16 +0200 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1401764897.4161.6.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> Message-ID: <538D86E4.5050605@redhat.com> On 3.6.2014 05:08, Nathaniel McCallum wrote: > This command calls the token sync HTTP POST call in the server providing > the CLI interface to synchronization. > > https://fedorahosted.org/freeipa/ticket/4260 > > This patch depends on my patch #0055. > Build fails on validation. You forgot to update API.txt and also the command misses __doc__. (not a proper review) -- Petr Vobornik From pspacek at redhat.com Tue Jun 3 08:29:05 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 03 Jun 2014 10:29:05 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538D7F1E.2010802@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> Message-ID: <538D8751.9030302@redhat.com> On 3.6.2014 09:54, Martin Kosek wrote: > On 06/02/2014 03:59 PM, Petr Vobornik wrote: >> Hi List, >> >> the purpose if this mail is to start a discussion about reorganization of >> navigation items. Users are not fond of such change so we should come up with a >> solution which would last for some time. >> >> Problem: >> UX recommendation is that one menu level should contain maximum of 7 items. We >> have 10 items in Identity, 7 in Policy and 7 in IPA Server. Basically we >> reached max. capacity of all 1st-level items. >> >> Solution: >> Introduce new 1st-level items and redistribute 2nd-level items. >> >> Initial Draft: >> >> Identity (6) >> - Users >> - Groups >> - Hosts >> - Hostgroups >> - Netgroups >> - Services > > ok, though I have different division in mind. > >> Policy (5) some better name? >> - HBAC >> - SUDO >> - Automount >> - Automember >> - SELinux User Maps > > I am not sure about Automount, SUDO and Automember as they are not so about > policy related to users but rather about central storage for native Linux > services - similarly to DNS. > >> Authentication (4) >> - Radius Server Proxy >> - OTP Tokens >> - Password Policy >> - Kerberos Ticket Policy > > Hm, "Policy" is indeed strange. > >> Infrastructure (6) some better name? >> - DNS >> - Realm Domains >> - Trust >> - Views >> - ID Ranges >> - Certificates >> >> Permissions (3) >> - Role Based Access Control >> - Self Service Permissions >> - Delegation >> >> Configuration (1) >> - Global > > Let me twist your proposal a bit and come to it from different way, i.e. > thinking about what admin wants to do. If he wants to set up a user, he should > not need to go to 2 different top level items. > > Users > - Users > - Groups > - OTP Tokens > - Password Policy > - Automember > > Hosts > - Hosts > - Host groups > - Netgroups > - HBAC > - SELinux User Maps > > Services > - Services > - SUDO > - Automount > > Trusts > - (future) Views > - Trust configuration > - Trusts > > Infrastructure > - Certificates > - DNS > - Realm Domains > - Kerberos Ticket Policy > - (future) Replication topology > > Configuration > - Global > - RBAC > - ID Ranges > > Does that make sense? This seems reasolable. Couple nitpicks: 1) "Certificates" under "Infrastructure": Now we don't support them for users, but this will change in (distant?) future. Also, hosts have own certificates. Services can have own certificates etc. Can we have e.g. "Certificates" button at two different places? (But still opening the same dialog.) 2) "Kerberos Ticket Policy" is also related to users ... 3) "Configuration" and "Infrastructure" seems so related to me that I would personally merge them. Anyway, this seems like a step in the right direction! -- Petr^2 Spacek From pspacek at redhat.com Tue Jun 3 08:41:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 03 Jun 2014 10:41:11 +0200 Subject: [Freeipa-devel] [PATCH 0239-0243] Refactor ldap_parse_master_zoneentry() In-Reply-To: <20140506201137.GA1129@mail.corp.redhat.com> References: <535016B2.2010809@redhat.com> <685055735.646933.1399380070775.JavaMail.zimbra@redhat.com> <5368FC93.2090703@redhat.com> <20140506201137.GA1129@mail.corp.redhat.com> Message-ID: <538D8A27.2020100@redhat.com> On 6.5.2014 22:11, Lukas Slebodnik wrote: > On (06/05/14 17:15), Petr Spacek wrote: >> On 6.5.2014 14:41, Tomas Hozza wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> This patch set attempts to move ldap_parse_master_zoneentry() a little bit >>>> closer to sane code. >>>> >>>> It is preparation for >>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 >>>> >>>> -- >>>> Petr^2 Spacek >>>> >>> >>> Patches look good. >>> >>> ACK. >>> >>> ACKing of version 2 of the patch 242 will follow. The patch 243 introduced new compilation >>> warning that Peter is aware of. Unfortunately we are unable to find the root cause of it, >>> so leaving it as is for now... >> >> I managed to find & fix one problem (see new version of the patch >> 243) but GCC still complains. >> >> ../../src/ldap_helper.c: In function 'update_zone': >> ../../src/ldap_helper.c:2334:34: error: 'data_changed' may be used >> uninitialized in this function [-Werror=maybe-uninitialized] >> if (sync_state == sync_finished && data_changed == ISC_TRUE) >> ^ >> ../../src/ldap_helper.c:2218:16: note: 'data_changed' was declared here >> isc_boolean_t data_changed; >> >> On my machine with gcc-4.8.2-7.fc20.x86_64 this happens only with -O2. >> > The same problem with -01,-Os,-O2 or -O3 > > I doubt it is false possibive, because I could reproduce it even with > gcc-4.9.0-1.fc21.x86_64 > >> I'm not able to reproduce this with clang-3.4-6.fc20.x86_64 but it is >> no so surprising - Clang didn't catch even the first case (fixed by >> patch version 2). >> >> Any hint what is wrong or how to refactor code will be appreciated! ;-) >> > I think it can be some kind of optimization in function zone_sync_apex. > You can try to debug this function with plugin "-O2"-build :-) > > The warning can be suppresed with initialising variable before the 1st CHECK. > It will not work if you try to initialize later. Yesterday I have discussed this with jkratoch. We weren't able to find out case where would initialization in ldap_parse_master_zoneentry() cause any problem so I have added initialization there. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0243-3-Refactor-zone-apex-synchronization-and-serial-mainte.patch Type: text/x-patch Size: 12021 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 3 08:53:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 03 Jun 2014 10:53:12 +0200 Subject: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for secure zones Message-ID: <538D8CF8.6040008@redhat.com> Hello, Fix run-time zone addition for secure zones. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0258-Fix-run-time-zone-addition-for-secure-zones.patch Type: text/x-patch Size: 2136 bytes Desc: not available URL: From mbasti at redhat.com Tue Jun 3 09:45:58 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 03 Jun 2014 11:45:58 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <538D6A1E.9010201@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> <538D6A1E.9010201@redhat.com> Message-ID: <1401788758.9684.3.camel@unused-4-145.brq.redhat.com> > > > > > >>> > >>> Patch 38: > >>> > >>> It seems you left out the normalize_zonemgr and normalize_zone > >>> modifications I have suggested. Is there a reason for this? > >>> > >> I left there original code, which works with strings. > >> > >> I dont use normalize_zone in DNS plugin anymore. So it would be better > >> to work only with string, no conversion string to object and back to > >> string. > >> > >> Should I modify normalize_zonemgr then? Old version works good, and code > >> will be little longer than your example. > > Yes please, just to be safe ;-) > Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0038-6-Modified-dns-related-global-functions.patch Type: text/x-patch Size: 15725 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 3 11:11:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 03 Jun 2014 13:11:23 +0200 Subject: [Freeipa-devel] [PATCH 0259] Fix run-time zone addition for invalid secure zones Message-ID: <538DAD5B.7090907@redhat.com> Hello, Fix run-time zone addition for invalid secure zones. It is important *not* to delete invalid zones to prevent ldap_parse_master_zoneentry() from entering infinite cycle. Zone addition in ldap_parse_master_zoneentry() enforces serial write-back to LDAP. This write generates LDAP modify event which again triggers ldap_parse_master_zoneentry() and so on. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0259-Fix-run-time-zone-addition-for-invalid-secure-zones.patch Type: text/x-patch Size: 1929 bytes Desc: not available URL: From pviktori at redhat.com Tue Jun 3 11:44:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Jun 2014 13:44:55 +0200 Subject: [Freeipa-devel] [PATCH] 0565 ipalib.aci: Fix bugs in comparison Message-ID: <538DB537.2000803@redhat.com> I found two bugs in the ACI comparison code, one new and one old. This fixes them and adds some more tests. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0566-ipalib.aci-Fix-bugs-in-comparison.patch Type: text/x-patch Size: 4666 bytes Desc: not available URL: From jcholast at redhat.com Tue Jun 3 12:06:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 03 Jun 2014 14:06:26 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <1401788758.9684.3.camel@unused-4-145.brq.redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> <538D6A1E.9010201@redhat.com> <1401788758.9684.3.camel@unused-4-145.brq.redhat.com> Message-ID: <538DBA42.6060709@redhat.com> On 3.6.2014 11:45, Martin Basti wrote: >>> >>> >>>>> >>>>> Patch 38: >>>>> >>>>> It seems you left out the normalize_zonemgr and normalize_zone >>>>> modifications I have suggested. Is there a reason for this? >>>>> >>>> I left there original code, which works with strings. >>>> >>>> I dont use normalize_zone in DNS plugin anymore. So it would be better >>>> to work only with string, no conversion string to object and back to >>>> string. >>>> >>>> Should I modify normalize_zonemgr then? Old version works good, and code >>>> will be little longer than your example. >> >> Yes please, just to be safe ;-) >> > > Patch attached. > Thanks, ACK on everything. (Note that webui code needs to be updated to understand DNS names in RPC.) -- Jan Cholasta From lkrispen at redhat.com Tue Jun 3 12:15:50 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 03 Jun 2014 14:15:50 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401719880.1318.15.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> Message-ID: <538DBC76.4080102@redhat.com> Hi Simo, just for clarification. The plan is to move the repl config into the shared tree for the main database and eventually for others like o=ipaca. Should the topology info live in cn=etc for all databases or each in the database it configures ? If the main database is always replicated I think all topology info should be concentrated in cn=etc. Ludwig On 06/02/2014 04:38 PM, Simo Sorce wrote: > On Mon, 2014-06-02 at 10:08 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> However we may want to be able to mark a topology for 'multiple' sets. >>> For example we may want to have by default the same topology both for >>> the main database and for the CA database. >> I think we should store them separately and making them the "same" would >> be applied by a tool, but the data would just reflect the connections. >> >> I was thinking the object DN would contain the LDAP database name (or >> some rough equivalent), so we would store the IPA connections separate >> from the CA connections. > Ok, we can debate about this, maybe we simply have a flag in the > framework that 'links' two topologies and simply replicates any change > from one to the other. > > The only reason I had to 'mark' stuff in a single topology in order to > share it is that this way any change is atomic and the 2 topologies > cannot diverge, as the objects are the same, if we think the chance of > divergence is low or that it is not important because the topology > plugin will always prevent disconnected states anyway then we may avoid > it, and let the framework try to keep topologies in sync and just loudly > warn if they somehow get out of sync (which will happen briefly every > time replication of the topology objects happens :). > >>>> ad 2] the data required are available in the replicationAgreement (and >>>> eventually replica) entries, but the question is if there should be a >>>> 1:1 relationship to entries in the shared tree or a condensed >>>> representation, if there should be a server or connection oriented view. >>> My answer is no, we need only one object per connection, but config >>> entries are per direction (and different ones on different servers). >> We also need to store the type, MMR, read-only, etc, for future-proofing. > Store where ? > >> One entry per connection would mirror what we have now in the mapping >> tree (which is generally ok). I wonder if this would be limiting with >> other agreement types depending on the schema we use. > My idea is that on the connection object you have a set of attributes > that tells you how replication happen. > > So normally you'll have: > dn: uuid? > objectclass: ipaReplicationTopologySegment > left: master-X > right: master-Y > direction: both || left-right || right-left (|| none ?) > > If we have other special types we change direction accordingly or add > another attribute. > >>> We already have the list of servers, so we need to add only the list of >>> connections in the topology view. We may need to amend the servers >>> objects to add additional data in some cases. For example indicate >>> whether it is fully installed or not (on creation the topology plugin >>> would complain the server is disconnected until we create the first >>> segment, but that may actually be a good thing :-) >> Not sure I grok the fully installed part. A server isn't added as a >> master until it is actually installed, so a prepared master shouldn't >> show here. > Uhmm you may be right, if we can make this a non-problem, all the > better. > >>>> Next question: How to handle changes directly done in the dse.ldif, if >>>> everything should be done by the topology plugin it would have to verify >>>> and compare the info in cn=config and in the shared tree at every >>>> startup of the directory server, which might be complicated by the fact >>>> that the replication plugin might already be started and repl agreemnts >>>> are active before the topology plugin is started and could do its work. >>>> (plugin starting order and dependencies need to be checked). >>> Why do we care which one starts first ? >>> We can simply change replication agreements at any time, so the fact the >>> replication topology (and therefore agreements) can change after startup >>> should not be an issue. >> Someone could delete an agreement, or worse, add one we don't know >> about. Does that matter? > Someone can do this at any time after startup, so we already need to > handle this, why should it be a problem ? > > However I agree we want to avoid churn, so to answer to Ludwig as well I > guess we just want to make sure the topology plugin always starts before > the replication plugin and amends replication agreements accordingly. > >> What happens to values in the mapping tree that aren't represented in >> our own topology view? > I think we should ignore them if they reference a machine that is not a > recognized master, I guess the main issue here is a case when a master > got deleted and somehow the cn=config entry was not and we end up with > an orphan agreement that the topology plugin initially created but does > not recognize as its own. > I see 2 options here: > 1) We ignore it, and let the admin deal with the issue > 2) We mark agreements with a special attribute that indicates they have > been generated by the topology plugin, so the plugin can delete any it > does not recognize as currently valid. The only problem here is initial > migration, but that is not a huge issue IMO, the topology plugin may > simply recognize the two sides of an existing agreement are 2 ipa > masters, and just take over those entries. > > [..] > >> So when we do the migration to this version some script will be needed >> to create the initial topology from the agreements. Could we have a race >> condition? > If we do the takeover thing I describe above maybe not ? > >>> I really do not want to touch the replication plugin. It works just fine >>> as it is, and handling topology has nothing to do with handling the low >>> level details of the replication. To each its own. >>> If other deployments want to use the topology plugin, we can later move >>> it to the 389ds codebase and generalize it. >> My memory is fuzzy but I think that restarts are required when >> adding/deleting agreements. Is that right? What implications would that >> have for this? > We create (and change) agreements on the fly w/o ever restarting the > server right now, so I would say not ? > > Simo. > From pviktori at redhat.com Tue Jun 3 12:41:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Jun 2014 14:41:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <5385F487.908@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <5385F487.908@redhat.com> Message-ID: <538DC26C.4040106@redhat.com> On 05/28/2014 04:36 PM, Petr Viktorin wrote: > On 05/28/2014 04:27 PM, Petr Viktorin wrote: >> On 05/27/2014 04:20 PM, Martin Kosek wrote: >>> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> Here I start upgrading the existing default permissions to the new >>>>> Managed style. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4346 >>>>> >>>>> The patches rely on my patch 0551 >>>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>>> >>>>> >>>>> >>>>> The operation is now described at >>>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If there user has modified an old default permission, a warning is >>>>> logged the replacement permission is not added/updated. The user needs >>>>> to evaluate the situation: either update the old permission to match >>>>> the >>>>> original default, or remove the old permission, and then run >>>>> ipa-ldap-updater will create the new one. >>>>> Is bailing out the right thing to do if the old entry was modified? >>> >>> Forcing user to remove old permission and create new one seems as a >>> too much >>> work to me. After the upgrade, we need to be sure that the managed >>> permissions >>> is there. >> >> Note that this only happens if the user changed the permissions, so we >> need to be extra careful to respect their wishes. >> >>> What is the problem of having both 2 permissions in the DS? The old >>> modified >>> permission and the new system managed one? As we are dealing with allow >>> permissions, having 2 of them should be harmless. >> >> The new one could be granting too much access, the admin might have >> wanted to restrict the defaults. >> >> >>>>> It could be possible to parse the permission, figure out the changes >>>>> the >>>>> user made, and apply them to the new one, but that seems like too much >>>>> guesswork to me. >>> >>> Maybe we could do the same we do with managed permissions upgrades? >>> Only allow >>> differences in the list of attributes? I am thinking that people could >>> hotfix >>> missing attributes at permissions themselves (like adding description to >>> sudorule permission), this would lead to duplicate permissions later. >>> >>> What we could do when old ACI differs only in allowed attributes is to >>> compare >>> it to defaults and set whitelist and blacklist attributes of the new >>> managed >>> permission. Then we can safely delete the old ACI (with warning). >>> >>> If you think this is too much work, we can keep the old behavior and >>> just add >>> duplicate ACI. >> >> Having duplicate permissions would be possible, after all they have a >> different name. However I'd expect that most people would still want to >> delete the old ones, rather than letting them hide among user-defined >> permissions. >> >>>>> On the other hand, my approach has a downside as well: if the >>>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', >>>>> there's >>>>> now no way to upgrade while allowing access but keeping that attribute >>>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>>> this? It might be worth it to create a special tool that upgrades a >>>>> single permission and allows setting the excluded/included attributes >>>>> explicitly. >>> >>> This problem would be removed with my approach proposed above. >>> >>>>> There are some interesting scenarios to think about with respect to >>>>> upgrades and user changes: >>>>> >>>>> * Upgrade to old version, e.g. >>>>> - have IPA 3.2 master, IPA 3.2 replica >>>>> - upgrade master to 4.0 (old permissions are updated) >>>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>>> >>>>> This is AFAIK not supported but it does happen. >>>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>>> always add the old permissions, but with this patch, a subsequent >>>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the >>>>> old >>>>> permissions again. >>> >>> Hm, I think this is the best option we have. We should warn about this >>> behavior >>> in our release notes though. >>> >>>>> Tied to that is another scenario: >>>>> >>>>> * Re-create permissions with old names >>>>> - have IPA 4.0 master >>>>> - Create a permission named 'Modify Sudo rule' >>>>> - Upgrade to IPA 4.1 >>>>> >>>>> Here we need to make sure the new permission is *not* removed, >>>>> because a >>>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>>> ensure this the updater only removes old-style permissions. >>> >>> Right, we can decide based on objectclasses - whether permissionsv2 OC >>> is there >>> or not. >>> >>>>> >>>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>>> that an old permission named 'Modify Sudo rule' is added on the old >>>>> server. Any update to 4.0+ will remove that. >>>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>>> anyway, so users should expect this. We should still point it out in >>>>> the >>>>> docs though, since I expect some users to start messing with the >>>>> permissions before upgrading all of the infrastructure to 4.0. >>> >>> +1, I would just point out that behavior in the release notes. >>> >>>>> The second patch upgrades sudorule permissions, this server as an >>>>> example of how the will work. >>>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>>> >>>> The user read permissions patches had a conflict with these; >>>> attaching rebased >>>> version. >>> >>> Now the actual review >>> 552.2: worked fine for me. Some updates will probably be needed >>> though, based >>> on the discussion above. >>> >>> 553.2: >>> >>> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >>> Looks >>> like a noop to me, it was also never part of our add ACIs. >> >> Simo, I hazily remember discussing that we should only allow specific >> attributes on add, otherwise users can add entries with any extra >> objectclasses and attributes. Did we come to a conclusion? >> I might have confused targetattr with targetattrfilter in my notes; >> since I see targetarr is ineffective. > > OK, this was just me confused. As Ludwig told me, >> for adding an entry you need add rights for the entry and write rights >> for each attribute, so in the add aci the targetattrs are irrelevant. > so I'll remove them from the add ACI. > >>> I tried to strip that down to just "description" and I was still able >>> to add a >>> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >>> it?) >>> targetattr part of add ACI? >>> >>> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >>> ineffective. >>> Privileged user still cannot update all SUDO rule attributes. >> >> Duh. I've been staring at this too long. >> >>> Besides that, the ACIs were working fine. The attached version looks at the old permission in LDAP and if it differs from the old default only in the targetattrs, it transplants the difference to the new managed permission. There is a lot of logging here so if something didn't work the way you expected, at least you'll know what happened. When there were multiple defaults, i.e. IPA added/removed some attributes in some version: the new managed permission's attributes will be applied, so upgrades from both very old and not-so-old versions should "do the right thing". If the old permission differs in something else than targetattrs, an error is logged (this will show up in yum update output), and as before the new managed permission is not created. The user now has 3 options to fix this: - Delete the old permission, then run ipa-ldap-updater to create the new default. - Modify the old permission on an *old* system to match the old default, possibly with targetattr changes, then run a *new* ipa-ldap-updater to convert that to the new default - Modify the old permission on a *new* system, which changes it to a V2 permission, then run ipa-ldap-updater to create the new default, ending up with both permissions. The distinction betwen the last two is subtle and error-prone, but 1) I don't see a better way, considering that future upgrades need to work well (in IPA 4.0+ a user-created permission named "Add Sudo Rule" has no special status) 2) I'm hoping that people didn't modify the old default permissions that much; if they did they should have felt some pain already -- I don't think the update system in 3.x would handle such changes wery well Apply my patch 0565 before trying these out. Some testing tips: - Create 3.x master and replica - Upgrade master RPMs with these patches - to add old permissions, run ipa-ldap-updater on the replica - to simulate an upgrade, run ipa-ldap-updater on the master - to delete a managed permission: $ curl -v -H Content-Type:application/json -H Accept:applicaton/json --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -X POST -H referer:https://`hostname`/ipa/json -d '{"method": "permission_del", "params":[["$PERMISSION_NAME"],{"force":true}], "id":0 }' https://`hostname`/ipa/json - be careful where you run permission-mod; on 4.0 it will convert the permission to V2 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0552.3-Add-mechanism-for-updating-permissions-to-managed.patch Type: text/x-patch Size: 9320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0553.3-Convert-Sudo-rule-default-permissions-to-managed.patch Type: text/x-patch Size: 6660 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0554.3-Add-missing-attributes-to-Modify-Sudo-rule-permissio.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: From simo at redhat.com Tue Jun 3 12:53:47 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 Jun 2014 08:53:47 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538DBC76.4080102@redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> <538DBC76.4080102@redhat.com> Message-ID: <1401800027.6551.32.camel@willson.usersys.redhat.com> On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote: > Hi Simo, > > just for clarification. The plan is to move the repl config into the > shared tree for the main database and eventually for others like > o=ipaca. Should the topology info live in cn=etc for all databases or > each in the database it configures ? > If the main database is always replicated I think all topology info > should be concentrated in cn=etc. This is actually a good question, I think we want to keep it in the main database, but to be forward looking, we should set the basedn of the configuration (per topology) in the topology plugin configuration entry, this way if it turns out we should move it in their own dbs we can just do it. The other issue is the list of masters though. I do not want to move them in the topology tree (breaks compatibility) nor duplicate those entries if possible, but we may need to do it or also configure where the "nodes" are stored. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Jun 3 13:18:22 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 03 Jun 2014 09:18:22 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <538D86E4.5050605@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> Message-ID: <1401801502.4161.7.camel@ipa.example.com> On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > On 3.6.2014 05:08, Nathaniel McCallum wrote: > > This command calls the token sync HTTP POST call in the server providing > > the CLI interface to synchronization. > > > > https://fedorahosted.org/freeipa/ticket/4260 > > > > This patch depends on my patch #0055. > > > > Build fails on validation. You forgot to update API.txt and also the > command misses __doc__. > > (not a proper review) Thanks, fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0056.1-Add-otptoken-sync-command.patch Type: text/x-patch Size: 4514 bytes Desc: not available URL: From lkrispen at redhat.com Tue Jun 3 13:47:30 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 03 Jun 2014 15:47:30 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401800027.6551.32.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> <538DBC76.4080102@redhat.com> <1401800027.6551.32.camel@willson.usersys.redhat.com> Message-ID: <538DD1F2.9050904@redhat.com> On 06/03/2014 02:53 PM, Simo Sorce wrote: > On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote: >> Hi Simo, >> >> just for clarification. The plan is to move the repl config into the >> shared tree for the main database and eventually for others like >> o=ipaca. Should the topology info live in cn=etc for all databases or >> each in the database it configures ? >> If the main database is always replicated I think all topology info >> should be concentrated in cn=etc. > This is actually a good question, I think we want to keep it in the main > database, but to be forward looking, we should set the basedn of the > configuration (per topology) in the topology plugin configuration entry, > this way if it turns out we should move it in their own dbs we can just > do it. yes, this can be handle in the topology plugin configuration, we need to define which databases should be controlled and where the root for the replicated topology information is. I assume we want only one plugin instance. > > The other issue is the list of masters though. I do not want to move > them in the topology tree (breaks compatibility) nor duplicate those > entries if possible, but we may need to do it or also configure where > the "nodes" are stored. Agreed. What about non-masters, in the ticket there was also discussion about read only replicas - to be delayed ? > > Simo. > From mkosek at redhat.com Tue Jun 3 14:02:21 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jun 2014 16:02:21 +0200 Subject: [Freeipa-devel] [PATCH 0029-0046, 0047] Internationalized domain names in DNS plugin In-Reply-To: <538DBA42.6060709@redhat.com> References: <1396440430.2333.10.camel@unused-4-145.brq.redhat.com> <533D639B.50901@redhat.com> <1396617021.2795.40.camel@unused-4-145.brq.redhat.com> <1397229835.2343.8.camel@unused-4-145.brq.redhat.com> <535637A5.1020107@redhat.com> <1400689411.2232.4.camel@unused-4-145.brq.redhat.com> <5382FC6B.8040402@redhat.com> <1401277811.2263.1.camel@unused-4-145.brq.redhat.com> <5385CEFA.9030101@redhat.com> <1401280275.2263.4.camel@unused-4-145.brq.redhat.com> <1401709818.2253.1.camel@unused-4-145.brq.redhat.com> <538C8852.60508@redhat.com> <1401721747.2253.23.camel@unused-4-145.brq.redhat.com> <1401722962.2253.25.camel@unused-4-145.brq.redhat.com> <538D6A1E.9010201@redhat.com> <1401788758.9684.3.camel@unused-4-145.brq.redhat.com> <538DBA42.6060709@redhat.com> Message-ID: <538DD56D.2010101@redhat.com> On 06/03/2014 02:06 PM, Jan Cholasta wrote: > On 3.6.2014 11:45, Martin Basti wrote: >>>> >>>> >>>>>> >>>>>> Patch 38: >>>>>> >>>>>> It seems you left out the normalize_zonemgr and normalize_zone >>>>>> modifications I have suggested. Is there a reason for this? >>>>>> >>>>> I left there original code, which works with strings. >>>>> >>>>> I dont use normalize_zone in DNS plugin anymore. So it would be better >>>>> to work only with string, no conversion string to object and back to >>>>> string. >>>>> >>>>> Should I modify normalize_zonemgr then? Old version works good, and code >>>>> will be little longer than your example. >>> >>> Yes please, just to be safe ;-) >>> >> >> Patch attached. >> > > Thanks, ACK on everything. > > (Note that webui code needs to be updated to understand DNS names in RPC.) > Pushed all to master. Thanks for careful review. Martin From mkosek at redhat.com Tue Jun 3 14:49:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jun 2014 16:49:14 +0200 Subject: [Freeipa-devel] [PATCH] 0058 Test DNS: dnsrecord-* zone.test. zone.test. should work In-Reply-To: <1401452106.2306.5.camel@unused-4-145.brq.redhat.com> References: <1401452106.2306.5.camel@unused-4-145.brq.redhat.com> Message-ID: <538DE06A.2010605@redhat.com> On 05/30/2014 02:15 PM, Martin Basti wrote: > Test only, issue was fixed in > https://fedorahosted.org/freeipa/ticket/3169 > > Required patches: mbasti 0029-0032, 0034-0040, 0047, > 0041-0042, 0045-0046 > > Patch attached. > Ticket: https://fedorahosted.org/freeipa/ticket/4232 Works for me, ACK. Pushed to master. Martin From mkosek at redhat.com Tue Jun 3 14:49:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jun 2014 16:49:48 +0200 Subject: [Freeipa-devel] [PATCH] 0057 Fix indentation In-Reply-To: <1401451739.2306.1.camel@unused-4-145.brq.redhat.com> References: <1401451739.2306.1.camel@unused-4-145.brq.redhat.com> Message-ID: <538DE08C.1010201@redhat.com> On 05/30/2014 02:08 PM, Martin Basti wrote: > Patch fixes indentation in one function in ipalib/util.py Ok, at least we have it fixed now. ACK. Pushed to master. Martin From mkosek at redhat.com Tue Jun 3 14:50:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Jun 2014 16:50:06 +0200 Subject: [Freeipa-devel] [PATCH] 0056 Test DNS: wildcards in name In-Reply-To: <1401297125.2263.21.camel@unused-4-145.brq.redhat.com> References: <1401296666.2263.13.camel@unused-4-145.brq.redhat.com> <1401297125.2263.21.camel@unused-4-145.brq.redhat.com> Message-ID: <538DE09E.6080901@redhat.com> On 05/28/2014 07:12 PM, Martin Basti wrote: > On Wed, 2014-05-28 at 19:04 +0200, Martin Basti wrote: >> Test for ticket https://fedorahosted.org/freeipa/ticket/3148 >> Patch attached. >> >> Required patches: mbasti 0029-0032, 0034-0040, 0047, >> 0041-0042, 0045-0046 > > Sorry, patch is attached here Works for me, ACK. Pushed to master. Martin From edewata at redhat.com Tue Jun 3 15:08:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 03 Jun 2014 10:08:26 -0500 Subject: [Freeipa-devel] [Pki-devel] faster ways to build/test dogtag? In-Reply-To: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> References: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> Message-ID: <538DE4EA.7010405@redhat.com> Hi Fraser, If you haven't got an answer yet, this is how I set up my lab environment: 1. As a non-root user (e.g. edewata) I checked out the source code into my home directory (e.g. ~/Projects/pki). In the lab the home directory is remotely mounted so it's slow, but it's useful to share files among multiple machines. 2. As root user I build Dogtag on root's home directory with this command: compose_pki_core_packages --work-dir /root/ hybrid_rpms It's faster because root's home directory is local. I also have some scripts that I use to simplify the build/installation tasks. Feel free to use them but they may require certain directory layout. http://fedorapeople.org/cgit/edewata/public_git/pki-dev.git/ Ideally there should be a faster way to compile & refresh Dogtag installation without building & reinstalling the RPM packages, but we just haven't got a chance to do it yet. It may require converting some of the installation code in the RPM spec file into CMake. -- Endi S. Dewata On 5/27/2014 2:00 AM, Fraser Tweedale wrote: > Hi all, > > I've been working on a fix for a profile issue > (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I > find the scripts/compose_pki_core_packages -> yum install -> test > cycle frustratingly slow on idm.lab.bos. Is there a quicker way > to build and test the software - particularly as part of the larger > IPA/certmonger/dogtag ecosystem? > > Cheers, > > Fraser > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel > From simo at redhat.com Tue Jun 3 15:59:39 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 Jun 2014 11:59:39 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538DD1F2.9050904@redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> <538DBC76.4080102@redhat.com> <1401800027.6551.32.camel@willson.usersys.redhat.com> <538DD1F2.9050904@redhat.com> Message-ID: <1401811179.6551.35.camel@willson.usersys.redhat.com> On Tue, 2014-06-03 at 15:47 +0200, Ludwig Krispenz wrote: > On 06/03/2014 02:53 PM, Simo Sorce wrote: > > On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote: > >> Hi Simo, > >> > >> just for clarification. The plan is to move the repl config into the > >> shared tree for the main database and eventually for others like > >> o=ipaca. Should the topology info live in cn=etc for all databases or > >> each in the database it configures ? > >> If the main database is always replicated I think all topology info > >> should be concentrated in cn=etc. > > This is actually a good question, I think we want to keep it in the main > > database, but to be forward looking, we should set the basedn of the > > configuration (per topology) in the topology plugin configuration entry, > > this way if it turns out we should move it in their own dbs we can just > > do it. > yes, this can be handle in the topology plugin configuration, we need to > define which databases should be controlled and where the root for the > replicated topology information is. > I assume we want only one plugin instance. > > > > The other issue is the list of masters though. I do not want to move > > them in the topology tree (breaks compatibility) nor duplicate those > > entries if possible, but we may need to do it or also configure where > > the "nodes" are stored. > Agreed. What about non-masters, in the ticket there was also discussion > about read only replicas - to be delayed ? TBD, from the pov of the plugin we care only about Nodes and links, but yeah dealing with R/O replicas will mean the plugin should understand such servers need a segment that sends data to them but do not need a segment that carries data out. Working on the topology consistency checker will be fun :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Jun 3 21:16:40 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Jun 2014 17:16:40 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538D8751.9030302@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> Message-ID: <538E3B38.7010709@redhat.com> On 06/03/2014 04:29 AM, Petr Spacek wrote: > On 3.6.2014 09:54, Martin Kosek wrote: >> On 06/02/2014 03:59 PM, Petr Vobornik wrote: >>> Hi List, >>> >>> the purpose if this mail is to start a discussion about >>> reorganization of >>> navigation items. Users are not fond of such change so we should >>> come up with a >>> solution which would last for some time. >>> >>> Problem: >>> UX recommendation is that one menu level should contain maximum of 7 >>> items. We >>> have 10 items in Identity, 7 in Policy and 7 in IPA Server. >>> Basically we >>> reached max. capacity of all 1st-level items. >>> >>> Solution: >>> Introduce new 1st-level items and redistribute 2nd-level items. >>> >>> Initial Draft: >>> >>> Identity (6) >>> - Users >>> - Groups >>> - Hosts >>> - Hostgroups >>> - Netgroups >>> - Services >> >> ok, though I have different division in mind. >> >>> Policy (5) some better name? >>> - HBAC >>> - SUDO >>> - Automount >>> - Automember >>> - SELinux User Maps >> >> I am not sure about Automount, SUDO and Automember as they are not so >> about >> policy related to users but rather about central storage for native >> Linux >> services - similarly to DNS. >> >>> Authentication (4) >>> - Radius Server Proxy >>> - OTP Tokens >>> - Password Policy >>> - Kerberos Ticket Policy >> >> Hm, "Policy" is indeed strange. >> >>> Infrastructure (6) some better name? >>> - DNS >>> - Realm Domains >>> - Trust >>> - Views >>> - ID Ranges >>> - Certificates >>> >>> Permissions (3) >>> - Role Based Access Control >>> - Self Service Permissions >>> - Delegation >>> >>> Configuration (1) >>> - Global >> >> Let me twist your proposal a bit and come to it from different way, i.e. >> thinking about what admin wants to do. If he wants to set up a user, >> he should >> not need to go to 2 different top level items. >> >> Users >> - Users >> - Groups >> - OTP Tokens >> - Password Policy >> - Automember >> >> Hosts >> - Hosts >> - Host groups >> - Netgroups >> - HBAC >> - SELinux User Maps User maps are more about users than hosts. No? >> >> Services >> - Services >> - SUDO >> - Automount I do not like "services" on two levels but I can't come up with an alternative. >> >> Trusts >> - (future) Views >> - Trust configuration >> - Trusts Ad other trusts in future >> >> Infrastructure >> - Certificates >> - DNS >> - Realm Domains >> - Kerberos Ticket Policy >> - (future) Replication topology >> >> Configuration >> - Global >> - RBAC Is it IPA access control? >> - ID Ranges I suggest different slicing: Configuration - Global - Access control - Realm Domains - Kerberos Ticket Policy - ID ranges Infrastructure - (future) Replication topology - DNS - (future) Vault I am not sure about Certificates. Is it about root CA? Can you point me to a feature page that corresponds to this feature? Should we have also: (future) Support - Documentation - Project Wiki - File issue here ... >> >> Does that make sense? > > This seems reasolable. Couple nitpicks: > 1) "Certificates" under "Infrastructure": > Now we don't support them for users, but this will change in > (distant?) future. Also, hosts have own certificates. Services can > have own certificates etc. > > Can we have e.g. "Certificates" button at two different places? (But > still opening the same dialog.) > > > 2) "Kerberos Ticket Policy" is also related to users ... > > 3) "Configuration" and "Infrastructure" seems so related to me that I > would personally merge them. > > > Anyway, this seems like a step in the right direction! > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From sbingram at gmail.com Tue Jun 3 23:15:20 2014 From: sbingram at gmail.com (Stephen Ingram) Date: Tue, 3 Jun 2014 16:15:20 -0700 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538E3B38.7010709@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> Message-ID: On Tue, Jun 3, 2014 at 2:16 PM, Dmitri Pal wrote: > >>>> Services >>> - Services >>> - SUDO >>> - Automount >>> >> > I do not like "services" on two levels but I can't come up with an > alternative. > Maybe Service Principles or Service Keys as that is what's in there, no? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Jun 4 03:50:35 2014 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Jun 2014 23:50:35 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538C8338.1040502@redhat.com> References: <538C8338.1040502@redhat.com> Message-ID: <538E978B.7080609@redhat.com> On 06/02/2014 09:59 AM, Petr Vobornik wrote: > Hi List, > > the purpose if this mail is to start a discussion about reorganization > of navigation items. Users are not fond of such change so we should > come up with a solution which would last for some time. > > Problem: > UX recommendation is that one menu level should contain maximum of 7 > items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. > Basically we reached max. capacity of all 1st-level items. > How hard and fast is that recommendation? I realize it is for New things, but for an existing? > Solution: > Introduce new 1st-level items and redistribute 2nd-level items. > > Initial Draft: > > Identity (6) > - Users > - Groups These are really two distinct things. Rarely are you modifying users and hosts. > - Hosts > - Hostgroups These would go nicely with HBAC > - Netgroups > - Services > > Policy (5) some better name? > - HBAC > - SUDO SUDO seems like it should go with users > - Automount Put with hosts > - Automember Is this for all LDAP type stuff? Probably should go with the ACLs in policy. > - SELinux User Maps > > Authentication (4) > - Radius Server Proxy > - OTP Tokens > - Password Policy > - Kerberos Ticket Policy > > Infrastructure (6) some better name? > - DNS Make this a top level. People tend to think of DNS as its own thing. > - Realm Domains > - Trust Maybe these go with Kerberos Ticket policy? Keep Kerberos with Kerberos. Maybe a Kerberos top level tab? Authentication? > - Views With kerberos > - ID Ranges This and Password policy seem like they should be linked. > - Certificates Maybe with Kerberos? A Credentials top level item? Do we really need all certificates together? User and host certificates are > > Permissions (3) Directory Access Controls. Maybe a Directory Admin top level tab? > - Role Based Access Control > - Self Service Permissions > - Delegation > > Configuration (1) > - Global > > > Notes: > * draft focuses only on first two levels of navigation > * 'Permission' and 'Configuration' could be merged into old 'IPA Server' > * 'Views' are related to Identity and Trust, they have no meaning > without some kind of trust -> are next to 'Trusts' > * it's weird to have 'Policy' item and items with "policy" in name to > have in 'Authentication' > > Comments are welcome From invite at feedspotmailer.com Wed Jun 4 05:17:19 2014 From: invite at feedspotmailer.com (farzad niazmand via Feedspot.com) Date: Wed, 4 Jun 2014 05:17:19 +0000 Subject: [Freeipa-devel] farzad niazmand has invited you to try Feedspot Message-ID: <00000146654f610a-b8d3bab1-e97f-4fc7-ac0e-7778bcd02e6d-000000@email.amazonses.com> farzad niazmand has invited you to join Feedspot - A place to read everything you need to stay informed and live and work smarter.\n\n http://www.feedspot.com/r_debcb4a074d4_*_freeipa-devel at redhat.com#monthlycode \n\n Feedspot is a place to organize and read all the news sites and blogs you visit in one place, where keeping up with your favorite sites is as easy as checking your email.\n\n Start using Feedspot today to get a complimentary month of Feedspot Premium, with even more of the features that make Feedspot great. And just for trying Feedspot, your friend will get rewards too.\n\n - The Feedspot Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Wed Jun 4 06:20:49 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 4 Jun 2014 16:20:49 +1000 Subject: [Freeipa-devel] [Pki-devel] faster ways to build/test dogtag? In-Reply-To: <538DE4EA.7010405@redhat.com> References: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> <538DE4EA.7010405@redhat.com> Message-ID: <20140604062049.GH11349@dhcp-40-8.bne.redhat.com> On Tue, Jun 03, 2014 at 10:08:26AM -0500, Endi Sukma Dewata wrote: > Hi Fraser, > > If you haven't got an answer yet, this is how I set up my lab environment: > > 1. As a non-root user (e.g. edewata) I checked out the source code into my > home directory (e.g. ~/Projects/pki). In the lab the home directory is > remotely mounted so it's slow, but it's useful to share files among multiple > machines. > > 2. As root user I build Dogtag on root's home directory with this command: > > compose_pki_core_packages --work-dir /root/ hybrid_rpms > > It's faster because root's home directory is local. > > I also have some scripts that I use to simplify the build/installation > tasks. Feel free to use them but they may require certain directory layout. > > http://fedorapeople.org/cgit/edewata/public_git/pki-dev.git/ > > Ideally there should be a faster way to compile & refresh Dogtag > installation without building & reinstalling the RPM packages, but we just > haven't got a chance to do it yet. It may require converting some of the > installation code in the RPM spec file into CMake. > Thanks for your suggestions. I'll spend a few minutes later this week getting all this information up on the wiki(s). Having these workflow tips/tools in one place (or a handful of places i.e. a page each in the IPA and Dogtag wikis) will be valuable for new hires and provide a starting place for discussions on workflow improvements. Cheers, Fraser > -- > Endi S. Dewata > > On 5/27/2014 2:00 AM, Fraser Tweedale wrote: > >Hi all, > > > >I've been working on a fix for a profile issue > >(https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I > >find the scripts/compose_pki_core_packages -> yum install -> test > >cycle frustratingly slow on idm.lab.bos. Is there a quicker way > >to build and test the software - particularly as part of the larger > >IPA/certmonger/dogtag ecosystem? > > > >Cheers, > > > >Fraser > > > >_______________________________________________ > >Freeipa-devel mailing list > >Freeipa-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-devel > > > >_______________________________________________ > >Pki-devel mailing list > >Pki-devel at redhat.com > >https://www.redhat.com/mailman/listinfo/pki-devel > > > > From mkosek at redhat.com Wed Jun 4 06:34:55 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 08:34:55 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538E3B38.7010709@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> Message-ID: <538EBE0F.3060302@redhat.com> On 06/03/2014 11:16 PM, Dmitri Pal wrote: > On 06/03/2014 04:29 AM, Petr Spacek wrote: >> On 3.6.2014 09:54, Martin Kosek wrote: >>> On 06/02/2014 03:59 PM, Petr Vobornik wrote: >>>> Hi List, >>>> >>>> the purpose if this mail is to start a discussion about reorganization of >>>> navigation items. Users are not fond of such change so we should come up >>>> with a >>>> solution which would last for some time. >>>> >>>> Problem: >>>> UX recommendation is that one menu level should contain maximum of 7 items. We >>>> have 10 items in Identity, 7 in Policy and 7 in IPA Server. Basically we >>>> reached max. capacity of all 1st-level items. >>>> >>>> Solution: >>>> Introduce new 1st-level items and redistribute 2nd-level items. >>>> >>>> Initial Draft: >>>> >>>> Identity (6) >>>> - Users >>>> - Groups >>>> - Hosts >>>> - Hostgroups >>>> - Netgroups >>>> - Services >>> >>> ok, though I have different division in mind. >>> >>>> Policy (5) some better name? >>>> - HBAC >>>> - SUDO >>>> - Automount >>>> - Automember >>>> - SELinux User Maps >>> >>> I am not sure about Automount, SUDO and Automember as they are not so about >>> policy related to users but rather about central storage for native Linux >>> services - similarly to DNS. >>> >>>> Authentication (4) >>>> - Radius Server Proxy >>>> - OTP Tokens >>>> - Password Policy >>>> - Kerberos Ticket Policy >>> >>> Hm, "Policy" is indeed strange. >>> >>>> Infrastructure (6) some better name? >>>> - DNS >>>> - Realm Domains >>>> - Trust >>>> - Views >>>> - ID Ranges >>>> - Certificates >>>> >>>> Permissions (3) >>>> - Role Based Access Control >>>> - Self Service Permissions >>>> - Delegation >>>> >>>> Configuration (1) >>>> - Global >>> >>> Let me twist your proposal a bit and come to it from different way, i.e. >>> thinking about what admin wants to do. If he wants to set up a user, he should >>> not need to go to 2 different top level items. >>> >>> Users >>> - Users >>> - Groups >>> - OTP Tokens >>> - Password Policy >>> - Automember >>> >>> Hosts >>> - Hosts >>> - Host groups >>> - Netgroups >>> - HBAC >>> - SELinux User Maps > > User maps are more about users than hosts. No? They are both about users and hosts. You set up what SELinux role you want for a user on given host. Similarly to HBAC. > >>> >>> Services >>> - Services >>> - SUDO >>> - Automount > > I do not like "services" on two levels but I can't come up with an alternative. >>> >>> Trusts >>> - (future) Views >>> - Trust configuration >>> - Trusts > > Ad other trusts in future +1 > >>> >>> Infrastructure >>> - Certificates >>> - DNS >>> - Realm Domains >>> - Kerberos Ticket Policy >>> - (future) Replication topology >>> >>> Configuration >>> - Global >>> - RBAC > > Is it IPA access control? Yes - i.e. menu not useful for someone besides FreeIPA security admin. > >>> - ID Ranges > > I suggest different slicing: > > Configuration > - Global > - Access control > - Realm Domains > - Kerberos Ticket Policy > - ID ranges Hmm, that makes sense. > > > Infrastructure > - (future) Replication topology > - DNS > - (future) Vault > > I am not sure about Certificates. > Is it about root CA? Can you point me to a feature page that corresponds to > this feature? http://www.freeipa.org/page/V3/Cert_find It gives you all certificates issued by FreeIPA PKI. Subsystem certificates, service certificates. > > Should we have also: > (future) Support > - Documentation > - Project Wiki > - File issue here > ... Maybe, though there is now About-ish menu already, in the top bar. Let me come up with new proposal based on your comments and on Adam Young's ideas elsewhere in the thread. Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Trusts - Trust configuration - Trusts - (future) Views Infrastructure - Certificates - DNS - (future) Replication topology - (future) Vault Configuration - Global - Access Control (RBAC) - Realm Domains - ID Ranges Martin From mkosek at redhat.com Wed Jun 4 06:44:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 08:44:15 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538EBE0F.3060302@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> Message-ID: <538EC03F.3060103@redhat.com> On 06/04/2014 08:34 AM, Martin Kosek wrote: ... > Users > - Users > - Groups > - SUDO > > Hosts > - Hosts > - Host groups > - Services > - Netgroups > - Automount > > Authentication > - OTP Tokens > - Password Policy > - Kerberos Ticket Policy > > Policy > - HBAC > - SELinux User Maps > - Automember Alternatively, we could rename Policy to "Authorization" as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. > > Trusts > - Trust configuration > - Trusts > - (future) Views > > Infrastructure > - Certificates > - DNS > - (future) Replication topology > - (future) Vault > > Configuration > - Global > - Access Control (RBAC) > - Realm Domains > - ID Ranges > > Martin From pspacek at redhat.com Wed Jun 4 07:37:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Jun 2014 09:37:51 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538EC03F.3060103@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> Message-ID: <538ECCCF.6000005@redhat.com> On 4.6.2014 08:44, Martin Kosek wrote: > On 06/04/2014 08:34 AM, Martin Kosek wrote: > ... This is really good proposal! Scroll down to see three nit picks: >> Users >> - Users >> - Groups >> - SUDO >> >> Hosts >> - Hosts >> - Host groups >> - Services >> - Netgroups >> - Automount >> >> Authentication >> - OTP Tokens >> - Password Policy >> - Kerberos Ticket Policy >> >> Policy >> - HBAC >> - SELinux User Maps >> - Automember > > Alternatively, we could rename Policy to "Authorization" as both HBAC and > SELinux is about authorizing what an authenticated user can do. We would just > need to move Automember to different place, though this one is difficult - it > relates both to Users and Hosts, just like Netgroup. > >> >> Trusts >> - Trust configuration >> - Trusts >> - (future) Views >> >> Infrastructure >> - Certificates ^^^ I would like to see this under "Authentication". Nowaways it is used to authenticate machines and it will be extended to user authentication as soon as Smart Card support is added. >> - DNS >> - (future) Replication topology ^^^ Personally, I would place it under "IPA Configuration". >> - (future) Vault ^^^ Why is Vault under "Infrastructure"? It sounds like "Authentication" to me. It is meant to store plain-text passwords etc., no? It seems that I'm proposing to reduce "Infrastructure" to "DNS". We can move DNS somewhere or make DNS top-level item until we get DHCP or something similar. This also opens the question if DNS management is really the right business for us :-) I'm personally not sure :-) >> Configuration ^^^ Can it be "IPA configuration" or something like that? Just "Configuration" seems too vague to me. After all, everything in the UI is some kind of configuration :-) >> - Global >> - Access Control (RBAC) >> - Realm Domains >> - ID Ranges -- Petr^2 Spacek From pvoborni at redhat.com Wed Jun 4 07:55:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 04 Jun 2014 09:55:46 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538ECCCF.6000005@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <538ECCCF.6000005@redhat.com> Message-ID: <538ED102.6090300@redhat.com> On 4.6.2014 09:37, Petr Spacek wrote: > On 4.6.2014 08:44, Martin Kosek wrote: >> On 06/04/2014 08:34 AM, Martin Kosek wrote: >> ... > > This is really good proposal! Scroll down to see three nit picks: > >>> Users >>> - Users >>> - Groups >>> - SUDO >>> >>> Hosts >>> - Hosts >>> - Host groups >>> - Services >>> - Netgroups >>> - Automount >>> >>> Authentication >>> - OTP Tokens >>> - Password Policy >>> - Kerberos Ticket Policy >>> >>> Policy >>> - HBAC >>> - SELinux User Maps >>> - Automember >> >> Alternatively, we could rename Policy to "Authorization" as both HBAC and >> SELinux is about authorizing what an authenticated user can do. We >> would just >> need to move Automember to different place, though this one is >> difficult - it >> relates both to Users and Hosts, just like Netgroup. >> >>> >>> Trusts >>> - Trust configuration >>> - Trusts >>> - (future) Views >>> >>> Infrastructure >>> - Certificates > ^^^ I would like to see this under "Authentication". Nowaways it is used > to authenticate machines and it will be extended to user authentication > as soon as Smart Card support is added. > >>> - DNS >>> - (future) Replication topology > ^^^ Personally, I would place it under "IPA Configuration". > >>> - (future) Vault > ^^^ Why is Vault under "Infrastructure"? It sounds like "Authentication" > to me. It is meant to store plain-text passwords etc., no? > > > It seems that I'm proposing to reduce "Infrastructure" to "DNS". We can > move DNS somewhere or make DNS top-level item until we get DHCP or > something similar. I would rather avoid having a temporary top-level item. > > This also opens the question if DNS management is really the right > business for us :-) I'm personally not sure :-) > > >>> Configuration > ^^^ Can it be "IPA configuration" or something like that? Just > "Configuration" seems too vague to me. After all, everything in the UI > is some kind of configuration :-) We can leave the old "IPA Server" name. I agree that "Replication topology" could be here because it configures the tool and not the data, similar to other items under this category. But I think that many users would try to find it in infrastructure. > >>> - Global >>> - Access Control (RBAC) >>> - Realm Domains >>> - ID Ranges > -- Petr Vobornik From mkosek at redhat.com Wed Jun 4 08:11:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 10:11:52 +0200 Subject: [Freeipa-devel] [PATCH] 0565 ipalib.aci: Fix bugs in comparison In-Reply-To: <538DB537.2000803@redhat.com> References: <538DB537.2000803@redhat.com> Message-ID: <538ED4C8.1070702@redhat.com> On 06/03/2014 01:44 PM, Petr Viktorin wrote: > I found two bugs in the ACI comparison code, one new and one old. > > This fixes them and adds some more tests. > ACK. Pushed to master: a2aca68f63c2e442dc9e103ae31ba0c67d606186 Martin From mkosek at redhat.com Wed Jun 4 08:15:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 10:15:26 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <538DC26C.4040106@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <5385F487.908@redhat.com> <538DC26C.4040106@redhat.com> Message-ID: <538ED59E.9050305@redhat.com> On 06/03/2014 02:41 PM, Petr Viktorin wrote: > On 05/28/2014 04:36 PM, Petr Viktorin wrote: >> On 05/28/2014 04:27 PM, Petr Viktorin wrote: >>> On 05/27/2014 04:20 PM, Martin Kosek wrote: >>>> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>>>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> Here I start upgrading the existing default permissions to the new >>>>>> Managed style. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4346 >>>>>> >>>>>> The patches rely on my patch 0551 >>>>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>>>> >>>>>> >>>>>> >>>>>> The operation is now described at >>>>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If there user has modified an old default permission, a warning is >>>>>> logged the replacement permission is not added/updated. The user needs >>>>>> to evaluate the situation: either update the old permission to match >>>>>> the >>>>>> original default, or remove the old permission, and then run >>>>>> ipa-ldap-updater will create the new one. >>>>>> Is bailing out the right thing to do if the old entry was modified? >>>> >>>> Forcing user to remove old permission and create new one seems as a >>>> too much >>>> work to me. After the upgrade, we need to be sure that the managed >>>> permissions >>>> is there. >>> >>> Note that this only happens if the user changed the permissions, so we >>> need to be extra careful to respect their wishes. >>> >>>> What is the problem of having both 2 permissions in the DS? The old >>>> modified >>>> permission and the new system managed one? As we are dealing with allow >>>> permissions, having 2 of them should be harmless. >>> >>> The new one could be granting too much access, the admin might have >>> wanted to restrict the defaults. >>> >>> >>>>>> It could be possible to parse the permission, figure out the changes >>>>>> the >>>>>> user made, and apply them to the new one, but that seems like too much >>>>>> guesswork to me. >>>> >>>> Maybe we could do the same we do with managed permissions upgrades? >>>> Only allow >>>> differences in the list of attributes? I am thinking that people could >>>> hotfix >>>> missing attributes at permissions themselves (like adding description to >>>> sudorule permission), this would lead to duplicate permissions later. >>>> >>>> What we could do when old ACI differs only in allowed attributes is to >>>> compare >>>> it to defaults and set whitelist and blacklist attributes of the new >>>> managed >>>> permission. Then we can safely delete the old ACI (with warning). >>>> >>>> If you think this is too much work, we can keep the old behavior and >>>> just add >>>> duplicate ACI. >>> >>> Having duplicate permissions would be possible, after all they have a >>> different name. However I'd expect that most people would still want to >>> delete the old ones, rather than letting them hide among user-defined >>> permissions. >>> >>>>>> On the other hand, my approach has a downside as well: if the >>>>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', >>>>>> there's >>>>>> now no way to upgrade while allowing access but keeping that attribute >>>>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>>>> this? It might be worth it to create a special tool that upgrades a >>>>>> single permission and allows setting the excluded/included attributes >>>>>> explicitly. >>>> >>>> This problem would be removed with my approach proposed above. >>>> >>>>>> There are some interesting scenarios to think about with respect to >>>>>> upgrades and user changes: >>>>>> >>>>>> * Upgrade to old version, e.g. >>>>>> - have IPA 3.2 master, IPA 3.2 replica >>>>>> - upgrade master to 4.0 (old permissions are updated) >>>>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>>>> >>>>>> This is AFAIK not supported but it does happen. >>>>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>>>> always add the old permissions, but with this patch, a subsequent >>>>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the >>>>>> old >>>>>> permissions again. >>>> >>>> Hm, I think this is the best option we have. We should warn about this >>>> behavior >>>> in our release notes though. >>>> >>>>>> Tied to that is another scenario: >>>>>> >>>>>> * Re-create permissions with old names >>>>>> - have IPA 4.0 master >>>>>> - Create a permission named 'Modify Sudo rule' >>>>>> - Upgrade to IPA 4.1 >>>>>> >>>>>> Here we need to make sure the new permission is *not* removed, >>>>>> because a >>>>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>>>> ensure this the updater only removes old-style permissions. >>>> >>>> Right, we can decide based on objectclasses - whether permissionsv2 OC >>>> is there >>>> or not. >>>> >>>>>> >>>>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>>>> that an old permission named 'Modify Sudo rule' is added on the old >>>>>> server. Any update to 4.0+ will remove that. >>>>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>>>> anyway, so users should expect this. We should still point it out in >>>>>> the >>>>>> docs though, since I expect some users to start messing with the >>>>>> permissions before upgrading all of the infrastructure to 4.0. >>>> >>>> +1, I would just point out that behavior in the release notes. >>>> >>>>>> The second patch upgrades sudorule permissions, this server as an >>>>>> example of how the will work. >>>>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>>>> >>>>> The user read permissions patches had a conflict with these; >>>>> attaching rebased >>>>> version. >>>> >>>> Now the actual review >>>> 552.2: worked fine for me. Some updates will probably be needed >>>> though, based >>>> on the discussion above. >>>> >>>> 553.2: >>>> >>>> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >>>> Looks >>>> like a noop to me, it was also never part of our add ACIs. >>> >>> Simo, I hazily remember discussing that we should only allow specific >>> attributes on add, otherwise users can add entries with any extra >>> objectclasses and attributes. Did we come to a conclusion? >>> I might have confused targetattr with targetattrfilter in my notes; >>> since I see targetarr is ineffective. >> >> OK, this was just me confused. As Ludwig told me, >>> for adding an entry you need add rights for the entry and write rights >>> for each attribute, so in the add aci the targetattrs are irrelevant. >> so I'll remove them from the add ACI. >> >>>> I tried to strip that down to just "description" and I was still able >>>> to add a >>>> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >>>> it?) >>>> targetattr part of add ACI? >>>> >>>> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >>>> ineffective. >>>> Privileged user still cannot update all SUDO rule attributes. >>> >>> Duh. I've been staring at this too long. >>> >>>> Besides that, the ACIs were working fine. > > The attached version looks at the old permission in LDAP and if it differs from > the old default only in the targetattrs, it transplants the difference to the > new managed permission. > > There is a lot of logging here so if something didn't work the way you > expected, at least you'll know what happened. > > When there were multiple defaults, i.e. IPA added/removed some attributes in > some version: the new managed permission's attributes will be applied, so > upgrades from both very old and not-so-old versions should "do the right thing". > > If the old permission differs in something else than targetattrs, an error is > logged (this will show up in yum update output), and as before the new managed > permission is not created. The user now has 3 options to fix this: > - Delete the old permission, then run ipa-ldap-updater to create the new default. This will probably be the safest route to go for users. > - Modify the old permission on an *old* system to match the old default, > possibly with targetattr changes, then run a *new* ipa-ldap-updater to convert > that to the new default > - Modify the old permission on a *new* system, which changes it to a V2 > permission, then run ipa-ldap-updater to create the new default, ending up with > both permissions. > > The distinction betwen the last two is subtle and error-prone, but > 1) I don't see a better way, considering that future upgrades need to work well > (in IPA 4.0+ a user-created permission named "Add Sudo Rule" has no special > status) > 2) I'm hoping that people didn't modify the old default permissions that much; > if they did they should have felt some pain already -- I don't think the update > system in 3.x would handle such changes wery well I would personally still be more forceful, especially given the arguments you gave in 2) and just log the old too-modified ACI and convert it to the new style, but there are not many followers to this opinion though... > Apply my patch 0565 before trying these out. > > > Some testing tips: > - Create 3.x master and replica > - Upgrade master RPMs with these patches > - to add old permissions, run ipa-ldap-updater on the replica > - to simulate an upgrade, run ipa-ldap-updater on the master > - to delete a managed permission: > $ curl -v -H Content-Type:application/json -H Accept:applicaton/json > --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -X POST -H > referer:https://`hostname`/ipa/json -d '{"method": "permission_del", > "params":[["$PERMISSION_NAME"],{"force":true}], "id":0 }' > https://`hostname`/ipa/json > - be careful where you run permission-mod; on 4.0 it will convert the > permission to V2 In my tests, the upgrade from 3.x worked as expected so that went well. What I still miss is a removal of ipapermdefaultattr in Add ACI in 553.3. As we mentioned earlier, it is a NOOP and rather confuses people instead of improving anything. Besides that, I did not spot any pending error. Martin From tbordaz at redhat.com Wed Jun 4 08:43:40 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 04 Jun 2014 10:43:40 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C39F6.2080006@redhat.com> References: <538C39F6.2080006@redhat.com> Message-ID: <538EDC3C.1070301@redhat.com> On 06/02/2014 10:46 AM, Ludwig Krispenz wrote: > Ticket 4302 is a request for an enhancement: Move replication topology > to the shared tree > > > There has been some discussion in comments in the ticket, but I'd like > to open the discussion to a wider audience to get an agreement on what > should be implemented, before writing a design spec. > > The implementation requires a new IPA plugin for 389 DS and eventually > an enhancement of the 389 replication plugin (which depends on some > decisions below). In the following I will use the terms ?topology > plugin? for the new plugin and ?replication plugin? for the existing > 389 multimaster replication plugin. > > > Lets start with the requirements: What should be achieved by this RFE ? > > In my opinion there are three different levels of features to > implement with this request > > - providing all replication configuration information consistent > across all deployed servers on all servers, eg to easily visualize the > replication topology. > > - Allowing to do sanity checks on replication configuration, denying > modifications which would break replication topology or issue warnings. > > - Use the information in the shared tree to trigger changes to the > replication configuration in the corresponding servers, this means to > allow to completely control replication configuration with > modifications of entries in the shared tree > > > The main questions are > > 1] which information is needed in the shared tree (eg what params in > the repl config should be modifiable) > > 2] how is the information organized and stored (layout of the repl > config information shared tree) > > 3] how is the interaction of the info in the shared tree and > configuration in cn=config and the interaction between the topology > plugin and the replication plugin > > > ad 1] to verify the topology, eg connectivity info about all existing > replication agreements is needed, the replication agreements only > contain info about the target, and the parameters for connection to > the target, but not about the origin. If the data have to evaluated on > any server, information about the origin has to be added, eg > replicaID, serverID,... > > In addition, if agreement config has to be changed based on the shared > tree all required parameters need to be present, eg > replicatedAttributeList, strippedAttrs, replicationEnabled, ..... > > Replication agreements only provide information on connections where > replication is configured, if connectivity is to be checked > independent info about all deployed serevers/replicas is needed. > > If topology should be validated, do we need params definig > requirements, eg each replica to be connected to 1,2,3,... others, > type of topology (ring, mesh, star,.) ? > > > ad 2] the data required are available in the replicationAgreement (and > eventually replica) entries, but the question is if there should be a > 1:1 relationship to entries in the shared tree or a condensed > representation, if there should be a server or connection oriented view. > > In my opinion a 1:1 relation is straight forward, easy to handle and > easy to extend (not the full data of a repl agreement need to be > present, other attributes are possible). The downside may be a larger > number of entries, but this is no problem for the directory server and > replication and the utilities eg to visualize a topology will handle > this. > > If the number of entries should be reduced information on multiple > replication agreements would have to be stored in one entry, and the > problem arises ho to group data belonging to one agreement. LDAP does > not provide a simple way to group attribute values in one entry, so > all the info related to one agreement (origin, target, replicated > attrs and other repl configuration info) could be stored in a single > attribute, which will make the attribute as nicely readable and > managable as acis. > > If topology verification and connectivity check is an integral part of > the feature, I think a connection oriented view is not sufficient, it > might be incomplete, so a server view is required, the server entry > would then have the connection information as subentries or as > attributes. > > > Ad 3] The replication configuration is stored under cn=config and can > be modified either by ldap operations or by editing the dse.ldif. With > the topology plugin another source of configuration changes comes into > play. > > The first question is: which information has precendence ? I think if > there is info in the shared tree it should be used, and the > information in cn=config should be updated. This also means that the > topology plugin needs to intercept all mods to the entries in > cn=config and have them ignored and handle all updates to the shared > tree and trigger changes to the cn=config entries, which then would > trigger rebuilds of the in memory replication objects. > > Next question: How to handle changes directly done in the dse.ldif, if > everything should be done by the topology plugin it would have to > verify and compare the info in cn=config and in the shared tree at > every startup of the directory server, which might be complicated by > the fact that the replication plugin might already be started and repl > agreemnts are active before the topology plugin is started and could > do its work. (plugin starting order and dependencies need to be checked). > > Next next question: should there be a ?bootstrapping? of the config > information in the shared tree ? > > I think yes, the topology plugin could check at startup if there is a > representation of the config info in the shared tree and if not > construct it, so after deployment and enabling of the topology plugin > the information in the shared tree would be initialized. > > > I think that not every part of the feature has to be handled in the > topology plugin, we could also ask for enhancements in the 389 > replication plugin itself. There could be an extension to the replica > and replication agreement entries to reference an entry in the shared > tree. The replication plugin could check at startup if these entries > contain replication configuration attributes and if so use them, > otherwise use the values in cn=config. The presence of the reference > indicates to the topolgy plugin that initialization is done. > > In my opinion this would simplify the coordination at startup and > avoid unnecessary revaluations and other deployments could benefit > from this new feature in directory server (one could eg have one entry > for replication argreements containing the fractional replication > configuration ? and it would be identical on all servers) > > > So my proposal would contain the following components > > 1] Store replication configuration in the shared tree in a combination > of server and connection view (think we need both) and map replication > configuration to these entries. I would prefer a direct mapping (with > a subset of the cn=config attributes and required additions) About adding a new server in the replication topology. If it was initialized, it may register itself into the shared tree and then join the topology. If it was not initialized, it can be initialized online by one of the master. Will it be triggered with an update to the shared tree ? > > 2] provide a topology plugin to do consistency checks and topology > verification, handle updates to trigger modification changes in > cn=config, intercept and reject direct mods to cn=config entries At > startup verify if shared tree opbjects are present, initialize them if > not, apply to cn=config if required > > 3] enhance replication plugin to handle config information in the > shared tree. This would allow to consistently handle config changes > either applied to the shared config, cn=config mods or des.ldif > changes. This feature might also be interesting to other DS deployments > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Wed Jun 4 08:43:51 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Jun 2014 10:43:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <538ED59E.9050305@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <5385F487.908@redhat.com> <538DC26C.4040106@redhat.com> <538ED59E.9050305@redhat.com> Message-ID: <538EDC47.1040709@redhat.com> On 06/04/2014 10:15 AM, Martin Kosek wrote: > On 06/03/2014 02:41 PM, Petr Viktorin wrote: >> On 05/28/2014 04:36 PM, Petr Viktorin wrote: >>> On 05/28/2014 04:27 PM, Petr Viktorin wrote: >>>> On 05/27/2014 04:20 PM, Martin Kosek wrote: >>>>> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>>>>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> Here I start upgrading the existing default permissions to the new >>>>>>> Managed style. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4346 >>>>>>> >>>>>>> The patches rely on my patch 0551 >>>>>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>>>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>>>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>>>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The operation is now described at >>>>>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> If there user has modified an old default permission, a warning is >>>>>>> logged the replacement permission is not added/updated. The user needs >>>>>>> to evaluate the situation: either update the old permission to match >>>>>>> the >>>>>>> original default, or remove the old permission, and then run >>>>>>> ipa-ldap-updater will create the new one. >>>>>>> Is bailing out the right thing to do if the old entry was modified? >>>>> >>>>> Forcing user to remove old permission and create new one seems as a >>>>> too much >>>>> work to me. After the upgrade, we need to be sure that the managed >>>>> permissions >>>>> is there. >>>> >>>> Note that this only happens if the user changed the permissions, so we >>>> need to be extra careful to respect their wishes. >>>> >>>>> What is the problem of having both 2 permissions in the DS? The old >>>>> modified >>>>> permission and the new system managed one? As we are dealing with allow >>>>> permissions, having 2 of them should be harmless. >>>> >>>> The new one could be granting too much access, the admin might have >>>> wanted to restrict the defaults. >>>> >>>> >>>>>>> It could be possible to parse the permission, figure out the changes >>>>>>> the >>>>>>> user made, and apply them to the new one, but that seems like too much >>>>>>> guesswork to me. >>>>> >>>>> Maybe we could do the same we do with managed permissions upgrades? >>>>> Only allow >>>>> differences in the list of attributes? I am thinking that people could >>>>> hotfix >>>>> missing attributes at permissions themselves (like adding description to >>>>> sudorule permission), this would lead to duplicate permissions later. >>>>> >>>>> What we could do when old ACI differs only in allowed attributes is to >>>>> compare >>>>> it to defaults and set whitelist and blacklist attributes of the new >>>>> managed >>>>> permission. Then we can safely delete the old ACI (with warning). >>>>> >>>>> If you think this is too much work, we can keep the old behavior and >>>>> just add >>>>> duplicate ACI. >>>> >>>> Having duplicate permissions would be possible, after all they have a >>>> different name. However I'd expect that most people would still want to >>>> delete the old ones, rather than letting them hide among user-defined >>>> permissions. >>>> >>>>>>> On the other hand, my approach has a downside as well: if the >>>>>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', >>>>>>> there's >>>>>>> now no way to upgrade while allowing access but keeping that attribute >>>>>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>>>>> this? It might be worth it to create a special tool that upgrades a >>>>>>> single permission and allows setting the excluded/included attributes >>>>>>> explicitly. >>>>> >>>>> This problem would be removed with my approach proposed above. >>>>> >>>>>>> There are some interesting scenarios to think about with respect to >>>>>>> upgrades and user changes: >>>>>>> >>>>>>> * Upgrade to old version, e.g. >>>>>>> - have IPA 3.2 master, IPA 3.2 replica >>>>>>> - upgrade master to 4.0 (old permissions are updated) >>>>>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>>>>> >>>>>>> This is AFAIK not supported but it does happen. >>>>>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>>>>> always add the old permissions, but with this patch, a subsequent >>>>>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the >>>>>>> old >>>>>>> permissions again. >>>>> >>>>> Hm, I think this is the best option we have. We should warn about this >>>>> behavior >>>>> in our release notes though. >>>>> >>>>>>> Tied to that is another scenario: >>>>>>> >>>>>>> * Re-create permissions with old names >>>>>>> - have IPA 4.0 master >>>>>>> - Create a permission named 'Modify Sudo rule' >>>>>>> - Upgrade to IPA 4.1 >>>>>>> >>>>>>> Here we need to make sure the new permission is *not* removed, >>>>>>> because a >>>>>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>>>>> ensure this the updater only removes old-style permissions. >>>>> >>>>> Right, we can decide based on objectclasses - whether permissionsv2 OC >>>>> is there >>>>> or not. >>>>> >>>>>>> >>>>>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>>>>> that an old permission named 'Modify Sudo rule' is added on the old >>>>>>> server. Any update to 4.0+ will remove that. >>>>>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>>>>> anyway, so users should expect this. We should still point it out in >>>>>>> the >>>>>>> docs though, since I expect some users to start messing with the >>>>>>> permissions before upgrading all of the infrastructure to 4.0. >>>>> >>>>> +1, I would just point out that behavior in the release notes. >>>>> >>>>>>> The second patch upgrades sudorule permissions, this server as an >>>>>>> example of how the will work. >>>>>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>>>>> >>>>>> The user read permissions patches had a conflict with these; >>>>>> attaching rebased >>>>>> version. >>>>> >>>>> Now the actual review >>>>> 552.2: worked fine for me. Some updates will probably be needed >>>>> though, based >>>>> on the discussion above. >>>>> >>>>> 553.2: >>>>> >>>>> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >>>>> Looks >>>>> like a noop to me, it was also never part of our add ACIs. >>>> >>>> Simo, I hazily remember discussing that we should only allow specific >>>> attributes on add, otherwise users can add entries with any extra >>>> objectclasses and attributes. Did we come to a conclusion? >>>> I might have confused targetattr with targetattrfilter in my notes; >>>> since I see targetarr is ineffective. >>> >>> OK, this was just me confused. As Ludwig told me, >>>> for adding an entry you need add rights for the entry and write rights >>>> for each attribute, so in the add aci the targetattrs are irrelevant. >>> so I'll remove them from the add ACI. >>> >>>>> I tried to strip that down to just "description" and I was still able >>>>> to add a >>>>> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >>>>> it?) >>>>> targetattr part of add ACI? >>>>> >>>>> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >>>>> ineffective. >>>>> Privileged user still cannot update all SUDO rule attributes. >>>> >>>> Duh. I've been staring at this too long. >>>> >>>>> Besides that, the ACIs were working fine. >> >> The attached version looks at the old permission in LDAP and if it differs from >> the old default only in the targetattrs, it transplants the difference to the >> new managed permission. >> >> There is a lot of logging here so if something didn't work the way you >> expected, at least you'll know what happened. >> >> When there were multiple defaults, i.e. IPA added/removed some attributes in >> some version: the new managed permission's attributes will be applied, so >> upgrades from both very old and not-so-old versions should "do the right thing". >> >> If the old permission differs in something else than targetattrs, an error is >> logged (this will show up in yum update output), and as before the new managed >> permission is not created. The user now has 3 options to fix this: >> - Delete the old permission, then run ipa-ldap-updater to create the new default. > > This will probably be the safest route to go for users. > >> - Modify the old permission on an *old* system to match the old default, >> possibly with targetattr changes, then run a *new* ipa-ldap-updater to convert >> that to the new default >> - Modify the old permission on a *new* system, which changes it to a V2 >> permission, then run ipa-ldap-updater to create the new default, ending up with >> both permissions. >> >> The distinction betwen the last two is subtle and error-prone, but >> 1) I don't see a better way, considering that future upgrades need to work well >> (in IPA 4.0+ a user-created permission named "Add Sudo Rule" has no special >> status) >> 2) I'm hoping that people didn't modify the old default permissions that much; >> if they did they should have felt some pain already -- I don't think the update >> system in 3.x would handle such changes wery well > > I would personally still be more forceful, especially given the arguments you > gave in 2) and just log the old too-modified ACI and convert it to the new > style, but there are not many followers to this opinion though... On the other hand, if someone did this kind of thing they probably (thought they) knew what they were doing, so they deserve a chance for manual intervention. >> Apply my patch 0565 before trying these out. >> >> >> Some testing tips: >> - Create 3.x master and replica >> - Upgrade master RPMs with these patches >> - to add old permissions, run ipa-ldap-updater on the replica >> - to simulate an upgrade, run ipa-ldap-updater on the master >> - to delete a managed permission: >> $ curl -v -H Content-Type:application/json -H Accept:applicaton/json >> --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -X POST -H >> referer:https://`hostname`/ipa/json -d '{"method": "permission_del", >> "params":[["$PERMISSION_NAME"],{"force":true}], "id":0 }' >> https://`hostname`/ipa/json >> - be careful where you run permission-mod; on 4.0 it will convert the >> permission to V2 > > In my tests, the upgrade from 3.x worked as expected so that went well. What I > still miss is a removal of ipapermdefaultattr in Add ACI in 553.3. As we > mentioned earlier, it is a NOOP and rather confuses people instead of improving > anything. Besides that, I did not spot any pending error. Ah, sorry, I rebased on the wrong patch. Here is the fixed version. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0552.4-Add-mechanism-for-updating-permissions-to-managed.patch Type: text/x-patch Size: 9320 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0553.4-Convert-Sudo-rule-default-permissions-to-managed.patch Type: text/x-patch Size: 6048 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0554.4-Add-missing-attributes-to-Modify-Sudo-rule-permissio.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 4 09:42:49 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 04 Jun 2014 11:42:49 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring Message-ID: <538EEA19.2000208@redhat.com> Hi, the following set of patches implements the ticket: https://fedorahosted.org/freeipa/ticket/4052 The refactoring touches both server and client bits, main features are: * easier inheritance and creation of new platform modules * all filesystem paths are defined as platform constants * platform related functionality is implemented as transparent platform tasks (as opposed to platform dependent implementations) * no need to implement your own authconfig class, since tasks encapsulate the relevant parts of the code More documentation, mainly on the part of the documenting the tasks contracts and the creation of own platform modules should follow later. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0202-ipaplatform-Create-separate-module-for-platform-file.patch Type: text/x-patch Size: 6513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0203-ipaplatform-Move-service-base-platfrom-related-funct.patch Type: text/x-patch Size: 33000 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0204-ipaplatform-Move-default-implementations-of-tasks-fr.patch Type: text/x-patch Size: 3325 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0205-ipaplatform-Create-default-implementations-for-tasks.patch Type: text/x-patch Size: 870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0206-ipaplatform-Add-base-fedora-platform-module.patch Type: text/x-patch Size: 5314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0207-ipaplatform-Moved-Fedora-16-service-implementations-.patch Type: text/x-patch Size: 19289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0208-ipaplatform-Move-restore_context-and-check_selinux_s.patch Type: text/x-patch Size: 5180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0209-ipaplatform-Do-not-require-custom-Authconfig-impleme.patch Type: text/x-patch Size: 18777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0210-ipaplatform-Remove-legacy-redhat-platform-module.patch Type: text/x-patch Size: 12402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0211-ipaplatform-Move-Fedora-specific-implementations-of-.patch Type: text/x-patch Size: 12470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0212-ipaplatform-Change-platform-dependant-code-in-freeip.patch Type: text/x-patch Size: 18009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0213-ipaplatform-Change-service-code-in-freeipa-to-use-ip.patch Type: text/x-patch Size: 45692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0214-ipaplatform-Change-paths-dependant-on-ipaservices-to.patch Type: text/x-patch Size: 3638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0215-ipaplatform-Remove-redundant-imports-of-ipaservices.patch Type: text/x-patch Size: 14095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0216-ipaplatform-Move-all-filesystem-paths-to-ipaplatform.patch Type: text/x-patch Size: 158027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0217-ipaplatform-Remove-remnants-of-the-ipapython-platfor.patch Type: text/x-patch Size: 16160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0218-ipaplatform-Change-makefiles-to-accomodate-for-new-p.patch Type: text/x-patch Size: 9082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0219-ipaplatform-Let-fedora-path-module-use-PathNamespace.patch Type: text/x-patch Size: 889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0220-ipaplatform-Link-to-platform-module-during-build-tim.patch Type: text/x-patch Size: 1542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0221-ipaplatform-Pylint-fixes.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0222-ipaplatform-Contain-all-the-tasks-in-the-TaskNamespa.patch Type: text/x-patch Size: 31072 bytes Desc: not available URL: From pspacek at redhat.com Wed Jun 4 11:14:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Jun 2014 13:14:17 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538ED102.6090300@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <538ECCCF.6000005@redhat.com> <538ED102.6090300@redhat.com> Message-ID: <538EFF89.4000803@redhat.com> On 4.6.2014 09:55, Petr Vobornik wrote: > On 4.6.2014 09:37, Petr Spacek wrote: >> On 4.6.2014 08:44, Martin Kosek wrote: >>> On 06/04/2014 08:34 AM, Martin Kosek wrote: >>> ... >> >> This is really good proposal! Scroll down to see three nit picks: >> >>>> Users >>>> - Users >>>> - Groups >>>> - SUDO >>>> >>>> Hosts >>>> - Hosts >>>> - Host groups >>>> - Services >>>> - Netgroups >>>> - Automount >>>> >>>> Authentication >>>> - OTP Tokens >>>> - Password Policy >>>> - Kerberos Ticket Policy >>>> >>>> Policy >>>> - HBAC >>>> - SELinux User Maps >>>> - Automember >>> >>> Alternatively, we could rename Policy to "Authorization" as both HBAC and >>> SELinux is about authorizing what an authenticated user can do. We >>> would just >>> need to move Automember to different place, though this one is >>> difficult - it >>> relates both to Users and Hosts, just like Netgroup. >>> >>>> >>>> Trusts >>>> - Trust configuration >>>> - Trusts >>>> - (future) Views >>>> >>>> Infrastructure >>>> - Certificates >> ^^^ I would like to see this under "Authentication". Nowaways it is used >> to authenticate machines and it will be extended to user authentication >> as soon as Smart Card support is added. >> >>>> - DNS >>>> - (future) Replication topology >> ^^^ Personally, I would place it under "IPA Configuration". >> >>>> - (future) Vault >> ^^^ Why is Vault under "Infrastructure"? It sounds like "Authentication" >> to me. It is meant to store plain-text passwords etc., no? >> >> >> It seems that I'm proposing to reduce "Infrastructure" to "DNS". We can >> move DNS somewhere or make DNS top-level item until we get DHCP or >> something similar. > > I would rather avoid having a temporary top-level item. Temporary ~ years in this case. Is it good enough? :-) I personally don't like categories with one item in them, it seems ridiculous. Look at "Time" menu in OrangeHRM :-) You have to go through it just to click to the only option inside. Ridiculous. >> This also opens the question if DNS management is really the right >> business for us :-) I'm personally not sure :-) >> >> >>>> Configuration >> ^^^ Can it be "IPA configuration" or something like that? Just >> "Configuration" seems too vague to me. After all, everything in the UI >> is some kind of configuration :-) > > We can leave the old "IPA Server" name. I agree that "Replication topology" > could be here because it configures the tool and not the data, similar to > other items under this category. But I think that many users would try to find > it in infrastructure. My point is that distinction between "Infrastructure" and "IPA server" or it's configuration is really vague. I'm worried that people (or at least I) will always look in the "wrong" category first which makes me unhappy. >>>> - Global >>>> - Access Control (RBAC) BTW can we clarify somehow that this applies purely to IPA? Maybe "IPA Server" category will make it clear enough... >>>> - Realm Domains >>>> - ID Ranges -- Petr^2 Spacek From pviktori at redhat.com Wed Jun 4 11:36:08 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Jun 2014 13:36:08 +0200 Subject: [Freeipa-devel] [PATCH] 0567 test_permission_plugin: limit results in targetfilter find test Message-ID: <538F04A8.2060207@redhat.com> A test fix. Pushed as one-liner to master: 3974c75053c165f7f9bc931fbd9925f16d1a07bb -- Petr? The IPA test suite goes green! -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0567-test_permission_plugin-limit-results-in-targetfilter.patch Type: text/x-patch Size: 1208 bytes Desc: not available URL: From lkrispen at redhat.com Wed Jun 4 11:46:44 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 04 Jun 2014 13:46:44 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538EDC3C.1070301@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> Message-ID: <538F0724.2020600@redhat.com> On 06/04/2014 10:43 AM, thierry bordaz wrote: > >> >> So my proposal would contain the following components >> >> 1] Store replication configuration in the shared tree in a >> combination of server and connection view (think we need both) and >> map replication configuration to these entries. I would prefer a >> direct mapping (with a subset of the cn=config attributes and >> required additions) > > About adding a new server in the replication topology. > If it was initialized, it may register itself into the shared tree and > then join the topology. If it was not initialized, it can be > initialized online by one of the master. Will it be triggered with an > update to the shared tree ? I think this has to be decided, I proposed some kind of bootstrapping: If the topology plugin is enabled and started it would check if there is already info on the connections for this server and if not create/update the entry in the shared tree, this could also happen if a new server is added. But Simo wanted to have the info in the shared tree indepndent of what was already configured. One problem with the automatic approach is what should be done if the config differs on the already deployed servers From lkrispen at redhat.com Wed Jun 4 11:50:41 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 04 Jun 2014 13:50:41 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401811179.6551.35.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> <538DBC76.4080102@redhat.com> <1401800027.6551.32.camel@willson.usersys.redhat.com> <538DD1F2.9050904@redhat.com> <1401811179.6551.35.camel@willson.usersys.redhat.com> Message-ID: <538F0811.4080400@redhat.com> On 06/03/2014 05:59 PM, Simo Sorce wrote: > On Tue, 2014-06-03 at 15:47 +0200, Ludwig Krispenz wrote: >> On 06/03/2014 02:53 PM, Simo Sorce wrote: >>> On Tue, 2014-06-03 at 14:15 +0200, Ludwig Krispenz wrote: >>>> Hi Simo, >>>> >>>> just for clarification. The plan is to move the repl config into the >>>> shared tree for the main database and eventually for others like >>>> o=ipaca. Should the topology info live in cn=etc for all databases or >>>> each in the database it configures ? >>>> If the main database is always replicated I think all topology info >>>> should be concentrated in cn=etc. >>> This is actually a good question, I think we want to keep it in the main >>> database, but to be forward looking, we should set the basedn of the >>> configuration (per topology) in the topology plugin configuration entry, >>> this way if it turns out we should move it in their own dbs we can just >>> do it. >> yes, this can be handle in the topology plugin configuration, we need to >> define which databases should be controlled and where the root for the >> replicated topology information is. >> I assume we want only one plugin instance. >>> The other issue is the list of masters though. I do not want to move >>> them in the topology tree (breaks compatibility) nor duplicate those >>> entries if possible, but we may need to do it or also configure where >>> the "nodes" are stored. >> Agreed. What about non-masters, in the ticket there was also discussion >> about read only replicas - to be delayed ? > TBD, from the pov of the plugin we care only about Nodes and links, but > yeah dealing with R/O replicas will mean the plugin should understand > such servers need a segment that sends data to them but do not need a > segment that carries data out. my question was more where the r/o replicas would be listed. In cn=ro-replicas parallel to cn=matsters, or should all servers be in cn=masters and have a replication role defined ? > > Working on the topology consistency checker will be fun :-) > > Simo. > From simo at redhat.com Wed Jun 4 13:06:27 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 09:06:27 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538F0811.4080400@redhat.com> References: <538C39F6.2080006@redhat.com> <1401713964.6654.29.camel@willson.usersys.redhat.com> <538C856E.8040905@redhat.com> <1401719880.1318.15.camel@willson.usersys.redhat.com> <538DBC76.4080102@redhat.com> <1401800027.6551.32.camel@willson.usersys.redhat.com> <538DD1F2.9050904@redhat.com> <1401811179.6551.35.camel@willson.usersys.redhat.com> <538F0811.4080400@redhat.com> Message-ID: <1401887187.24826.4.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 13:50 +0200, Ludwig Krispenz wrote: > my question was more where the r/o replicas would be listed. In > cn=ro-replicas parallel to cn=matsters, > or should all servers be in cn=masters and have a replication role defined ? We do not know yet as we do not have read-only replicas at all. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Jun 4 15:23:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Jun 2014 17:23:02 +0200 Subject: [Freeipa-devel] [PATCH 0260] Add wrappers for isc_task_*exclusive() Message-ID: <538F39D6.3080308@redhat.com> Hello, Add wrappers for isc_task_*exclusive(). This patch replaces scattered isc_task_* calls and associated locking to one place. It helps with debugging sometimes. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0260-Add-wrappers-for-isc_task_-exclusive.patch Type: text/x-patch Size: 10551 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 4 15:23:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 17:23:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <538EDC47.1040709@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <5385F487.908@redhat.com> <538DC26C.4040106@redhat.com> <538ED59E.9050305@redhat.com> <538EDC47.1040709@redhat.com> Message-ID: <538F3A07.1080002@redhat.com> On 06/04/2014 10:43 AM, Petr Viktorin wrote: > On 06/04/2014 10:15 AM, Martin Kosek wrote: >> On 06/03/2014 02:41 PM, Petr Viktorin wrote: >>> On 05/28/2014 04:36 PM, Petr Viktorin wrote: >>>> On 05/28/2014 04:27 PM, Petr Viktorin wrote: >>>>> On 05/27/2014 04:20 PM, Martin Kosek wrote: >>>>>> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>>>>>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> Here I start upgrading the existing default permissions to the new >>>>>>>> Managed style. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4346 >>>>>>>> >>>>>>>> The patches rely on my patch 0551 >>>>>>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>>>>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>>>>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>>>>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The operation is now described at >>>>>>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If there user has modified an old default permission, a warning is >>>>>>>> logged the replacement permission is not added/updated. The user needs >>>>>>>> to evaluate the situation: either update the old permission to match >>>>>>>> the >>>>>>>> original default, or remove the old permission, and then run >>>>>>>> ipa-ldap-updater will create the new one. >>>>>>>> Is bailing out the right thing to do if the old entry was modified? >>>>>> >>>>>> Forcing user to remove old permission and create new one seems as a >>>>>> too much >>>>>> work to me. After the upgrade, we need to be sure that the managed >>>>>> permissions >>>>>> is there. >>>>> >>>>> Note that this only happens if the user changed the permissions, so we >>>>> need to be extra careful to respect their wishes. >>>>> >>>>>> What is the problem of having both 2 permissions in the DS? The old >>>>>> modified >>>>>> permission and the new system managed one? As we are dealing with allow >>>>>> permissions, having 2 of them should be harmless. >>>>> >>>>> The new one could be granting too much access, the admin might have >>>>> wanted to restrict the defaults. >>>>> >>>>> >>>>>>>> It could be possible to parse the permission, figure out the changes >>>>>>>> the >>>>>>>> user made, and apply them to the new one, but that seems like too much >>>>>>>> guesswork to me. >>>>>> >>>>>> Maybe we could do the same we do with managed permissions upgrades? >>>>>> Only allow >>>>>> differences in the list of attributes? I am thinking that people could >>>>>> hotfix >>>>>> missing attributes at permissions themselves (like adding description to >>>>>> sudorule permission), this would lead to duplicate permissions later. >>>>>> >>>>>> What we could do when old ACI differs only in allowed attributes is to >>>>>> compare >>>>>> it to defaults and set whitelist and blacklist attributes of the new >>>>>> managed >>>>>> permission. Then we can safely delete the old ACI (with warning). >>>>>> >>>>>> If you think this is too much work, we can keep the old behavior and >>>>>> just add >>>>>> duplicate ACI. >>>>> >>>>> Having duplicate permissions would be possible, after all they have a >>>>> different name. However I'd expect that most people would still want to >>>>> delete the old ones, rather than letting them hide among user-defined >>>>> permissions. >>>>> >>>>>>>> On the other hand, my approach has a downside as well: if the >>>>>>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', >>>>>>>> there's >>>>>>>> now no way to upgrade while allowing access but keeping that attribute >>>>>>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>>>>>> this? It might be worth it to create a special tool that upgrades a >>>>>>>> single permission and allows setting the excluded/included attributes >>>>>>>> explicitly. >>>>>> >>>>>> This problem would be removed with my approach proposed above. >>>>>> >>>>>>>> There are some interesting scenarios to think about with respect to >>>>>>>> upgrades and user changes: >>>>>>>> >>>>>>>> * Upgrade to old version, e.g. >>>>>>>> - have IPA 3.2 master, IPA 3.2 replica >>>>>>>> - upgrade master to 4.0 (old permissions are updated) >>>>>>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>>>>>> >>>>>>>> This is AFAIK not supported but it does happen. >>>>>>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>>>>>> always add the old permissions, but with this patch, a subsequent >>>>>>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the >>>>>>>> old >>>>>>>> permissions again. >>>>>> >>>>>> Hm, I think this is the best option we have. We should warn about this >>>>>> behavior >>>>>> in our release notes though. >>>>>> >>>>>>>> Tied to that is another scenario: >>>>>>>> >>>>>>>> * Re-create permissions with old names >>>>>>>> - have IPA 4.0 master >>>>>>>> - Create a permission named 'Modify Sudo rule' >>>>>>>> - Upgrade to IPA 4.1 >>>>>>>> >>>>>>>> Here we need to make sure the new permission is *not* removed, >>>>>>>> because a >>>>>>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>>>>>> ensure this the updater only removes old-style permissions. >>>>>> >>>>>> Right, we can decide based on objectclasses - whether permissionsv2 OC >>>>>> is there >>>>>> or not. >>>>>> >>>>>>>> >>>>>>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>>>>>> that an old permission named 'Modify Sudo rule' is added on the old >>>>>>>> server. Any update to 4.0+ will remove that. >>>>>>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>>>>>> anyway, so users should expect this. We should still point it out in >>>>>>>> the >>>>>>>> docs though, since I expect some users to start messing with the >>>>>>>> permissions before upgrading all of the infrastructure to 4.0. >>>>>> >>>>>> +1, I would just point out that behavior in the release notes. >>>>>> >>>>>>>> The second patch upgrades sudorule permissions, this server as an >>>>>>>> example of how the will work. >>>>>>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>>>>>> >>>>>>> The user read permissions patches had a conflict with these; >>>>>>> attaching rebased >>>>>>> version. >>>>>> >>>>>> Now the actual review >>>>>> 552.2: worked fine for me. Some updates will probably be needed >>>>>> though, based >>>>>> on the discussion above. >>>>>> >>>>>> 553.2: >>>>>> >>>>>> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >>>>>> Looks >>>>>> like a noop to me, it was also never part of our add ACIs. >>>>> >>>>> Simo, I hazily remember discussing that we should only allow specific >>>>> attributes on add, otherwise users can add entries with any extra >>>>> objectclasses and attributes. Did we come to a conclusion? >>>>> I might have confused targetattr with targetattrfilter in my notes; >>>>> since I see targetarr is ineffective. >>>> >>>> OK, this was just me confused. As Ludwig told me, >>>>> for adding an entry you need add rights for the entry and write rights >>>>> for each attribute, so in the add aci the targetattrs are irrelevant. >>>> so I'll remove them from the add ACI. >>>> >>>>>> I tried to strip that down to just "description" and I was still able >>>>>> to add a >>>>>> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >>>>>> it?) >>>>>> targetattr part of add ACI? >>>>>> >>>>>> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >>>>>> ineffective. >>>>>> Privileged user still cannot update all SUDO rule attributes. >>>>> >>>>> Duh. I've been staring at this too long. >>>>> >>>>>> Besides that, the ACIs were working fine. >>> >>> The attached version looks at the old permission in LDAP and if it differs from >>> the old default only in the targetattrs, it transplants the difference to the >>> new managed permission. >>> >>> There is a lot of logging here so if something didn't work the way you >>> expected, at least you'll know what happened. >>> >>> When there were multiple defaults, i.e. IPA added/removed some attributes in >>> some version: the new managed permission's attributes will be applied, so >>> upgrades from both very old and not-so-old versions should "do the right >>> thing". >>> >>> If the old permission differs in something else than targetattrs, an error is >>> logged (this will show up in yum update output), and as before the new managed >>> permission is not created. The user now has 3 options to fix this: >>> - Delete the old permission, then run ipa-ldap-updater to create the new >>> default. >> >> This will probably be the safest route to go for users. >> >>> - Modify the old permission on an *old* system to match the old default, >>> possibly with targetattr changes, then run a *new* ipa-ldap-updater to convert >>> that to the new default >>> - Modify the old permission on a *new* system, which changes it to a V2 >>> permission, then run ipa-ldap-updater to create the new default, ending up with >>> both permissions. >>> >>> The distinction betwen the last two is subtle and error-prone, but >>> 1) I don't see a better way, considering that future upgrades need to work well >>> (in IPA 4.0+ a user-created permission named "Add Sudo Rule" has no special >>> status) >>> 2) I'm hoping that people didn't modify the old default permissions that much; >>> if they did they should have felt some pain already -- I don't think the update >>> system in 3.x would handle such changes wery well >> >> I would personally still be more forceful, especially given the arguments you >> gave in 2) and just log the old too-modified ACI and convert it to the new >> style, but there are not many followers to this opinion though... > > On the other hand, if someone did this kind of thing they probably (thought > they) knew what they were doing, so they deserve a chance for manual intervention. Ok, fair enough. I found permission-del & "ipa-ldap-update --upgrade" as the easiest way to restore such permission. We should add similar hint later to release notes. > >>> Apply my patch 0565 before trying these out. >>> >>> >>> Some testing tips: >>> - Create 3.x master and replica >>> - Upgrade master RPMs with these patches >>> - to add old permissions, run ipa-ldap-updater on the replica >>> - to simulate an upgrade, run ipa-ldap-updater on the master >>> - to delete a managed permission: >>> $ curl -v -H Content-Type:application/json -H Accept:applicaton/json >>> --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -X POST -H >>> referer:https://`hostname`/ipa/json -d '{"method": "permission_del", >>> "params":[["$PERMISSION_NAME"],{"force":true}], "id":0 }' >>> https://`hostname`/ipa/json >>> - be careful where you run permission-mod; on 4.0 it will convert the >>> permission to V2 >> >> In my tests, the upgrade from 3.x worked as expected so that went well. What I >> still miss is a removal of ipapermdefaultattr in Add ACI in 553.3. As we >> mentioned earlier, it is a NOOP and rather confuses people instead of improving >> anything. Besides that, I did not spot any pending error. > > Ah, sorry, I rebased on the wrong patch. > Here is the fixed version. This one works fine, so ACK from me. Martin From pspacek at redhat.com Wed Jun 4 15:34:29 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Jun 2014 17:34:29 +0200 Subject: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for secure zones In-Reply-To: <538D8CF8.6040008@redhat.com> References: <538D8CF8.6040008@redhat.com> Message-ID: <538F3C85.20507@redhat.com> On 3.6.2014 10:53, Petr Spacek wrote: > Hello, > > Fix run-time zone addition for secure zones. Here comes fix for the fix ... We really need a test-suite for bind-dyndb-ldap. > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0258-2-Fix-run-time-zone-addition-for-secure-zones.patch Type: text/x-patch Size: 2135 bytes Desc: not available URL: From simo at redhat.com Wed Jun 4 15:35:26 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 11:35:26 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538EC03F.3060103@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> Message-ID: <1401896126.28354.2.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: > On 06/04/2014 08:34 AM, Martin Kosek wrote: > ... > > Users > > - Users > > - Groups > > - SUDO > > > > Hosts > > - Hosts > > - Host groups > > - Services > > - Netgroups > > - Automount > > > > Authentication > > - OTP Tokens > > - Password Policy > > - Kerberos Ticket Policy > > > > Policy > > - HBAC > > - SELinux User Maps > > - Automember > > Alternatively, we could rename Policy to "Authorization" as both HBAC and > SELinux is about authorizing what an authenticated user can do. We would just > need to move Automember to different place, though this one is difficult - it > relates both to Users and Hosts, just like Netgroup. I do not see the need to do Policy -> Authorization but Automember is in the wrong place imo. The first tab should be Users -> Accounts and include automember in it as automember is about groupings ? Actually I would merge the current Users and Hosts tabs into 'Accounts' (or maybe 'Identities' ?) and add Automember. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Jun 4 15:36:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Jun 2014 17:36:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions In-Reply-To: <538F3A07.1080002@redhat.com> References: <537DF6A6.7020001@redhat.com> <53835339.1040900@redhat.com> <53849F31.2050508@redhat.com> <5385F26A.1010402@redhat.com> <5385F487.908@redhat.com> <538DC26C.4040106@redhat.com> <538ED59E.9050305@redhat.com> <538EDC47.1040709@redhat.com> <538F3A07.1080002@redhat.com> Message-ID: <538F3D14.10700@redhat.com> On 06/04/2014 05:23 PM, Martin Kosek wrote: > On 06/04/2014 10:43 AM, Petr Viktorin wrote: >> On 06/04/2014 10:15 AM, Martin Kosek wrote: >>> On 06/03/2014 02:41 PM, Petr Viktorin wrote: >>>> On 05/28/2014 04:36 PM, Petr Viktorin wrote: >>>>> On 05/28/2014 04:27 PM, Petr Viktorin wrote: >>>>>> On 05/27/2014 04:20 PM, Martin Kosek wrote: >>>>>>> On 05/26/2014 04:44 PM, Petr Viktorin wrote: >>>>>>>> On 05/22/2014 03:07 PM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> Here I start upgrading the existing default permissions to the new >>>>>>>>> Managed style. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4346 >>>>>>>>> >>>>>>>>> The patches rely on my patch 0551 >>>>>>>>> (https://fedorahosted.org/freeipa/ticket/4349) >>>>>>>>> You may run into what seems to be a 389 bug. If you get a "Midair >>>>>>>>> Collision" (NO_SUCH_ATTRIBUTE) error, restart the DS and try running >>>>>>>>> ipa-ldap-updater again. I'm working with Ludwig on this one. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The operation is now described at >>>>>>>>> http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> If there user has modified an old default permission, a warning is >>>>>>>>> logged the replacement permission is not added/updated. The user needs >>>>>>>>> to evaluate the situation: either update the old permission to match >>>>>>>>> the >>>>>>>>> original default, or remove the old permission, and then run >>>>>>>>> ipa-ldap-updater will create the new one. >>>>>>>>> Is bailing out the right thing to do if the old entry was modified? >>>>>>> >>>>>>> Forcing user to remove old permission and create new one seems as a >>>>>>> too much >>>>>>> work to me. After the upgrade, we need to be sure that the managed >>>>>>> permissions >>>>>>> is there. >>>>>> >>>>>> Note that this only happens if the user changed the permissions, so we >>>>>> need to be extra careful to respect their wishes. >>>>>> >>>>>>> What is the problem of having both 2 permissions in the DS? The old >>>>>>> modified >>>>>>> permission and the new system managed one? As we are dealing with allow >>>>>>> permissions, having 2 of them should be harmless. >>>>>> >>>>>> The new one could be granting too much access, the admin might have >>>>>> wanted to restrict the defaults. >>>>>> >>>>>> >>>>>>>>> It could be possible to parse the permission, figure out the changes >>>>>>>>> the >>>>>>>>> user made, and apply them to the new one, but that seems like too much >>>>>>>>> guesswork to me. >>>>>>> >>>>>>> Maybe we could do the same we do with managed permissions upgrades? >>>>>>> Only allow >>>>>>> differences in the list of attributes? I am thinking that people could >>>>>>> hotfix >>>>>>> missing attributes at permissions themselves (like adding description to >>>>>>> sudorule permission), this would lead to duplicate permissions later. >>>>>>> >>>>>>> What we could do when old ACI differs only in allowed attributes is to >>>>>>> compare >>>>>>> it to defaults and set whitelist and blacklist attributes of the new >>>>>>> managed >>>>>>> permission. Then we can safely delete the old ACI (with warning). >>>>>>> >>>>>>> If you think this is too much work, we can keep the old behavior and >>>>>>> just add >>>>>>> duplicate ACI. >>>>>> >>>>>> Having duplicate permissions would be possible, after all they have a >>>>>> different name. However I'd expect that most people would still want to >>>>>> delete the old ones, rather than letting them hide among user-defined >>>>>> permissions. >>>>>> >>>>>>>>> On the other hand, my approach has a downside as well: if the >>>>>>>>> 'memberallowcmd' attribute was removed from 'Modify Sudo rule', >>>>>>>>> there's >>>>>>>>> now no way to upgrade while allowing access but keeping that attribute >>>>>>>>> off-limits, short of writing deny a ACI by hand. How big a problem is >>>>>>>>> this? It might be worth it to create a special tool that upgrades a >>>>>>>>> single permission and allows setting the excluded/included attributes >>>>>>>>> explicitly. >>>>>>> >>>>>>> This problem would be removed with my approach proposed above. >>>>>>> >>>>>>>>> There are some interesting scenarios to think about with respect to >>>>>>>>> upgrades and user changes: >>>>>>>>> >>>>>>>>> * Upgrade to old version, e.g. >>>>>>>>> - have IPA 3.2 master, IPA 3.2 replica >>>>>>>>> - upgrade master to 4.0 (old permissions are updated) >>>>>>>>> - then upgrade replica to 3.3 (old permissions are added again!) >>>>>>>>> >>>>>>>>> This is AFAIK not supported but it does happen. >>>>>>>>> We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will >>>>>>>>> always add the old permissions, but with this patch, a subsequent >>>>>>>>> upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the >>>>>>>>> old >>>>>>>>> permissions again. >>>>>>> >>>>>>> Hm, I think this is the best option we have. We should warn about this >>>>>>> behavior >>>>>>> in our release notes though. >>>>>>> >>>>>>>>> Tied to that is another scenario: >>>>>>>>> >>>>>>>>> * Re-create permissions with old names >>>>>>>>> - have IPA 4.0 master >>>>>>>>> - Create a permission named 'Modify Sudo rule' >>>>>>>>> - Upgrade to IPA 4.1 >>>>>>>>> >>>>>>>>> Here we need to make sure the new permission is *not* removed, >>>>>>>>> because a >>>>>>>>> new 'Modify Sudo rule' permission is no longer special in any way. To >>>>>>>>> ensure this the updater only removes old-style permissions. >>>>>>> >>>>>>> Right, we can decide based on objectclasses - whether permissionsv2 OC >>>>>>> is there >>>>>>> or not. >>>>>>> >>>>>>>>> >>>>>>>>> One thing that can happen when 4.0 masters are still mixed with 3.x is >>>>>>>>> that an old permission named 'Modify Sudo rule' is added on the old >>>>>>>>> server. Any update to 4.0+ will remove that. >>>>>>>>> Old-style default permissions were sorta-kinda managed by IPA itself >>>>>>>>> anyway, so users should expect this. We should still point it out in >>>>>>>>> the >>>>>>>>> docs though, since I expect some users to start messing with the >>>>>>>>> permissions before upgrading all of the infrastructure to 4.0. >>>>>>> >>>>>>> +1, I would just point out that behavior in the release notes. >>>>>>> >>>>>>>>> The second patch upgrades sudorule permissions, this server as an >>>>>>>>> example of how the will work. >>>>>>>>> The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 >>>>>>>> >>>>>>>> The user read permissions patches had a conflict with these; >>>>>>>> attaching rebased >>>>>>>> version. >>>>>>> >>>>>>> Now the actual review >>>>>>> 552.2: worked fine for me. Some updates will probably be needed >>>>>>> though, based >>>>>>> on the discussion above. >>>>>>> >>>>>>> 553.2: >>>>>>> >>>>>>> 1) Why should we bother specifying ipapermdefaultattr for "add" ACIs? >>>>>>> Looks >>>>>>> like a noop to me, it was also never part of our add ACIs. >>>>>> >>>>>> Simo, I hazily remember discussing that we should only allow specific >>>>>> attributes on add, otherwise users can add entries with any extra >>>>>> objectclasses and attributes. Did we come to a conclusion? >>>>>> I might have confused targetattr with targetattrfilter in my notes; >>>>>> since I see targetarr is ineffective. >>>>> >>>>> OK, this was just me confused. As Ludwig told me, >>>>>> for adding an entry you need add rights for the entry and write rights >>>>>> for each attribute, so in the add aci the targetattrs are irrelevant. >>>>> so I'll remove them from the add ACI. >>>>> >>>>>>> I tried to strip that down to just "description" and I was still able >>>>>>> to add a >>>>>>> whole new SUDO rule. Ludwig, is that correct - does DS ignore (should >>>>>>> it?) >>>>>>> targetattr part of add ACI? >>>>>>> >>>>>>> 2) You stated 'System: Modify Sudo rule' as "add" ACI, making it >>>>>>> ineffective. >>>>>>> Privileged user still cannot update all SUDO rule attributes. >>>>>> >>>>>> Duh. I've been staring at this too long. >>>>>> >>>>>>> Besides that, the ACIs were working fine. >>>> >>>> The attached version looks at the old permission in LDAP and if it differs from >>>> the old default only in the targetattrs, it transplants the difference to the >>>> new managed permission. >>>> >>>> There is a lot of logging here so if something didn't work the way you >>>> expected, at least you'll know what happened. >>>> >>>> When there were multiple defaults, i.e. IPA added/removed some attributes in >>>> some version: the new managed permission's attributes will be applied, so >>>> upgrades from both very old and not-so-old versions should "do the right >>>> thing". >>>> >>>> If the old permission differs in something else than targetattrs, an error is >>>> logged (this will show up in yum update output), and as before the new managed >>>> permission is not created. The user now has 3 options to fix this: >>>> - Delete the old permission, then run ipa-ldap-updater to create the new >>>> default. >>> >>> This will probably be the safest route to go for users. >>> >>>> - Modify the old permission on an *old* system to match the old default, >>>> possibly with targetattr changes, then run a *new* ipa-ldap-updater to convert >>>> that to the new default >>>> - Modify the old permission on a *new* system, which changes it to a V2 >>>> permission, then run ipa-ldap-updater to create the new default, ending up with >>>> both permissions. >>>> >>>> The distinction betwen the last two is subtle and error-prone, but >>>> 1) I don't see a better way, considering that future upgrades need to work well >>>> (in IPA 4.0+ a user-created permission named "Add Sudo Rule" has no special >>>> status) >>>> 2) I'm hoping that people didn't modify the old default permissions that much; >>>> if they did they should have felt some pain already -- I don't think the update >>>> system in 3.x would handle such changes wery well >>> >>> I would personally still be more forceful, especially given the arguments you >>> gave in 2) and just log the old too-modified ACI and convert it to the new >>> style, but there are not many followers to this opinion though... >> >> On the other hand, if someone did this kind of thing they probably (thought >> they) knew what they were doing, so they deserve a chance for manual intervention. > > Ok, fair enough. I found permission-del & "ipa-ldap-update --upgrade" as the > easiest way to restore such permission. We should add similar hint later to > release notes. > >> >>>> Apply my patch 0565 before trying these out. >>>> >>>> >>>> Some testing tips: >>>> - Create 3.x master and replica >>>> - Upgrade master RPMs with these patches >>>> - to add old permissions, run ipa-ldap-updater on the replica >>>> - to simulate an upgrade, run ipa-ldap-updater on the master >>>> - to delete a managed permission: >>>> $ curl -v -H Content-Type:application/json -H Accept:applicaton/json >>>> --negotiate -u : --delegation always --cacert /etc/ipa/ca.crt -X POST -H >>>> referer:https://`hostname`/ipa/json -d '{"method": "permission_del", >>>> "params":[["$PERMISSION_NAME"],{"force":true}], "id":0 }' >>>> https://`hostname`/ipa/json >>>> - be careful where you run permission-mod; on 4.0 it will convert the >>>> permission to V2 >>> >>> In my tests, the upgrade from 3.x worked as expected so that went well. What I >>> still miss is a removal of ipapermdefaultattr in Add ACI in 553.3. As we >>> mentioned earlier, it is a NOOP and rather confuses people instead of improving >>> anything. Besides that, I did not spot any pending error. >> >> Ah, sorry, I rebased on the wrong patch. >> Here is the fixed version. > > This one works fine, so ACK from me. > > Martin > Thanks for reviewing! Pushed to master: f802845a7abfca0b414ad6801968d33e6788916b -- Petr? From simo at redhat.com Wed Jun 4 15:41:37 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 11:41:37 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538F0724.2020600@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> Message-ID: <1401896497.28354.8.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: > On 06/04/2014 10:43 AM, thierry bordaz wrote: > > > >> > >> So my proposal would contain the following components > >> > >> 1] Store replication configuration in the shared tree in a > >> combination of server and connection view (think we need both) and > >> map replication configuration to these entries. I would prefer a > >> direct mapping (with a subset of the cn=config attributes and > >> required additions) > > > > About adding a new server in the replication topology. > > If it was initialized, it may register itself into the shared tree and > > then join the topology. If it was not initialized, it can be > > initialized online by one of the master. Will it be triggered with an > > update to the shared tree ? > > I think this has to be decided, I proposed some kind of bootstrapping: > If the topology plugin is enabled and started it would check if there is > already info on the connections for this server and if not create/update > the entry in the shared tree, this could also happen if a new server is > added. You mean updating the shared tree from information about replication agreements found in cn=config ? I can see how this would be useful in migration from previous server versions, but I fear would cause issues if you remove a connection when one of the 2 servers is down. When you bring the server up it would try to re-create a connection that was deleted by the admin. It's a catch-22 which is why I want the shared tree to be authoritative but not the cn=config tree. > But Simo wanted to have the info in the shared tree indepndent of what > was already configured. It's not much about being independent, it's about what is authoritative and what is not. > One problem with the automatic approach is what should be done if the > config differs on the already deployed servers That's just one of many problems. I think cn=config entries should be read an injected in the shared topology only once at upgrade time, but not anymore after. Maybe this calls for adding nodes to the topology tree, if the topology plugin starts and the server is not in the topology tree, then it sources the local configuration, then adds itself and the connections to the topology tree. If the node is already in the topology tree this step is always skipped. Or something similar (could be just a flag in cn=masters objects). makes sense ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Wed Jun 4 15:46:47 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 04 Jun 2014 17:46:47 +0200 Subject: [Freeipa-devel] User life Cycle: referential integrity Message-ID: <538F3F67.60804@redhat.com> Hello, I am looking at the appropriate way to configure DS referential integrity and I am hitting some issues about its scoping and which attributes need to be preserved. User A and B are both Active. User A refers user B for example 'owner: '. If entry A is deleted (user-del), it keeps 'owner: '. Do we really want to preserve such attributes (owner, member, seeAlso...) in case the user is coming back (user-undel) ? If it makes sense we may achieve this if we extends RI to both 'Active' and 'Delete' container. If we prefer to remove such attributes, then 'user-del' is a MODRDN followed by some MODs or a ADD-DEL where the Delete entry is rebuilt from the 'Active' entry. This is a similar problem when using 'stageuser-add --from-delete', the references may become invalid (unless RI also covers Staging). An option would be to accept to have invalid references in 'staging' and 'delete', but when the entry is stageuser-activate/user-undel the reference are checked and removed if invalid. Here invalid means, the referred entry does not exist or is not 'Active'. thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Jun 4 15:47:26 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Jun 2014 18:47:26 +0300 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1398975733.2017.1.camel@localhost.localdomain> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> Message-ID: <20140604154726.GI2726@redhat.com> On Thu, 01 May 2014, Nathaniel McCallum wrote: >On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: >> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: >> > On Tue, 11 Mar 2014, Jan Pazdziora wrote: >> > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: >> > >> Before this patch, ipa-kdb would load global configuration on startup >> > >> and never update it. This means that if global configuration is changed, >> > >> the KDC never receives the new configuration until it is restarted. >> > >> >> > >> This patch enables caching of the global configuration with a timeout of >> > >> 60 seconds. >> > >> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >> > > >> > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 >> > >> From: Nathaniel McCallum >> > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 >> > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration >> > >> >> > >> Before this patch, ipa-kdb would load global configuration on startup and >> > >> never update it. This means that if global configuration is changed, the >> > >> KDC never receives the new configuration until it is restarted. >> > >> >> > >> This patch enables caching of the global configuration with a timeout of >> > >> 60 seconds. >> > >> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >> > > >> > >I have only read the code and it looks sane, so depending on how much >> > >you consider my word about code-reading worth, ack. >> > > >> > >However, my gut feeling is that my preferred way of handling the issue >> > >(without knowing much about the background of the ticket) would >> > >probably be a HUP signal handler or something similar, rather than >> > >polling for current values with the value timeout. This patch >> > >introduces small nondeterminism to the behaviour when the usage of the >> > >new values cannot really be enfoced by the admin (without the daemon >> > >restart). >> > Thing is, we need the update to happen when other, non-root process >> > makes the changes -- in our case when IPA server running under httpd >> > privileges performs series of MS-RPC calls towards smbd which lead to >> > creating certain LDAP objects. httpd couldn't send SIGHUP to a process >> > not owned by httpd's effective user (non-root). >> >> Yes but this is not really the way to go. >> >> The proper fix is to use syncrepl/persistent search to get a >> notification of when we need to reload the configuration. >> >> On the patch itself I have a NACK due to this syntax used in various >> places: function()->attribute >> >> don't. do. that. ever. >> >> assign whatever come from the function to a local variable and *check* >> it is not null, *then* use it. > >Attached patch fixes the NACK issue, but does not address the question >of the larger approach. Do we need to take a different approach? If so, >what is it? I've tested the patch but was unable to spot any activity to refresh the configuration after I've updated it with ipa config-mod --ipaconfigstring=KDC:Disable\ Lockout At least, dirsrv logs didn't show me any attempt to re-read IPA config past the change. > >Nathaniel -- / Alexander Bokovoy From simo at redhat.com Wed Jun 4 15:58:22 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 11:58:22 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401896497.28354.8.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> Message-ID: <1401897502.28354.11.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 11:41 -0400, Simo Sorce wrote: > On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: > > On 06/04/2014 10:43 AM, thierry bordaz wrote: > > > > > >> > > >> So my proposal would contain the following components > > >> > > >> 1] Store replication configuration in the shared tree in a > > >> combination of server and connection view (think we need both) and > > >> map replication configuration to these entries. I would prefer a > > >> direct mapping (with a subset of the cn=config attributes and > > >> required additions) > > > > > > About adding a new server in the replication topology. > > > If it was initialized, it may register itself into the shared tree and > > > then join the topology. If it was not initialized, it can be > > > initialized online by one of the master. Will it be triggered with an > > > update to the shared tree ? > > > > I think this has to be decided, I proposed some kind of bootstrapping: > > If the topology plugin is enabled and started it would check if there is > > already info on the connections for this server and if not create/update > > the entry in the shared tree, this could also happen if a new server is > > added. > > You mean updating the shared tree from information about replication > agreements found in cn=config ? > I can see how this would be useful in migration from previous server > versions, but I fear would cause issues if you remove a connection when > one of the 2 servers is down. > When you bring the server up it would try to re-create a connection that > was deleted by the admin. It's a catch-22 which is why I want the shared > tree to be authoritative but not the cn=config tree. > > > But Simo wanted to have the info in the shared tree indepndent of what > > was already configured. > > It's not much about being independent, it's about what is authoritative > and what is not. > > > One problem with the automatic approach is what should be done if the > > config differs on the already deployed servers > > That's just one of many problems. > I think cn=config entries should be read an injected in the shared > topology only once at upgrade time, but not anymore after. > Maybe this calls for adding nodes to the topology tree, if the topology > plugin starts and the server is not in the topology tree, then it > sources the local configuration, then adds itself and the connections to > the topology tree. > If the node is already in the topology tree this step is always skipped. > > Or something similar (could be just a flag in cn=masters objects). Replying to myself, a flag on the cn=masters servers is probably better, because otherwise connection objects would reference "missing" nodes (servers that have not already been upgraded) or they would cause the creation of missing node (for integrity) and that would cause those servers to not be able to import their agreements. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 4 16:02:44 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 12:02:44 -0400 Subject: [Freeipa-devel] User life Cycle: referential integrity In-Reply-To: <538F3F67.60804@redhat.com> References: <538F3F67.60804@redhat.com> Message-ID: <1401897764.28354.15.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: > Hello, > > I am looking at the appropriate way to configure DS > referential integrity and I am hitting some issues about its > scoping and which attributes need to be preserved. > > > User A and B are both Active. User A refers user B for > example 'owner: '. > If entry A is deleted (user-del), it keeps 'owner: in Active container>'. Do we really want to preserve such > attributes (owner, member, seeAlso...) in case the user is > coming back (user-undel) ? No, when a user is deleted all references to it in the rest of the tree should be removed. the entries "it" references can stay I guess, the user is deleted so no harm should come from it having dangling DNs in its attributes. > If it makes sense we may achieve this if we extends RI to both > 'Active' and 'Delete' container. Nope, makes no sense. > If we prefer to remove such attributes, then 'user-del' is a > MODRDN followed by some MODs or a ADD-DEL where the Delete > entry is rebuilt from the 'Active' entry. Delete must be a modrdn, we cannot delete the entry and re-add it. > This is a similar problem when using 'stageuser-add > --from-delete', the references may become invalid (unless RI > also covers Staging). There should be no references in either staged or delete users, or they should be adjusted when the user is unstaged/undeleted. > An option would be to accept to have invalid references in > 'staging' and 'delete', but when the entry is > stageuser-activate/user-undel the reference are checked and > removed if invalid. Here invalid means, the referred entry > does not exist or is not 'Active'. Yup, this sounds right, when you "activate" the user references need to be checked and adjusted accordingly. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Wed Jun 4 16:04:54 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 04 Jun 2014 18:04:54 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401896497.28354.8.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> Message-ID: <538F43A6.3030501@redhat.com> On 06/04/2014 05:41 PM, Simo Sorce wrote: > On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: >> On 06/04/2014 10:43 AM, thierry bordaz wrote: >>>> So my proposal would contain the following components >>>> >>>> 1] Store replication configuration in the shared tree in a >>>> combination of server and connection view (think we need both) and >>>> map replication configuration to these entries. I would prefer a >>>> direct mapping (with a subset of the cn=config attributes and >>>> required additions) >>> About adding a new server in the replication topology. >>> If it was initialized, it may register itself into the shared tree and >>> then join the topology. If it was not initialized, it can be >>> initialized online by one of the master. Will it be triggered with an >>> update to the shared tree ? >> I think this has to be decided, I proposed some kind of bootstrapping: >> If the topology plugin is enabled and started it would check if there is >> already info on the connections for this server and if not create/update >> the entry in the shared tree, this could also happen if a new server is >> added. > You mean updating the shared tree from information about replication > agreements found in cn=config ? > I can see how this would be useful in migration from previous server > versions, but I fear would cause issues if you remove a connection when > one of the 2 servers is down. > When you bring the server up it would try to re-create a connection that > was deleted by the admin. It's a catch-22 which is why I want the shared > tree to be authoritative but not the cn=config tree. > >> But Simo wanted to have the info in the shared tree indepndent of what >> was already configured. > It's not much about being independent, it's about what is authoritative > and what is not. > >> One problem with the automatic approach is what should be done if the >> config differs on the already deployed servers > That's just one of many problems. > I think cn=config entries should be read an injected in the shared > topology only once at upgrade time, but not anymore after. > Maybe this calls for adding nodes to the topology tree, if the topology > plugin starts and the server is not in the topology tree, then it > sources the local configuration, then adds itself and the connections to > the topology tree. > If the node is already in the topology tree this step is always skipped. I like the idea that the node can add itself and the connection to the topology tree. But this requires that the node database is already initialized (have the same replicageneration than the others nodes). If it is not initialized, it could be done by any masters. But if it is automatic, there is a risk that several masters will want to initialize it. In addition if the new node has a different replicageneration, how does the new node know that it should wait to be initialized rather than initialize the others. > > Or something similar (could be just a flag in cn=masters objects). > > makes sense ? > > Simo. > From simo at redhat.com Wed Jun 4 16:19:52 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 12:19:52 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538F43A6.3030501@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> Message-ID: <1401898792.28354.21.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 18:04 +0200, thierry bordaz wrote: > On 06/04/2014 05:41 PM, Simo Sorce wrote: > > On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: > >> On 06/04/2014 10:43 AM, thierry bordaz wrote: > >>>> So my proposal would contain the following components > >>>> > >>>> 1] Store replication configuration in the shared tree in a > >>>> combination of server and connection view (think we need both) and > >>>> map replication configuration to these entries. I would prefer a > >>>> direct mapping (with a subset of the cn=config attributes and > >>>> required additions) > >>> About adding a new server in the replication topology. > >>> If it was initialized, it may register itself into the shared tree and > >>> then join the topology. If it was not initialized, it can be > >>> initialized online by one of the master. Will it be triggered with an > >>> update to the shared tree ? > >> I think this has to be decided, I proposed some kind of bootstrapping: > >> If the topology plugin is enabled and started it would check if there is > >> already info on the connections for this server and if not create/update > >> the entry in the shared tree, this could also happen if a new server is > >> added. > > You mean updating the shared tree from information about replication > > agreements found in cn=config ? > > I can see how this would be useful in migration from previous server > > versions, but I fear would cause issues if you remove a connection when > > one of the 2 servers is down. > > When you bring the server up it would try to re-create a connection that > > was deleted by the admin. It's a catch-22 which is why I want the shared > > tree to be authoritative but not the cn=config tree. > > > >> But Simo wanted to have the info in the shared tree indepndent of what > >> was already configured. > > It's not much about being independent, it's about what is authoritative > > and what is not. > > > >> One problem with the automatic approach is what should be done if the > >> config differs on the already deployed servers > > That's just one of many problems. > > I think cn=config entries should be read an injected in the shared > > topology only once at upgrade time, but not anymore after. > > Maybe this calls for adding nodes to the topology tree, if the topology > > plugin starts and the server is not in the topology tree, then it > > sources the local configuration, then adds itself and the connections to > > the topology tree. > > If the node is already in the topology tree this step is always skipped. > I like the idea that the node can add itself and the connection to the > topology tree. > But this requires that the node database is already initialized (have > the same replicageneration than the others nodes). > If it is not initialized, it could be done by any masters. But if it is > automatic, there is a risk that several masters will want to initialize it. > > In addition if the new node has a different replicageneration, how does > the new node know that it should wait to be initialized rather than > initialize the others. Yeah see my follow-up, I think a flag would be better, this way import is done only once and never more. If a node is already initialized then the topology plugin will always wipe away and reconfigure agreements in cn=config from the topology tree and never backwards. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Jun 4 16:34:19 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 04 Jun 2014 18:34:19 +0200 Subject: [Freeipa-devel] Is CA certificate storage correct? In-Reply-To: <537F5CE6.1000500@redhat.com> References: <537AF620.6090802@redhat.com> <537B1D5F.6000305@redhat.com> <537F5CE6.1000500@redhat.com> Message-ID: <538F4A8B.7000602@redhat.com> On 23.5.2014 16:36, Martin Kosek wrote: > On 05/20/2014 11:16 AM, Jan Cholasta wrote: >> On 20.5.2014 08:28, Martin Kosek wrote: >>> Hi there, >>> >>> I checked the update CA Certificate renewal feature design page and one part >>> seemed awkward to me: >>> >>> http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store >>> >>> IIUC, when there are multiple iterations of a certificate stored, there will be >>> one LDAP object with multiple cACertificate attributes, multiple ipaKeyUsage >>> attributes, ipaKeyTrust, ... >>> >>> Given that LDAP does not guarantee order, how do I identify which cACertificate >>> belongs to which attribute? >> >> There is no such relation, ipaKey* attributes apply to all of the cACertificate >> attributes. >> >>> >>> If I do ldapsearch for some specific ipaKeyUsage and I get this LDAP record >>> returned, how do I find out which certificate it is? Do I need to go through >>> all binary blobs, parse them and look which blob matches? >> >> No. > > Could you then please state some example in > > http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store > > with more than one cACertificate;binary? I think it would greatly help > understand the relation of the new schema attributes and cACertificate. As you > can see, it may be pretty confusing. Updated the design page. Hopefully it's clearer now. > > Martin > -- Jan Cholasta From jcholast at redhat.com Wed Jun 4 16:42:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 04 Jun 2014 18:42:41 +0200 Subject: [Freeipa-devel] CA certificate renewal, shared store trust settings In-Reply-To: <20140530141121.GA16884@redhat.com> References: <20140529174427.GC12741@redhat.com> <53882EBA.4030007@redhat.com> <20140530141121.GA16884@redhat.com> Message-ID: <538F4C81.30800@redhat.com> On 30.5.2014 16:11, Nalin Dahyabhai wrote: > On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote: >> On 29.5.2014 19:44, Nalin Dahyabhai wrote: >>> I'm working on adding to certmonger the ability to read the IPA root >>> certificate from the server and store it locally, and I'm looking at the >>> V4 shared certificate store feature [1] with an eye toward also pulling >>> down and processing those certificates. Before I head down that path, >>> I've got a few questions about the schema that the page describes for >>> storing trust information. >> >> So, you want to fetch the certificates directly from LDAP? Shouldn't >> they rather be fetched using IPA API (in ipa-submit) or Dogtag API >> (in dogtag-ipa-renew-agent-submit)? > > Yes, that's something the daemon is farming out to the enrollment > helpers. As a start, though, I'm only looking at teaching ipa-submit to > fetch this information. > > The IPA interfaces run over HTTPS, so I thought that having ipa-submit > search LDAP using GSSAPI would avoid complications that could arise if > the CA certificate had become invalid before we went to fetch things. Right, that might be a problem. > > The request for the "read the root certificate" functionality is to have > something that works against servers running IPA on EL6, so the ability > to fetch the v3 root information is dictated by needing to work against > what we're already storing and offering there. > > Accessing the additional information that's coming in v4 could be done > differently, but I'd also lean toward looking at the directory directly. > The design page mentions asking SSSD for it, which I guess would work. Well, both will work. > >> In the past few months that I worked on the CA certificate renewal >> feature the shared certificate store design has evolved into >> something more about certificate trust policy rather than simple >> storage of CA certificates. My plan is to integrate it with p11-kit >> in the forthcoming months to provide the policy to IPA clients. SSSD >> is going to be used as the component between IPA and p11-kit. A >> PKCS#11 module will be provided for (not only) that. (This is what >> is going >> to be about.) >> >> I can imagine you might as well talk to the module to fetch the CA >> certificates. Are there any plans to support PKCS#11 as a storage >> backend in certmonger? > > Only notionally, as it it's only ever been one of those "would be cool, > but we don't need it in the short-term" things. I also wasn't looking > forward to dealing with cases where a removable token isn't inserted > right when we intend to access it, but if we need to make that work, > then okay. > >> This does not make me nervous at all. Take a look at other similar >> attributes in IPA, they all use directory string syntax. I'm open to >> suggestions, though. > > The first thing that comes to mind is an enumerated syntax like the one > for booleans, but I understand that enforcing that would require help > from the server itself. The docs tell me that syntax plugins are a > thing we can supply, but that might be more than we want to bite off. My thoughts exactly. > >>> The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted' >>> and 'distrusted', appears to map pretty directly to the sort of >>> information that OpenSSL stores in trusted certificates [2], but going >>> through the man pages for x509(1) and verify(1), I don't see anything >>> that obviously corresponds to an ipaKeyTrust value of 'unknown'. What's >>> that value intended to signify, and how would consumers of the >>> certificates be expected to treat certificates from entries with that >>> ipaKeyTrust value? >> >> Actually it is designed to map to p11-kit-style trust policy (), >> which is a superset of OpenSSL's. > > What's the planned schedule for teaching NSS and OpenSSL to consume > trust information supplied in this format? It's all available in Fedora since F19, see . > >> The "unknown" value means the trust is not explicitly given and that >> if there is other source of trust information for the >> key/certificate, it should be used. In p11-kit terms, it is for >> certificates which are neither in the anchors nor the blacklist set. >> In NSS terms, it's for certificates without any of the C, T, P or p >> trust flags. > > Okay, that makes sense -- they're around for building chains, but not > much else. > >>> Are there examples of what the ipaKeyUsage attribute should contain? >> >> It's the purpose bit names from the key usage certificate extension >> () or "none". > > So, enumerated values represented as directory strings? Yes. > >>> Is there a recommended method for mapping from this representation to >>> the form that we'd pass to certutil(1)'s '-t' option when storing the >>> certificates in NSS databases, or is the intent that it be translated >>> into NSS-specific PKCS#11 attributes set on those certificates? >> >> Well, it can be both. But as I said above, I'm not sure if reading >> from LDAP directly is the best thing to do in this case. > > [shrug] If that's where it's being stored, something's going to have to > fetch it from there. Until the SSSD and IPA interfaces are fleshed out, > LDAP's the only option. But I understand we're not there yet. > > I'm starting to think that attempting to future-proof by learning to > fetch and store the v4 information isn't a good idea at this time, and > sticking to just fetching the data we store in v3 is the better option. I agree. We can work out the details later. > > Cheers, > > Nalin > -- Jan Cholasta From pviktori at redhat.com Wed Jun 4 16:43:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Jun 2014 18:43:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed Message-ID: <538F4CA1.4070501@redhat.com> Hello, I try to think about any kind of data the user might have in LDAP, but in the spirit of YAGNI, I'll deal with the various corner cases in IPA's historic default permissions as I go along. Patch 0568 adds support for the case where the default permissions changed in something else than attribute lists. Needed for the 'Change User password' permission. Patch 0569 converts user permissions to managed. Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0568-managed-perm-updater-Handle-case-where-we-changed-de.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0569-Convert-User-default-permissions-to-managed.patch Type: text/x-patch Size: 14891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0570-Add-nsAccountLock-to-the-Unlock-user-accounts-permis.patch Type: text/x-patch Size: 1208 bytes Desc: not available URL: From tbordaz at redhat.com Wed Jun 4 16:46:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 04 Jun 2014 18:46:39 +0200 Subject: [Freeipa-devel] User life Cycle: referential integrity In-Reply-To: <1401897764.28354.15.camel@willson.usersys.redhat.com> References: <538F3F67.60804@redhat.com> <1401897764.28354.15.camel@willson.usersys.redhat.com> Message-ID: <538F4D6F.1090906@redhat.com> On 06/04/2014 06:02 PM, Simo Sorce wrote: > On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: >> Hello, >> >> I am looking at the appropriate way to configure DS >> referential integrity and I am hitting some issues about its >> scoping and which attributes need to be preserved. >> >> >> User A and B are both Active. User A refers user B for >> example 'owner: '. >> If entry A is deleted (user-del), it keeps 'owner: > in Active container>'. Do we really want to preserve such >> attributes (owner, member, seeAlso...) in case the user is >> coming back (user-undel) ? > No, when a user is deleted all references to it in the rest of the tree > should be removed. the entries "it" references can stay I guess, the > user is deleted so no harm should come from it having dangling DNs in > its attributes. Actually it was my concern. If users A then B are moved Active->Delete (user-del), then the reference to B in the 'Active' container is not removed by RI. If for any reason user A returns to Active (user-undel), it contains dangling DN unless it is checked/removed. >> If it makes sense we may achieve this if we extends RI to both >> 'Active' and 'Delete' container. > Nope, makes no sense. > >> If we prefer to remove such attributes, then 'user-del' is a >> MODRDN followed by some MODs or a ADD-DEL where the Delete >> entry is rebuilt from the 'Active' entry. > Delete must be a modrdn, we cannot delete the entry and re-add it. ok great :) >> This is a similar problem when using 'stageuser-add >> --from-delete', the references may become invalid (unless RI >> also covers Staging). > There should be no references in either staged or delete users, or they > should be adjusted when the user is unstaged/undeleted. > >> An option would be to accept to have invalid references in >> 'staging' and 'delete', but when the entry is >> stageuser-activate/user-undel the reference are checked and >> removed if invalid. Here invalid means, the referred entry >> does not exist or is not 'Active'. > Yup, this sounds right, when you "activate" the user references need to > be checked and adjusted accordingly. Which attributes need to be checked/adjusted ? those configured in RI ? attributes with DN syntax ? thierry > > Simo. > From simo at redhat.com Wed Jun 4 17:04:46 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 13:04:46 -0400 Subject: [Freeipa-devel] User life Cycle: referential integrity In-Reply-To: <538F4D6F.1090906@redhat.com> References: <538F3F67.60804@redhat.com> <1401897764.28354.15.camel@willson.usersys.redhat.com> <538F4D6F.1090906@redhat.com> Message-ID: <1401901486.31205.3.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 18:46 +0200, thierry bordaz wrote: > On 06/04/2014 06:02 PM, Simo Sorce wrote: > > On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: > >> Hello, > >> > >> I am looking at the appropriate way to configure DS > >> referential integrity and I am hitting some issues about its > >> scoping and which attributes need to be preserved. > >> > >> > >> User A and B are both Active. User A refers user B for > >> example 'owner: '. > >> If entry A is deleted (user-del), it keeps 'owner: >> in Active container>'. Do we really want to preserve such > >> attributes (owner, member, seeAlso...) in case the user is > >> coming back (user-undel) ? > > No, when a user is deleted all references to it in the rest of the tree > > should be removed. the entries "it" references can stay I guess, the > > user is deleted so no harm should come from it having dangling DNs in > > its attributes. > Actually it was my concern. If users A then B are moved Active->Delete > (user-del), then the reference to B in the 'Active' container is not > removed by RI. If for any reason user A returns to Active (user-undel), > it contains dangling DN unless it is checked/removed. > >> If it makes sense we may achieve this if we extends RI to both > >> 'Active' and 'Delete' container. > > Nope, makes no sense. > > > >> If we prefer to remove such attributes, then 'user-del' is a > >> MODRDN followed by some MODs or a ADD-DEL where the Delete > >> entry is rebuilt from the 'Active' entry. > > Delete must be a modrdn, we cannot delete the entry and re-add it. > ok great :) > >> This is a similar problem when using 'stageuser-add > >> --from-delete', the references may become invalid (unless RI > >> also covers Staging). > > There should be no references in either staged or delete users, or they > > should be adjusted when the user is unstaged/undeleted. > > > >> An option would be to accept to have invalid references in > >> 'staging' and 'delete', but when the entry is > >> stageuser-activate/user-undel the reference are checked and > >> removed if invalid. Here invalid means, the referred entry > >> does not exist or is not 'Active'. > > Yup, this sounds right, when you "activate" the user references need to > > be checked and adjusted accordingly. > Which attributes need to be checked/adjusted ? those configured in RI ? > attributes with DN syntax ? Probably all the attrributes with DN syntax, I am partiocularly concerned with memberof and manager. but memberof should be removed automatically at delete time by the fact the user should be removed from any group (does RI do this when an entry moves out of scope ?) Manager if there should probably be adjusted, others should probably be just wiped and let automember or other plugin or an admin fix whatever need fixing ? Seem like a rathole especially if the user has an objectclass in ti the has a DN containing attribute as MUST ... We need to think of a sensible behavior when this happens as it could be an additional custom class/attribute the admin added... Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Jun 4 18:52:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Jun 2014 20:52:23 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <1401896126.28354.2.camel@willson.usersys.redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> Message-ID: <538F6AE7.4050308@redhat.com> On 06/04/2014 05:35 PM, Simo Sorce wrote: > On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: >> On 06/04/2014 08:34 AM, Martin Kosek wrote: >> ... >>> Users >>> - Users >>> - Groups >>> - SUDO >>> >>> Hosts >>> - Hosts >>> - Host groups >>> - Services >>> - Netgroups >>> - Automount >>> >>> Authentication >>> - OTP Tokens >>> - Password Policy >>> - Kerberos Ticket Policy >>> >>> Policy >>> - HBAC >>> - SELinux User Maps >>> - Automember >> >> Alternatively, we could rename Policy to "Authorization" as both HBAC and >> SELinux is about authorizing what an authenticated user can do. We would just >> need to move Automember to different place, though this one is difficult - it >> relates both to Users and Hosts, just like Netgroup. > > I do not see the need to do Policy -> Authorization but Automember is in > the wrong place imo. > > The first tab should be Users -> Accounts and include automember in it > as automember is about groupings ? > > Actually I would merge the current Users and Hosts tabs into > 'Accounts' (or maybe 'Identities' ?) and add Automember. > > Simo. > Automember is about grouping both users and hosts. I put it under Policy originally as it basically is a policy, when are certain users/hosts automember'ed. I would personally not merge Users and Hosts top level menus to one top level menu as that would spoil the whole reason why this effort is done, i.e. have at most 7 items in the second level bar to make things clearer. To me, it seemed a good idea to split Users and Hosts to achieve the target as it separates well the intent what one wants to do. Now we have it all under Identity (including DNS and Realm Domains) which is messy. But I am pretty open to counter-proposals which keeps the UX requirement of 7 second level items. Martin From simo at redhat.com Wed Jun 4 20:10:16 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Jun 2014 16:10:16 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538F6AE7.4050308@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> Message-ID: <1401912616.597.7.camel@willson.usersys.redhat.com> On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote: > On 06/04/2014 05:35 PM, Simo Sorce wrote: > > On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: > >> On 06/04/2014 08:34 AM, Martin Kosek wrote: > >> ... > >>> Users > >>> - Users > >>> - Groups > >>> - SUDO > >>> > >>> Hosts > >>> - Hosts > >>> - Host groups > >>> - Services > >>> - Netgroups > >>> - Automount > >>> > >>> Authentication > >>> - OTP Tokens > >>> - Password Policy > >>> - Kerberos Ticket Policy > >>> > >>> Policy > >>> - HBAC > >>> - SELinux User Maps > >>> - Automember > >> > >> Alternatively, we could rename Policy to "Authorization" as both HBAC and > >> SELinux is about authorizing what an authenticated user can do. We would just > >> need to move Automember to different place, though this one is difficult - it > >> relates both to Users and Hosts, just like Netgroup. > > > > I do not see the need to do Policy -> Authorization but Automember is in > > the wrong place imo. > > > > The first tab should be Users -> Accounts and include automember in it > > as automember is about groupings ? > > > > Actually I would merge the current Users and Hosts tabs into > > 'Accounts' (or maybe 'Identities' ?) and add Automember. > > > > Simo. > > > > Automember is about grouping both users and hosts. I put it under Policy > originally as it basically is a policy, when are certain users/hosts automember'ed. > > I would personally not merge Users and Hosts top level menus to one top level > menu as that would spoil the whole reason why this effort is done, i.e. have at > most 7 items in the second level bar to make things clearer. > > To me, it seemed a good idea to split Users and Hosts to achieve the target as > it separates well the intent what one wants to do. Now we have it all under > Identity (including DNS and Realm Domains) which is messy. Unfortunately some of your groupings make little sense to me: - why is SUDO under Users ?? It's a security policy and those policies are equally related to users, groups and hosts. - why "policies" are under authentication ? Both password policies and Kerberos Ticket policies have nothing to do with the authentication part, but with changing password and with which features are allowed on tickets. - why automember is in Policy ? It is just autoconfiguration it doesn't enforce any policy on its own > But I am pretty open to counter-proposals which keeps the UX requirement of 7 > second level items. > > Martin This is how it makes sense to me as a logical grouping: Accounts/Identity (7): - Users - Groups - Hosts - Host Groups - Netgroups - Services - Automember ^ These are all identity or identity-grouping related objects/actions Policies (6): - Sudo - HBAC - SELinux User Maps - OTP Tokens (*) - Password Policies - Kerberos ticket Policies ^ These are all Security Policies an admin cares about Directory (6): - Permissions - Privileges - Roles - Delegation NOTE: the 4 above can be merged into a single 'Authorization' entry perhaps - Replication Topology - Views (future) ^ Everything that deals with direct LDAP access/view Network Services (4): - Automount - DNS - CA - Vault (future) ^ All the additional network services or configuration of network related services Configuration (3): - Trusts - ID Ranges - Realm Domains - Global ^ Anything that does not fit the above categories. Docs: - whatever :) (*) The only doubt I have is about OTP Tokens, it may be worth taking them off Policies and putting them into a new tab which in future may also sport a pointer to user certificates management: Authentication: - OTP Tokens - User Certificates (future) HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Wed Jun 4 20:42:23 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Jun 2014 22:42:23 +0200 Subject: [Freeipa-devel] [PATCH 0261-0262] Support run-time changes in idnsSecInlineSigning attribute Message-ID: <538F84AF.1060301@redhat.com> Hello, This patch set allows you to change DNSSEC zone configuration at run-time. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0261-Delete-old-database-journal-files-during-zone-loadin.patch Type: text/x-patch Size: 2442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0262-Support-run-time-changes-in-idnsSecInlineSigning-att.patch Type: text/x-patch Size: 9653 bytes Desc: not available URL: From mgregg at redhat.com Wed Jun 4 20:55:30 2014 From: mgregg at redhat.com (Michael Gregg) Date: Wed, 04 Jun 2014 13:55:30 -0700 Subject: [Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset. Message-ID: <538F87C2.60207@redhat.com> I was trying to join my rhel 5 client to a rhel 7 domain, and getting the following error: [root at oracle ~]# ipa-client-install -p admin -w -U root : ERROR LDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed root : ERROR LDAP Error: Connect error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Unable to find IPA Server to join Installation failed. Rolling back changes. IPA client is not configured on this system. Tried to verify the cert with this: openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt This came up with this error code: Verify return code: 9 (certificate is not yet valid) After syncing the clock, everything worked al-right. I tried googling around a bit, but I couldn't find any specific articles about this problem. Does this sound like a troubleshooting and repair step that is documented somewhere already? Michael- From rcritten at redhat.com Wed Jun 4 21:07:36 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Jun 2014 17:07:36 -0400 Subject: [Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset. In-Reply-To: <538F87C2.60207@redhat.com> References: <538F87C2.60207@redhat.com> Message-ID: <538F8A98.6010905@redhat.com> Michael Gregg wrote: > > I was trying to join my rhel 5 client to a rhel 7 domain, and getting > the following error: > > [root at oracle ~]# ipa-client-install -p admin -w -U > root : ERROR LDAP Error: Connect error: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > root : ERROR LDAP Error: Connect error: error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > Unable to find IPA Server to join > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > Tried to verify the cert with this: > > openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt > > This came up with this error code: > > Verify return code: 9 (certificate is not yet valid) > > After syncing the clock, everything worked al-right. I tried googling > around a bit, but I couldn't find any specific articles about this problem. > > Does this sound like a troubleshooting and repair step that is > documented somewhere already? I don't recall any documentation on this. The time should be synchronized before that happens. Can you send me the full ipaclient-install.log? rob From mgregg at redhat.com Wed Jun 4 21:19:46 2014 From: mgregg at redhat.com (Michael Gregg) Date: Wed, 04 Jun 2014 14:19:46 -0700 Subject: [Freeipa-devel] joining rhel5 ipa clients to rhel 7 server failing caused by time offset. In-Reply-To: <538F8A98.6010905@redhat.com> References: <538F87C2.60207@redhat.com> <538F8A98.6010905@redhat.com> Message-ID: <538F8D72.8060608@redhat.com> On 06/04/2014 02:07 PM, Rob Crittenden wrote: > Michael Gregg wrote: >> I was trying to join my rhel 5 client to a rhel 7 domain, and getting >> the following error: >> >> [root at oracle ~]# ipa-client-install -p admin -w -U >> root : ERROR LDAP Error: Connect error: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> root : ERROR LDAP Error: Connect error: error:14090086:SSL >> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> Unable to find IPA Server to join >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> Tried to verify the cert with this: >> >> openssl s_client -host iota.testrelm.test -port 443 -CAfile /etc/ipa/ca.crt >> >> This came up with this error code: >> >> Verify return code: 9 (certificate is not yet valid) >> >> After syncing the clock, everything worked al-right. I tried googling >> around a bit, but I couldn't find any specific articles about this problem. >> >> Does this sound like a troubleshooting and repair step that is >> documented somewhere already? > I don't recall any documentation on this. The time should be > synchronized before that happens. Can you send me the full > ipaclient-install.log? > > rob Sure thing. The log is not very long. It is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-client-install.log Type: text/x-log Size: 2245 bytes Desc: not available URL: From jcholast at redhat.com Thu Jun 5 06:45:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 05 Jun 2014 08:45:48 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1401309865.4631.5.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> <1401309865.4631.5.camel@ipa.example.com> Message-ID: <5390121C.5070402@redhat.com> On 28.5.2014 22:44, Nathaniel McCallum wrote: > On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: >> On 13.5.2014 19:12, Nathaniel McCallum wrote: >>> On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: >>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: >>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the >>>>>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Admins, as before, have full access to all token permissions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Normal users have read/search/compare access to all of the non-secret >>>>>>>>>>>>>> data for tokens assigned to them, whether protected or non-protected. >>>>>>>>>>>>>> Users can add or delete non-protected tokens and modify most of their >>>>>>>>>>>>>> metadata. However they cannot create, delete or modify protected tokens. >>>>>>>>>>>>>> Regardless of whether the token is protected or not, users cannot change >>>>>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In contrast, admins can create protected tokens. This protects the token >>>>>>>>>>>>>> from deletion or modification when assigned to users. Additionally, when >>>>>>>>>>>>>> a user account is deleted, the assigned non-protected tokens are deleted >>>>>>>>>>>>>> but the protected tokens are merely orphaned. This permits the token to >>>>>>>>>>>>>> be reassigned without having to recreate it. This last point is >>>>>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>>>>> >>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>>>>> This new version makes ipatokenDisabled visible for token owners. It is >>>>>>>>>>>>> also writable if the token is non-protected. This additionally fixes: >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>>>>> This new version changes the way the default value of protected is setup >>>>>>>>>>>> in accordance with the changes made for the review of my patch 0048.2. >>>>>>>>>>>> >>>>>>>>>>>> Nathaniel >>>>>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>>>>> No. Alternate designs are welcome. The code is easy enough to modify. >>>>>>>>>> >>>>>>>>>>> I did not dig too deep into this, but I think it might be better to >>>>>>>>>>> instead use the managedby attribute on a token to limit who can delete >>>>>>>>>>> (or administer in other way) the token. On otptoken-add, managedby would >>>>>>>>>>> be set to the "whoami" user DN, unless run with --protected, in which >>>>>>>>>>> case managedby would be left empty. Then, when deleting a user, the >>>>>>>>>>> token would be deleted only if the user manages the token. >>>>>>>>>> It seems to me that the mechanics of this are roughly the same as >>>>>>>>>> protected, just with a different syntax. The cost of this is more >>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses (is >>>>>>>>>> this possible?) instead of a simple filter. If there is a clear benefit, >>>>>>>>>> we can justify the more obtuse syntax. >>>>>>>>> >>>>>>>>> We usually try not to create new attributes until it is fully justified. >>>>>>>>> I would like Simo to chime in on this. >>>>>>>> >>>>>>>> I would also prefer to reuse existing attributes and mechanism if >>>>>>>> possible and if it will not preclude future work. >>>>>>>> >>>>>>>> In this case, it "sounds" like managed-by has the appropriate meaning: >>>>>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>>>>> >>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>>>>> using managed-by vs a new attribute ? >>>>>>> >>>>>>> These are the ACIs using the protected mechanism: >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = >>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>>>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>>>>>> "ipatokenOwner#SELFDN";) >>>>>>> >>>>>>> This is what they look like using managedBy (I have not tested this): >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>> userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>> "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>> "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>>>>>> userattr = "managedBy#SELFDN";) >>>>>>> >>>>>>> In short: >>>>>>> 1. Owner and manager get read, search and compare. >>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>> >>>>>>> The otptoken-add command should gain the following defaults: >>>>>>> 1. The owner defaults to the user adding the token. >>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>> >>>>>>> This means that if neither owner nor managedBy are specified, the >>>>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>>>> owner is specified, no manager is assumed. >>>>>>> >>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>>>>>> syntax. This will become clear during testing if we want this approach. >>>>>>> >>>>>>> Does this look sane? >>>>>> >>>>>> I am not entirely sure your ACI syntax is always right for the second >>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner >>>>>> once for manager). >>>>>> >>>>>> I think the read ACIs do not need to list managedby ? Do we plan to have >>>>>> a manager that is another regular user but not the owner nor an admin ? >>>>>> >>>>>> In any case I prefer the sytnax that uses managedby, as it has more >>>>>> potential. >>>>> >>>>> Attached is a new version of the patch which implements the feature >>>>> using managedBy instead of ipatokenProtected. One important thing needs >>>>> to be said about this patch. I am not exposing managedBy in either the >>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>> expose this similar to owner or as a relationship? >>>> >>>> I would expose it, as a relationship. (Note that ipatokenowner should >>>> ideally be represented as a relationship too, but the framework does not >>>> support 1-to-many relationships ATM.) >>> >>> So since this is a 1-to-many relationship we shouldn't expose it? >>> >>> Or should I do it like owner is currently done? >> >> Do it like managedby is done in the host plugin (see >> "attribute_members", "relationships", etc.) >> >>> >>>> >>>> Just curious, why are the ACIs divided like this: >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers >>>> can read basic token info"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >>>> details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>> "Users/managers can see HOTP details"; allow (read, search, compare) >>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> >>>> IMHO you could make them less complex by dividing them like this: >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can >>>> read token details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers >>>> can read token details"; allow (read, search, compare) userattr = >>>> "managedBy#USERDN";) >>> >>> The first set is organized by objectClass. The second by userattr. I >>> have no strong opinion on this matter, though performance is probably a >>> consideration. Do any DS guys want to chime in? >> >> I would still like to know someone else's opinion on this, but if >> there's none, let's keep it your way. >> >>> >>>> Would it make sense to keep --protected as a flag in otptoken-add as a >>>> shortcut for "entry_attrs['managedby'] = None"? >>> >>> I can't think of a use case for this. The only use case I *can* think of >>> is an admin creating a non-protected token for a user. >> >> OK. >> >>> >>>> Would it make sense to default managedby to the current bind DN in >>>> otptoken-add, even if it's not a user DN? (Do we want to allow running >>>> otptoken-add by hosts/services/other non-users?) >>> >>> No idea. Dmitri? >> >> We can add this later if necessary. >> >>> >>>> Is orphaning a token when a user is deleted only if it is not managed by >>>> any other users the intended behavior? It just seems sort of strange to >>>> me, since it changes the token from unprotected to protected. >>> >>> I don't think that is the behavior. We orphan the token if the owner is >>> not listed as a manager. If the owner is listed as a manager, we delete >>> the token. >>> >>> Put another way, protected tokens are orphaned and unprotected tokens >>> are deleted. >>> >>> If I didn't implement that, please point out my bug. >> >> Sorry, my bad, your code is right. You can make it simpler, though: >> >> orphan = [x for x in token.get('managedby', []) if x == dn] >> >> (The "len() == 0" check is not necessary and using list comprehensions >> makes the code more readable than using filter.) > > The attached version fixes all the above issues. Two issues that may > remain: > 1. There is no option to set managedBy during otptoken-add or > otptoken-mod. This is probably okay. Yes. I guess this bit is not needed anymore: # If owner was not specified, default to the person adding this token. - if 'ipatokenowner' not in entry_attrs: + # If managedby was not specified, attempt a sensible default. + if 'ipatokenowner' not in entry_attrs or 'managedby' not in entry_attrs: result = self.api.Command.user_find(whoami=True)['result'] if result: cur_uid = result[0]['uid'][0] - entry_attrs.setdefault('ipatokenowner', cur_uid) + prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) + if cur_uid == prev_uid: + entry_attrs.setdefault('managedby', result[0]['dn']) > 2. I can't figure out how to get the framework to actually show > managedBy in command output (like otptoken-show). This means you can > add/remove relationships using otptoken-add-managedby and > otptoken-remove-managedby, but you can't actually see the list of > managers. What am I missing? In the hbacrule or selinuxusermap plugins it is done by adding an "invisible" param to the object plugin, like this: Str('managedby_user?', label=_('Manager'), flags=['no_create', 'no_update', 'no_search'], ), > > Also, it would be helpful if someone with DS expertise could answer the > question about the performance of the ACI structure options as listed > above. +1 > > Nathaniel > You should update the code in user_del to use managedby_user instead of managedby, otherwise it won't really work. -- Jan Cholasta From mkosek at redhat.com Thu Jun 5 08:00:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Jun 2014 10:00:32 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <5390121C.5070402@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> <1401309865.4631.5.camel@ipa.example.com> <5390121C.5070402@redhat.com> Message-ID: <539023A0.4020404@redhat.com> On 06/05/2014 08:45 AM, Jan Cholasta wrote: > On 28.5.2014 22:44, Nathaniel McCallum wrote: >> On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: >>> On 13.5.2014 19:12, Nathaniel McCallum wrote: >>>> On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: ... >>>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>>>>>> using managed-by vs a new attribute ? >>>>>>>> >>>>>>>> These are the ACIs using the protected mechanism: >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>> "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = >>>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>>>>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>>>>>>> "ipatokenOwner#SELFDN";) >>>>>>>> >>>>>>>> This is what they look like using managedBy (I have not tested this): >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>>> userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>>> "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>>> "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>>>>>>> userattr = "managedBy#SELFDN";) >>>>>>>> >>>>>>>> In short: >>>>>>>> 1. Owner and manager get read, search and compare. >>>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>>> >>>>>>>> The otptoken-add command should gain the following defaults: >>>>>>>> 1. The owner defaults to the user adding the token. >>>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>>> >>>>>>>> This means that if neither owner nor managedBy are specified, the >>>>>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>>>>> owner is specified, no manager is assumed. >>>>>>>> >>>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>>>>>>> syntax. This will become clear during testing if we want this approach. >>>>>>>> >>>>>>>> Does this look sane? >>>>>>> >>>>>>> I am not entirely sure your ACI syntax is always right for the second >>>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner >>>>>>> once for manager). >>>>>>> >>>>>>> I think the read ACIs do not need to list managedby ? Do we plan to have >>>>>>> a manager that is another regular user but not the owner nor an admin ? >>>>>>> >>>>>>> In any case I prefer the sytnax that uses managedby, as it has more >>>>>>> potential. >>>>>> >>>>>> Attached is a new version of the patch which implements the feature >>>>>> using managedBy instead of ipatokenProtected. One important thing needs >>>>>> to be said about this patch. I am not exposing managedBy in either the >>>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>>> expose this similar to owner or as a relationship? >>>>> >>>>> I would expose it, as a relationship. (Note that ipatokenowner should >>>>> ideally be represented as a relationship too, but the framework does not >>>>> support 1-to-many relationships ATM.) >>>> >>>> So since this is a 1-to-many relationship we shouldn't expose it? >>>> >>>> Or should I do it like owner is currently done? >>> >>> Do it like managedby is done in the host plugin (see >>> "attribute_members", "relationships", etc.) >>> >>>> >>>>> >>>>> Just curious, why are the ACIs divided like this: >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers >>>>> can read basic token info"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >>>>> details"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>> "Users/managers can see HOTP details"; allow (read, search, compare) >>>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> >>>>> IMHO you could make them less complex by dividing them like this: >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can >>>>> read token details"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers >>>>> can read token details"; allow (read, search, compare) userattr = >>>>> "managedBy#USERDN";) >>>> >>>> The first set is organized by objectClass. The second by userattr. I >>>> have no strong opinion on this matter, though performance is probably a >>>> consideration. Do any DS guys want to chime in? ... >> 2. I can't figure out how to get the framework to actually show >> managedBy in command output (like otptoken-show). This means you can >> add/remove relationships using otptoken-add-managedby and >> otptoken-remove-managedby, but you can't actually see the list of >> managers. What am I missing? > > In the hbacrule or selinuxusermap plugins it is done by adding an "invisible" > param to the object plugin, like this: > > Str('managedby_user?', > label=_('Manager'), > flags=['no_create', 'no_update', 'no_search'], > ), > >> >> Also, it would be helpful if someone with DS expertise could answer the >> question about the performance of the ACI structure options as listed >> above. > > +1 CCing Ludwig to advise on the ACIs. Martin From lkrispen at redhat.com Thu Jun 5 09:27:40 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 05 Jun 2014 11:27:40 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538F43A6.3030501@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> Message-ID: <5390380C.3090004@redhat.com> On 06/04/2014 06:04 PM, thierry bordaz wrote: > On 06/04/2014 05:41 PM, Simo Sorce wrote: >> On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote: >>> On 06/04/2014 10:43 AM, thierry bordaz wrote: >>>>> So my proposal would contain the following components >>>>> >>>>> 1] Store replication configuration in the shared tree in a >>>>> combination of server and connection view (think we need both) and >>>>> map replication configuration to these entries. I would prefer a >>>>> direct mapping (with a subset of the cn=config attributes and >>>>> required additions) >>>> About adding a new server in the replication topology. >>>> If it was initialized, it may register itself into the shared tree and >>>> then join the topology. If it was not initialized, it can be >>>> initialized online by one of the master. Will it be triggered with an >>>> update to the shared tree ? >>> I think this has to be decided, I proposed some kind of bootstrapping: >>> If the topology plugin is enabled and started it would check if >>> there is >>> already info on the connections for this server and if not >>> create/update >>> the entry in the shared tree, this could also happen if a new server is >>> added. >> You mean updating the shared tree from information about replication >> agreements found in cn=config ? >> I can see how this would be useful in migration from previous server >> versions, but I fear would cause issues if you remove a connection when >> one of the 2 servers is down. >> When you bring the server up it would try to re-create a connection that >> was deleted by the admin. It's a catch-22 which is why I want the shared >> tree to be authoritative but not the cn=config tree. >> >>> But Simo wanted to have the info in the shared tree indepndent of what >>> was already configured. >> It's not much about being independent, it's about what is authoritative >> and what is not. >> >>> One problem with the automatic approach is what should be done if the >>> config differs on the already deployed servers >> That's just one of many problems. >> I think cn=config entries should be read an injected in the shared >> topology only once at upgrade time, but not anymore after. >> Maybe this calls for adding nodes to the topology tree, if the topology >> plugin starts and the server is not in the topology tree, then it >> sources the local configuration, then adds itself and the connections to >> the topology tree. >> If the node is already in the topology tree this step is always skipped. > I like the idea that the node can add itself and the connection to the > topology tree. > But this requires that the node database is already initialized (have > the same replicageneration than the others nodes). > If it is not initialized, it could be done by any masters. But if it > is automatic, there is a risk that several masters will want to > initialize it. I would not give the plugin the power to reinitialize a database on another server and I also would not put the responsibility to do it to the plugin. Initializing a server is an administrative task done at specific steps during deployment or in error conditions and most time has to be scheduled and often on-line initialization is not the preferred method. The plugin could still be used to trigger online initializations if the nsds5replicarefresh attribute is part of the information in the shared tree, it can be modified, the plugin on the targeted server will detect the change, update the replication agreement object and start the initialization (but this should probably still be allowed to be done directly). The question for me was more how the configuration information in the shared tree is initialized (not the full shared tree). We do agree that the info in the shared tree should be authoritative. To synchronize the info in the shared tree and cn=config I see two modes: "passive" mode: the sync is only from the shared tree to cn=config, it is the responsibility of an admin/tool to initialize the config in the shared tree "supporting" mode: if the plugin starts, it checks if the info in the shared tree exists, if not it initializes the topology info in the shared tree and then only reacts to changes in the shared tree. I prefer the "supporting" mode (if we find a better name), as long as no admin interferes the info in the shared tree and cn=config will be identical as they are set in a normal deployment, so no harm is done, but they are replicated and the full information is available on every server. > > In addition if the new node has a different replicageneration, how > does the new node know that it should wait to be initialized rather > than initialize the others. >> >> Or something similar (could be just a flag in cn=masters objects). >> >> makes sense ? >> >> Simo. >> > From tbordaz at redhat.com Thu Jun 5 10:55:18 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 05 Jun 2014 12:55:18 +0200 Subject: [Freeipa-devel] User life Cycle: referential integrity In-Reply-To: <1401901486.31205.3.camel@willson.usersys.redhat.com> References: <538F3F67.60804@redhat.com> <1401897764.28354.15.camel@willson.usersys.redhat.com> <538F4D6F.1090906@redhat.com> <1401901486.31205.3.camel@willson.usersys.redhat.com> Message-ID: <53904C96.205@redhat.com> On 06/04/2014 07:04 PM, Simo Sorce wrote: > On Wed, 2014-06-04 at 18:46 +0200, thierry bordaz wrote: >> On 06/04/2014 06:02 PM, Simo Sorce wrote: >>> On Wed, 2014-06-04 at 17:46 +0200, thierry bordaz wrote: >>>> Hello, >>>> >>>> I am looking at the appropriate way to configure DS >>>> referential integrity and I am hitting some issues about its >>>> scoping and which attributes need to be preserved. >>>> >>>> >>>> User A and B are both Active. User A refers user B for >>>> example 'owner: '. >>>> If entry A is deleted (user-del), it keeps 'owner: >>> in Active container>'. Do we really want to preserve such >>>> attributes (owner, member, seeAlso...) in case the user is >>>> coming back (user-undel) ? >>> No, when a user is deleted all references to it in the rest of the tree >>> should be removed. the entries "it" references can stay I guess, the >>> user is deleted so no harm should come from it having dangling DNs in >>> its attributes. >> Actually it was my concern. If users A then B are moved Active->Delete >> (user-del), then the reference to B in the 'Active' container is not >> removed by RI. If for any reason user A returns to Active (user-undel), >> it contains dangling DN unless it is checked/removed. >>>> If it makes sense we may achieve this if we extends RI to both >>>> 'Active' and 'Delete' container. >>> Nope, makes no sense. >>> >>>> If we prefer to remove such attributes, then 'user-del' is a >>>> MODRDN followed by some MODs or a ADD-DEL where the Delete >>>> entry is rebuilt from the 'Active' entry. >>> Delete must be a modrdn, we cannot delete the entry and re-add it. >> ok great :) >>>> This is a similar problem when using 'stageuser-add >>>> --from-delete', the references may become invalid (unless RI >>>> also covers Staging). >>> There should be no references in either staged or delete users, or they >>> should be adjusted when the user is unstaged/undeleted. >>> >>>> An option would be to accept to have invalid references in >>>> 'staging' and 'delete', but when the entry is >>>> stageuser-activate/user-undel the reference are checked and >>>> removed if invalid. Here invalid means, the referred entry >>>> does not exist or is not 'Active'. >>> Yup, this sounds right, when you "activate" the user references need to >>> be checked and adjusted accordingly. >> Which attributes need to be checked/adjusted ? those configured in RI ? >> attributes with DN syntax ? > Probably all the attrributes with DN syntax, I am partiocularly > concerned with memberof and manager. > but memberof should be removed automatically at delete time by the fact > the user should be removed from any group (does RI do this when an entry > moves out of scope ?) Yes that is correct. If the user is removed from the group, memberof plugin update the memberof attribute in the user entry. If the user is moved out of the scope then this is the RI that updates the 'member' attribute of the group and then memberof plugin updates 'memberof'. So a 'user-del' command removes all 'memberof' attribute. > > Manager if there should probably be adjusted, others should probably be > just wiped and let automember or other plugin or an admin fix whatever > need fixing ? Ok to keep Manager and remove others DN syntax attributes. > > Seem like a rathole especially if the user has an objectclass in ti the > has a DN containing attribute as MUST ... A possibility would be to keep those attributes and replace their values with a specific value (empty value ?) thierry > > We need to think of a sensible behavior when this happens as it could be > an additional custom class/attribute the admin added... > > Simo. > From simo at redhat.com Thu Jun 5 12:45:53 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Jun 2014 08:45:53 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <5390380C.3090004@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> Message-ID: <1401972353.21784.2.camel@willson.usersys.redhat.com> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: > On 06/04/2014 06:04 PM, thierry bordaz wrote: > > But this requires that the node database is already initialized (have > > the same replicageneration than the others nodes). > > If it is not initialized, it could be done by any masters. But if it > > is automatic, there is a risk that several masters will want to > > initialize it. > I would not give the plugin the power to reinitialize a database on > another server and I also would not put the responsibility to do it to > the plugin. Initializing a server is an administrative task done at > specific steps during deployment or in error conditions and most time > has to be scheduled and often on-line initialization is not the > preferred method. Agree. > The plugin could still be used to trigger online initializations if the > nsds5replicarefresh attribute is part of the information in the shared > tree, it can be modified, the plugin on the targeted server will detect > the change, update the replication agreement object and start the > initialization (but this should probably still be allowed to be done > directly). Nope, leave re-initialization to the plumbing. The topology plugin deals only with topology, it should not be involved with re-initializations, save for not going crazy and trying to remove agreements "during" a re-initialization. > The question for me was more how the configuration information in the > shared tree is initialized (not the full shared tree). > We do agree that the info in the shared tree should be authoritative. Yep. > To > synchronize the info in the shared tree and cn=config I see two modes: > "passive" mode: the sync is only from the shared tree to cn=config, it > is the responsibility of an admin/tool to initialize the config in the > shared tree This is my preferred, although leaves the problem open for migration, we need a way to properly prime the topology so that it doesn't wipe out current agreements before they are imported. > "supporting" mode: if the plugin starts, it checks if the info in the > shared tree exists, if not it initializes the topology info in the > shared tree and then only reacts to changes in the shared tree. I would like some more details about what you have in mind here, depending on the fine points I might agree this is desirable to solve the migration problem. > I prefer the "supporting" mode (if we find a better name), as long as no > admin interferes the info in the shared tree and cn=config will be > identical as they are set in a normal deployment, so no harm is done, > but they are replicated and the full information is available on every > server. Full topology information you mean here, right ? Simo. -- Simo Sorce * Red Hat, Inc * New York From lkrispen at redhat.com Thu Jun 5 13:14:11 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 05 Jun 2014 15:14:11 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401972353.21784.2.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> <1401972353.21784.2.camel@willson.usersys.redhat.com> Message-ID: <53906D23.2090107@redhat.com> On 06/05/2014 02:45 PM, Simo Sorce wrote: > On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: >> On 06/04/2014 06:04 PM, thierry bordaz wrote: >>> But this requires that the node database is already initialized (have >>> the same replicageneration than the others nodes). >>> If it is not initialized, it could be done by any masters. But if it >>> is automatic, there is a risk that several masters will want to >>> initialize it. >> I would not give the plugin the power to reinitialize a database on >> another server and I also would not put the responsibility to do it to >> the plugin. Initializing a server is an administrative task done at >> specific steps during deployment or in error conditions and most time >> has to be scheduled and often on-line initialization is not the >> preferred method. > Agree. > >> The plugin could still be used to trigger online initializations if the >> nsds5replicarefresh attribute is part of the information in the shared >> tree, it can be modified, the plugin on the targeted server will detect >> the change, update the replication agreement object and start the >> initialization (but this should probably still be allowed to be done >> directly). > Nope, leave re-initialization to the plumbing. The topology plugin deals > only with topology, it should not be involved with re-initializations, > save for not going crazy and trying to remove agreements "during" a > re-initialization. > >> The question for me was more how the configuration information in the >> shared tree is initialized (not the full shared tree). >> We do agree that the info in the shared tree should be authoritative. > Yep. > >> To >> synchronize the info in the shared tree and cn=config I see two modes: >> "passive" mode: the sync is only from the shared tree to cn=config, it >> is the responsibility of an admin/tool to initialize the config in the >> shared tree > This is my preferred, although leaves the problem open for migration, we > need a way to properly prime the topology so that it doesn't wipe out > current agreements before they are imported. > >> "supporting" mode: if the plugin starts, it checks if the info in the >> shared tree exists, if not it initializes the topology info in the >> shared tree and then only reacts to changes in the shared tree. > I would like some more details about what you have in mind here, > depending on the fine points I might agree this is desirable to solve > the migration problem. I will write it down for a few different scenarios. > >> I prefer the "supporting" mode (if we find a better name), as long as no >> admin interferes the info in the shared tree and cn=config will be >> identical as they are set in a normal deployment, so no harm is done, >> but they are replicated and the full information is available on every >> server. > Full topology information you mean here, right ? topology information (nodes and edges) and properties of the connections, eg replicated or stripped attributes > > Simo. > From pviktori at redhat.com Thu Jun 5 13:14:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Jun 2014 15:14:43 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <538EEA19.2000208@redhat.com> References: <538EEA19.2000208@redhat.com> Message-ID: <53906D43.2060707@redhat.com> On 06/04/2014 11:42 AM, Tomas Babej wrote: > Hi, > > the following set of patches implements the ticket: > > https://fedorahosted.org/freeipa/ticket/4052 > > The refactoring touches both server and client bits, main features are: > > * easier inheritance and creation of new platform modules > * all filesystem paths are defined as platform constants > * platform related functionality is implemented as transparent platform > tasks > (as opposed to platform dependent implementations) > * no need to implement your own authconfig class, since tasks encapsulate > the relevant parts of the code > > More documentation, mainly on the part of the documenting the tasks > contracts > and the creation of own platform modules should follow later. > Thanks for all the work! I didn't test yet; actually I haven't read it all yet, but sharing the first thoughts might make the review faster. If you'd rather have the whole thing, just wait :) 0202: OK 0203: Can we remove the leading underscores from `__wait_for_open_ports`? I don't think there's a good reason for that to be "private", let alone super-annoyingly "private". It would be nice to have the Services' __init__s take an optional `api` argument, and then use `self.api` everywhere. I'm certain we'd appreciate it in the future. In SystemdService.restart, I think the comment is obsolete by now. But If we want to keep it we should add a link to https://bugs.freedesktop.org/show_bug.cgi?id=39824 Also, it's pointless to just fix whitespace issues and line length. If you're cleaning up, please convert the code to actually idiomatic Python, otherwise these are just changes for the sake of change. (Or maybe for the sake of passing automated style checks, which is pretty stupid. The real issues are those the tool doesn't report. There's a nice summary on using the `pep8` tool like this in the last paragraph of http://bugs.python.org/msg193909.) In PlatformService.start, use `with` for open files. Also flush() is unnecessary before closing a file. In SystemdService.service_instance, len(string) == 0 translates to: not string In SystemdService.parse_variables, map(lambda x: y(x), z) translates to: [y(x) for x in z] (plus you can skip the [ ] since you don't need a list) In SystemdService.stop/start if 'context' in api.env and api.env.context in X: translates to: if getattr(api.env, 'context', None) in X: SystemdService.is_installed, the flag is not needed, just return directly. 0204: When commenting what a function does, use a docstring. 0205: OK 0206: OK 0207: In system_units: again, a generator expression is better than map(lambda, ...) In FedoraService.__init__, len(string.split(c)) == 1 translates to: c not in string In FedoraDirectoryService, the comment applies just to restart(), could you move it there? In FedoraDirectoryService.restart, there's `len(instance_name) > 0` again In FedoraCAService, can __wait_until_running have just one leading underscore? I don't think we need to hide it. In FedoraCAService.__wait_until_running, there are some hardcoded paths. Can we pull them from the paths module? It'll be easier to reuse if we ever find out the class applies to more than Fedora. (You could do it in some later patch of course.) 0208: Again some hardcoded paths, would be nice to pull them from the paths object I'm surprised you left the parentheses around `if` expressions, since you're so meticulous about whitespace and line length... check_selinux_status, in the RuntimeError message, assumes that it's called from an installation. This should at least be pointed out in the docstring. There's no newline at the end of the file. 0209: ipa-client-install, --noac help: "Red Hat" has two words. Also it's a company; I don't think "Red Hat based distributions" is a correct use of the trademark. In comments/class names it doesn't really matter but in user-facing text we should try to be professional. We can either go with "Fedora-based" here and sort this out in a RHEL patch if needed, or better, adjust the help text (or visibility of the option) based on if the platform uses authconfig. In configure_sshd_config, why did you remove `authorized_keys_changes = candidate`? base.tasks: These need docstrings. Will those included in the documentation that you want to provide later? base.{tasks,fedora}.restore_pre_ipa_client_configuration: line too long. You fix this in a later patch, why not here? Each of the functions configure_sssd_for_user_info_and_auth, configure_ldap_for_user_info, configure_auto_homedir_creation now execute authconfig. In the base.authconfig.Authconfig docstring, the example is wrong. In that docstring and in ipaplatform.fedora.tasks, instead of auth_config.enable("sssd").\ enable("sssdauth") please use auth_config.enable("sssd") auth_config.enable("sssdauth") In addition to PEP8 compliance (this is Python, not JQuery), it's more diff-friendly. Alternately, be pythonic and add support for: auth_config.enable("sssd", "sssdauth") auth_config.add_parameters(nisdomain=nisdomain): It seems that for every AuthConfig.execute(), you need to do auth_config.add_option("update") Why not roll that into execute(), with a (default) argument? AuthConfig.__build_args should lose the leading underscores. Nothing to hide here; according to the docstring it's even part of the public interface. I'd also move it (and execute()) to the base implementation, since it's quite unlikely that authconfig would use different arguments in other distros that support it (and they can override anyway). There's another hardcoded path, "/usr/sbin/authconfig". 0210: OK It might be good to point to this patch in some docs, there are some ideas for porting to System V distros. 0211: I believe ipaplatform.paths.path_namespace doesn't exist yet. Should these changes be in a later patch? I see more hardcodced paths. For logging, use multiple arguments instead of %, and str() is unnecessary, e.g.: root_logger.info("Failed to add CA to the systemwide " "CA trust database: %s", e) In backup_and_replace_hostname, please use the logger for the message, so it ends up a logfile. (Do it in addition to the print if the logger might be unconfigured.) In backup_and_replace_hostname, the `readlines` in `for line in f.readlines():` is unnecessary. 0212: OK 0213: OK 0214: OK 0215: Looks OK (pylint should be enough to check this, haven't run it yet) 0216: I see a lot of these lines: from ipaplatform.paths import path_namespace as paths I don't think it's healthy to have an object that you *always* import as another name (actually in a single codebase we shouldn't need renaming objects on import at all, but that would be a very minor nitpick). We had some discussions about this, maybe I gave you the idea; sorry for any miscommunication. (I was mostly scared at wanting to redefine a module's __getattr__, which is some seriously arcane magic -- you should only try it at home.) You can do better by just placing the class in a convenient place: /paths_module.py: class PathsNamespace(object): ... ipaplatform/paths_module.py ? /paths_module.py ipaplatform/__init__.py: from ipaplatform.paths_module import PathsNamespace paths = PathsNamespace() any other module: from ipaplatform import paths mkdir(paths.IMPORTANT_DIR) ipalib/__init__.py: I think your regex got too hungry here... I'd add a _TEMPLATE suffix to names of "paths" containing %s, to make it clear what they are. (note to self: I'm at line 1500 of the patch) --- When moving code around you remove the Authors: lines from the top of the files, and replace them with yourself. I don't think that's a fair thing to do. -- Petr? From edewata at redhat.com Thu Jun 5 14:25:48 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 05 Jun 2014 09:25:48 -0500 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <53874C4A.3020402@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> Message-ID: <53907DEC.8050106@redhat.com> ACK for patches #592-#628. I'll continue reviewing the rest. There are some minor/unrelated issues I found while testing but they can be addressed separately: 1. In the login page the message says "To login with username and password, enter them in the fields below," but the fields are actually displayed on the left of the message in desktop mode (big screen) or above the message in mobile mode (small screen). 2. If there's a login error, the logo and the message shifts up. I think it would be nicer to display the error without changing the layout of the original page. 3. In the login page the "configured" link goes to unauthorized.html which displays "Unable to verify your Kerberos credentials" message. I think people expect to see an instruction to configure the browser, not an error message. 4. In the list page (e.g. Users) in mobile mode the Refresh button may overlap the search box. 5. In mobile mode the list table loses the outer border. Is this intentional? If so, maybe the left/right margin could be removed as well to maximize the horizontal space. 6. In desktop mode if the page is narrower than a certain width the table cell content may wrap (i.e. "First name" will be displayed in 2 lines). 7. If the list table is empty, the cell borders disappear (see Host Groups page). 8. In mobile mode if you click the menu icon on the top right there will be 2 scrollbars, one for the whole page, and one for the menu itself. I think in mobile mode the menu should occupy the entire page, so there's only one scrollbar. 9. In mobile mode if you select Policy from the menu it will show the HBAC Rules page. Similarly, if you click IPA Server it will show the Roles page. This can be confusing since in mobile mode we don't see the navigation hierarchy. Probably the breadcrumb needs to include the full hierarchy (e.g. Policy >> HBAC >> Rules). Alternatively, the menu items that don't have a corresponding page shouldn't be clickable. 10. In mobile mode the Available and Prospective tables in the association dialog are arranged vertically, but the Add and Delete arrows are still pointing horizontally. 11. In desktop mode the QR code for new OTP token is displayed outside the dialog box. 12. There seems to be a caching issue. I added a user, then I added an automember rule that will add the user to a group. When I opened the user details page initially, the "User Groups" tab header was showing it's a member of 1 group. Then I rebuilt auto membership and reopened the page, it's still showing 1 group. Then I clicked another tab (e.g. Netgroups) it's now showing 2 groups. But if I clicked "User Groups" tab it went back to 1 group. To get the right info I had to click Refresh. I think the counter in the tab header should be based on the cached tab content. Alternatively, rebuilding automember should invalidate the cache. -- Endi S. Dewata From lkrispen at redhat.com Thu Jun 5 14:46:48 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Thu, 05 Jun 2014 16:46:48 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <53906D23.2090107@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> <1401972353.21784.2.camel@willson.usersys.redhat.com> <53906D23.2090107@redhat.com> Message-ID: <539082D8.5060109@redhat.com> On 06/05/2014 03:14 PM, Ludwig Krispenz wrote: > > On 06/05/2014 02:45 PM, Simo Sorce wrote: >> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: >>> On 06/04/2014 06:04 PM, thierry bordaz wrote: >>>> But this requires that the node database is already initialized (have >>>> the same replicageneration than the others nodes). >>>> If it is not initialized, it could be done by any masters. But if it >>>> is automatic, there is a risk that several masters will want to >>>> initialize it. >>> I would not give the plugin the power to reinitialize a database on >>> another server and I also would not put the responsibility to do it to >>> the plugin. Initializing a server is an administrative task done at >>> specific steps during deployment or in error conditions and most time >>> has to be scheduled and often on-line initialization is not the >>> preferred method. >> Agree. >> >>> The plugin could still be used to trigger online initializations if the >>> nsds5replicarefresh attribute is part of the information in the shared >>> tree, it can be modified, the plugin on the targeted server will detect >>> the change, update the replication agreement object and start the >>> initialization (but this should probably still be allowed to be done >>> directly). >> Nope, leave re-initialization to the plumbing. The topology plugin deals >> only with topology, it should not be involved with re-initializations, >> save for not going crazy and trying to remove agreements "during" a >> re-initialization. >> >>> The question for me was more how the configuration information in the >>> shared tree is initialized (not the full shared tree). >>> We do agree that the info in the shared tree should be authoritative. >> Yep. >> >>> To >>> synchronize the info in the shared tree and cn=config I see two modes: >>> "passive" mode: the sync is only from the shared tree to cn=config, it >>> is the responsibility of an admin/tool to initialize the config in the >>> shared tree >> This is my preferred, although leaves the problem open for migration, we >> need a way to properly prime the topology so that it doesn't wipe out >> current agreements before they are imported. >> >>> "supporting" mode: if the plugin starts, it checks if the info in the >>> shared tree exists, if not it initializes the topology info in the >>> shared tree and then only reacts to changes in the shared tree. >> I would like some more details about what you have in mind here, >> depending on the fine points I might agree this is desirable to solve >> the migration problem. > I will write it down for a few different scenarios. looks like this could get ugly, if the topology info initialization would happen on several masters at the same time, they would create the same entries (at least the config root container) and we could get replication conflicts :-( we need to be careful on the process, I have an idea how it could work, but need to think a bit more about it >> >>> I prefer the "supporting" mode (if we find a better name), as long >>> as no >>> admin interferes the info in the shared tree and cn=config will be >>> identical as they are set in a normal deployment, so no harm is done, >>> but they are replicated and the full information is available on every >>> server. >> Full topology information you mean here, right ? > topology information (nodes and edges) and properties of the > connections, eg replicated or stripped attributes >> >> Simo. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Thu Jun 5 17:12:42 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Jun 2014 13:12:42 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <539082D8.5060109@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> <1401972353.21784.2.camel@willson.usersys.redhat.com> <53906D23.2090107@redhat.com> <539082D8.5060109@redhat.com> Message-ID: <1401988362.26048.2.camel@willson.usersys.redhat.com> On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote: > On 06/05/2014 03:14 PM, Ludwig Krispenz wrote: > > > > On 06/05/2014 02:45 PM, Simo Sorce wrote: > >> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: > >>> On 06/04/2014 06:04 PM, thierry bordaz wrote: > >>>> But this requires that the node database is already initialized (have > >>>> the same replicageneration than the others nodes). > >>>> If it is not initialized, it could be done by any masters. But if it > >>>> is automatic, there is a risk that several masters will want to > >>>> initialize it. > >>> I would not give the plugin the power to reinitialize a database on > >>> another server and I also would not put the responsibility to do it to > >>> the plugin. Initializing a server is an administrative task done at > >>> specific steps during deployment or in error conditions and most time > >>> has to be scheduled and often on-line initialization is not the > >>> preferred method. > >> Agree. > >> > >>> The plugin could still be used to trigger online initializations if the > >>> nsds5replicarefresh attribute is part of the information in the shared > >>> tree, it can be modified, the plugin on the targeted server will detect > >>> the change, update the replication agreement object and start the > >>> initialization (but this should probably still be allowed to be done > >>> directly). > >> Nope, leave re-initialization to the plumbing. The topology plugin deals > >> only with topology, it should not be involved with re-initializations, > >> save for not going crazy and trying to remove agreements "during" a > >> re-initialization. > >> > >>> The question for me was more how the configuration information in the > >>> shared tree is initialized (not the full shared tree). > >>> We do agree that the info in the shared tree should be authoritative. > >> Yep. > >> > >>> To > >>> synchronize the info in the shared tree and cn=config I see two modes: > >>> "passive" mode: the sync is only from the shared tree to cn=config, it > >>> is the responsibility of an admin/tool to initialize the config in the > >>> shared tree > >> This is my preferred, although leaves the problem open for migration, we > >> need a way to properly prime the topology so that it doesn't wipe out > >> current agreements before they are imported. > >> > >>> "supporting" mode: if the plugin starts, it checks if the info in the > >>> shared tree exists, if not it initializes the topology info in the > >>> shared tree and then only reacts to changes in the shared tree. > >> I would like some more details about what you have in mind here, > >> depending on the fine points I might agree this is desirable to solve > >> the migration problem. > > I will write it down for a few different scenarios. > looks like this could get ugly, if the topology info initialization > would happen on several masters at the same time, they would create the > same entries (at least the config root container) and we could get > replication conflicts :-( This is exactly why I said I do not want the plugin to create the topology tree itself :-) It should only import agreements that are not yet there. There is still potential conflict, the topology plugin will have to handle them, by intercepting replication writes to the topology tree and smartly merging/fencing IMO. > we need to be careful on the process, I have an idea how it could work, > but need to think a bit more about it I am all ears. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Jun 5 21:15:13 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jun 2014 17:15:13 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <1401912616.597.7.camel@willson.usersys.redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> <1401912616.597.7.camel@willson.usersys.redhat.com> Message-ID: <5390DDE1.1010502@redhat.com> On 06/04/2014 04:10 PM, Simo Sorce wrote: > On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote: >> On 06/04/2014 05:35 PM, Simo Sorce wrote: >>> On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: >>>> On 06/04/2014 08:34 AM, Martin Kosek wrote: >>>> ... >>>>> Users >>>>> - Users >>>>> - Groups >>>>> - SUDO >>>>> >>>>> Hosts >>>>> - Hosts >>>>> - Host groups >>>>> - Services >>>>> - Netgroups >>>>> - Automount >>>>> >>>>> Authentication >>>>> - OTP Tokens >>>>> - Password Policy >>>>> - Kerberos Ticket Policy >>>>> >>>>> Policy >>>>> - HBAC >>>>> - SELinux User Maps >>>>> - Automember >>>> Alternatively, we could rename Policy to "Authorization" as both HBAC and >>>> SELinux is about authorizing what an authenticated user can do. We would just >>>> need to move Automember to different place, though this one is difficult - it >>>> relates both to Users and Hosts, just like Netgroup. >>> I do not see the need to do Policy -> Authorization but Automember is in >>> the wrong place imo. >>> >>> The first tab should be Users -> Accounts and include automember in it >>> as automember is about groupings ? >>> >>> Actually I would merge the current Users and Hosts tabs into >>> 'Accounts' (or maybe 'Identities' ?) and add Automember. >>> >>> Simo. >>> >> Automember is about grouping both users and hosts. I put it under Policy >> originally as it basically is a policy, when are certain users/hosts automember'ed. >> >> I would personally not merge Users and Hosts top level menus to one top level >> menu as that would spoil the whole reason why this effort is done, i.e. have at >> most 7 items in the second level bar to make things clearer. >> >> To me, it seemed a good idea to split Users and Hosts to achieve the target as >> it separates well the intent what one wants to do. Now we have it all under >> Identity (including DNS and Realm Domains) which is messy. > Unfortunately some of your groupings make little sense to me: > - why is SUDO under Users ?? > It's a security policy and those policies are equally related to users, > groups and hosts. > - why "policies" are under authentication ? > Both password policies and Kerberos Ticket policies have nothing to do > with the authentication part, but with changing password and with which > features are allowed on tickets. > - why automember is in Policy ? > It is just autoconfiguration it doesn't enforce any policy on its own > >> But I am pretty open to counter-proposals which keeps the UX requirement of 7 >> second level items. >> >> Martin > This is how it makes sense to me as a logical grouping: > > Accounts/Identity (7): > - Users > - Groups > - Hosts > - Host Groups > - Netgroups > - Services > - Automember > > ^ These are all identity or identity-grouping related objects/actions +1 > > Policies (6): > - Sudo > - HBAC > - SELinux User Maps > - OTP Tokens (*) > - Password Policies > - Kerberos ticket Policies > > ^ These are all Security Policies an admin cares about +1, with the note, i.e. OTP does not belong there > > Directory (6): > - Permissions > - Privileges > - Roles > - Delegation > NOTE: the 4 above can be merged into a single 'Authorization' entry > perhaps May be it should be and "Administration" tab, I do not like the title. I understand where the directory comes from but this is IMo not intuitive for someone who does not know what is under the hood. > - Replication Topology > - Views (future) > > ^ Everything that deals with direct LDAP access/view I think views do not belong here. They belong in the same place where the trusts are. > > Network Services (4): > - Automount > - DNS > - CA > - Vault (future) > > ^ All the additional network services or configuration of network > related services +1 > > Configuration (3): > - Trusts > - ID Ranges > - Realm Domains > - Global > > ^ Anything that does not fit the above categories. +1 > > Docs: > - whatever :) > > > (*) The only doubt I have is about OTP Tokens, it may be worth taking > them off Policies and putting them into a new tab which in future may > also sport a pointer to user certificates management: Yeah, may be for now we put OTP as a top level for now and have tokens and create a RADIUS page to manage radius proxies? In future when we add other credentials we can rename it and add smart card related options. > > Authentication: > - OTP Tokens > - User Certificates (future) > > > HTH, > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Jun 5 22:36:20 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Jun 2014 18:36:20 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1401988362.26048.2.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> <1401972353.21784.2.camel@willson.usersys.redhat.com> <53906D23.2090107@redhat.com> <539082D8.5060109@redhat.com> <1401988362.26048.2.camel@willson.usersys.redhat.com> Message-ID: <5390F0E4.3080703@redhat.com> On 06/05/2014 01:12 PM, Simo Sorce wrote: > On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote: >> On 06/05/2014 03:14 PM, Ludwig Krispenz wrote: >>> On 06/05/2014 02:45 PM, Simo Sorce wrote: >>>> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: >>>>> On 06/04/2014 06:04 PM, thierry bordaz wrote: >>>>>> But this requires that the node database is already initialized (have >>>>>> the same replicageneration than the others nodes). >>>>>> If it is not initialized, it could be done by any masters. But if it >>>>>> is automatic, there is a risk that several masters will want to >>>>>> initialize it. >>>>> I would not give the plugin the power to reinitialize a database on >>>>> another server and I also would not put the responsibility to do it to >>>>> the plugin. Initializing a server is an administrative task done at >>>>> specific steps during deployment or in error conditions and most time >>>>> has to be scheduled and often on-line initialization is not the >>>>> preferred method. >>>> Agree. >>>> >>>>> The plugin could still be used to trigger online initializations if the >>>>> nsds5replicarefresh attribute is part of the information in the shared >>>>> tree, it can be modified, the plugin on the targeted server will detect >>>>> the change, update the replication agreement object and start the >>>>> initialization (but this should probably still be allowed to be done >>>>> directly). >>>> Nope, leave re-initialization to the plumbing. The topology plugin deals >>>> only with topology, it should not be involved with re-initializations, >>>> save for not going crazy and trying to remove agreements "during" a >>>> re-initialization. >>>> >>>>> The question for me was more how the configuration information in the >>>>> shared tree is initialized (not the full shared tree). >>>>> We do agree that the info in the shared tree should be authoritative. >>>> Yep. >>>> >>>>> To >>>>> synchronize the info in the shared tree and cn=config I see two modes: >>>>> "passive" mode: the sync is only from the shared tree to cn=config, it >>>>> is the responsibility of an admin/tool to initialize the config in the >>>>> shared tree >>>> This is my preferred, although leaves the problem open for migration, we >>>> need a way to properly prime the topology so that it doesn't wipe out >>>> current agreements before they are imported. >>>> >>>>> "supporting" mode: if the plugin starts, it checks if the info in the >>>>> shared tree exists, if not it initializes the topology info in the >>>>> shared tree and then only reacts to changes in the shared tree. >>>> I would like some more details about what you have in mind here, >>>> depending on the fine points I might agree this is desirable to solve >>>> the migration problem. >>> I will write it down for a few different scenarios. >> looks like this could get ugly, if the topology info initialization >> would happen on several masters at the same time, they would create the >> same entries (at least the config root container) and we could get >> replication conflicts :-( > This is exactly why I said I do not want the plugin to create the > topology tree itself :-) > > It should only import agreements that are not yet there. There is still > potential conflict, the topology plugin will have to handle them, by > intercepting replication writes to the topology tree and smartly > merging/fencing IMO. > >> we need to be careful on the process, I have an idea how it could work, >> but need to think a bit more about it > I am all ears. > > Simo. > We already have several situations (CRL, DNSSEC, cert rotation) where a single server has to do the job first and all the rest should rely on that. We can simply our life by making the initialization a special admin initialized operation for the situations when we upgrade from earlier versions. So general topology plugin does not initialize anything automatically. If we build a new deployment the ipa replica management tools will drive the modifications as servers are added. If it is an upgrade admin might go to IPA configuration and ray build/rebuild topology. This will drop all segment information if there is any and using master list from cn=masters connect to each replica, query its replication agreements and create data for the replicated tree. If some replica is not on line the operation will report that replica can be connected and that topology is not complete. I think this is acceptable for topology plugin to focus only on keeping data in sync when replica management tools are invoked and mot worry about initialization after migration. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From redhatrises at gmail.com Fri Jun 6 06:36:19 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 6 Jun 2014 00:36:19 -0600 Subject: [Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env Message-ID: Hello, Patch 21: This is a patch for https://fedorahosted.org/freeipa/ticket/3724 Patch 22: This is part of https://fedorahosted.org/freeipa/ticket/4316 and adds the API to 'ipa env' One question that I had for adding 'ipa --version' is if using the default optparse version argument would be sufficient/intended i.e. version=('Version: %s, API_Version: %s' % (version, api_version) or if a custom optparse argument is needed. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0021-ipautil.run-args-log-message-is-confusing.patch Type: text/x-patch Size: 919 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0022-Add-API-version-to-env.patch Type: text/x-patch Size: 1069 bytes Desc: not available URL: From pspacek at redhat.com Fri Jun 6 07:43:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Jun 2014 09:43:50 +0200 Subject: [Freeipa-devel] Wikipedia articles mentioning FreeIPA Message-ID: <53917136.1080800@redhat.com> Hello list, I accidentally came across RHEV wikipedia articles mentioning FreeIPA: https://en.wikipedia.org/wiki/FreeIPA https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization Those articles could use attention of wordsmith :-) I'm not saying it should be full of marketing buzzwords, it should be factually correct. https://en.wikipedia.org/wiki/FreeIPA says: "FreeIPA aims to provide support not just for Linux and Unix based computers but ultimately Microsoft Windows and Apple Macintosh computers also." https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization says: "It can acquire user and group information from an Active Directory service or FreeIPA Active Directory emulator," Have a nice day! -- Petr^2 Spacek From pviktori at redhat.com Fri Jun 6 07:58:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Jun 2014 09:58:29 +0200 Subject: [Freeipa-devel] Wikipedia articles mentioning FreeIPA In-Reply-To: <53917136.1080800@redhat.com> References: <53917136.1080800@redhat.com> Message-ID: <539174A5.7040407@redhat.com> On 06/06/2014 09:43 AM, Petr Spacek wrote: > Hello list, > > I accidentally came across RHEV wikipedia articles mentioning FreeIPA: > https://en.wikipedia.org/wiki/FreeIPA > https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization > > Those articles could use attention of wordsmith :-) I'm not saying it > should be full of marketing buzzwords, it should be factually correct. > > > https://en.wikipedia.org/wiki/FreeIPA > says: > "FreeIPA aims to provide support not just for Linux and Unix based > computers but ultimately Microsoft Windows and Apple Macintosh computers > also." > > > https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization > says: > "It can acquire user and group information from an Active Directory > service or FreeIPA Active Directory emulator," > > Have a nice day! > Note that if you're a FreeIPA developer, especially a paid one, you should read Wikipedia's Conflict of Interest page carefully before (not) editing those pages. http://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest -- Petr? From mkosek at redhat.com Fri Jun 6 08:30:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jun 2014 10:30:34 +0200 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <1401499643.3590.39.camel@willson.li.ssimo.org> References: <1401499643.3590.39.camel@willson.li.ssimo.org> Message-ID: <53917C2A.9060702@redhat.com> On 05/31/2014 03:27 AM, Simo Sorce wrote: > I have rebased theold patch attached to the ticket, unfortunately I > haven't had time to test it yet, but didn't want to lose it in some > branch. > > Simo. I tested the patch and it worked fine, code also reads OK. Thus, I am willing to ACK it. I am just wondering if there is any scenario we could have missed, but I did not find any. In there is no push back against the patch I may just push it. Martin From mkosek at redhat.com Fri Jun 6 09:38:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Jun 2014 11:38:28 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed In-Reply-To: <538F4CA1.4070501@redhat.com> References: <538F4CA1.4070501@redhat.com> Message-ID: <53918C14.2080204@redhat.com> On 06/04/2014 06:43 PM, Petr Viktorin wrote: > Hello, > I try to think about any kind of data the user might have in LDAP, but in the > spirit of YAGNI, I'll deal with the various corner cases in IPA's historic > default permissions as I go along. > > Patch 0568 adds support for the case where the default permissions changed in > something else than attribute lists. Needed for the 'Change User password' > permission. > > Patch 0569 converts user permissions to managed. > > Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697 1) Add aci has targetfilter part - is that intentional? # ipa permission-show 'System: Add Users' --all --raw ... aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "permission:System: Add Users";allow (add) groupdn = "ldap:///cn=System: Add Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test";) This part IS effective though, so it may not be a bad thing at all, to keep it in the ACI: # ldapadd -Y GSSAPI SASL/GSSAPI authentication started SASL username: fbar at MKOSEK-FEDORA20.TEST SASL SSF: 56 SASL data security layer installed. dn: cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test objectclass: top objectclass: nscontainer cn: foo adding new entry "cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test" ldap_add: Insufficient access (50) additional info: Insufficient 'add' privilege to add the entry 'cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test'. # ipa user-add --first=Foo --last Bar fbar2 ------------------ Added user "fbar2" ------------------ User login: fbar2 First name: Foo ... 2) System: Add User to default group I was wondering whether we should keep the ACI in cn=groups container or directly with the group, but I think the group itself is a good idea. (Unless someone deletes and recreates it). 3) System: Change User password I hit some nasty DS error which prevented authorized user to update password. ACI log attached. Ludwig, does that ring any bell? The ACI itself looks OK though as after I restarted DS, it started to work. Maybe DS did not cache the ACIs properly after upgrade? 4) When running user unit tests, I found couple issues: a) Some attributes we may still miss in the permissions: - krbPrincipalExpiration - userclass - ipaUserAuthType - preferredLanguage I am thinking we could base Modify Users permission on the read one and add regular attributes there b) Read membership ACIs for users and groups miss "member" attribute and thus indirect/direct processing goes wrong. This is all I could find, patches are looking good, otherwise. Martin -------------- next part -------------- [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=742 (main): Allow search on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=krbtgt/mkosek-fedora20.test at mkosek-fedora20.test,cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=743 (main): Allow search on entry(cn=ipaconfig,cn=etc,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=ipaconfig,cn=etc,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=ipaconfig,cn=etc,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=ipaconfig,cn=etc,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=744 (main): Allow search on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=744 (main): Allow search on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=744 (main): Allow search on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=744 (main): Allow search on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=744 (main): Allow search on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(krbprincipalname=ldap/ipa.mkosek-fedora20.test at mkosek-fedora20.test,cn=services,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=745 (main): Allow search on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=746 (main): Allow search on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=746 (main): Allow search on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=746 (main): Allow search on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - conn=4 op=747 (main): Allow search on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:16 +0200] NSACLPlugin - Root access (read) allowed on entry(cn=mkosek-fedora20.test,cn=kerberos,dc=mkosek-fedora20,dc=test) [06/Jun/2014:11:17:17 +0200] NSACLPlugin - conn=87 op=4 (main): Allow write on entry(uid=fbar2,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test): root user [06/Jun/2014:11:17:17 +0200] NSACLPlugin - acl_init_userGroup: found in cache for dn:uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:17 +0200] NSACLPlugin - #### conn=87 op=4 binddn="uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test" [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Searching AVL tree for update:uid=fbar2,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test: container:-1 [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Searching AVL tree for update:cn=users,cn=accounts,dc=mkosek-fedora20,dc=test: container:4 [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Searching AVL tree for update:cn=accounts,dc=mkosek-fedora20,dc=test: container:3 [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Searching AVL tree for update:dc=mkosek-fedora20,dc=test: container:2 [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Searching AVL tree for update:dc=test: container:-1 [06/Jun/2014:11:17:17 +0200] NSACLPlugin - ************ RESOURCE INFO STARTS ********* [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Client DN: uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:17 +0200] NSACLPlugin - resource type:256(write target_DN ) [06/Jun/2014:11:17:17 +0200] NSACLPlugin - Slapi_Entry DN: uid=fbar2,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:17 +0200] NSACLPlugin - ATTR: krbPrincipalKey [06/Jun/2014:11:17:18 +0200] NSACLPlugin - rights:write [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ************ RESOURCE INFO ENDS ********* [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Using ACL Container:0 for evaluation [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Using ACL Container:1 for evaluation [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Using ACL Container:2 for evaluation [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***BEGIN ACL INFO[ Name: "permission:System: Change User password"]*** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACL Index:272 ACL_ELEVEL:6 [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI type:(write target_attr acltxt allow_rule ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI RULE type:(groupdn ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Slapi_Entry DN:cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***END ACL INFO***************************** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***BEGIN ACL INFO[ Name: "permission:System: Change User password"]*** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACL Index:273 ACL_ELEVEL:6 [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI type:(write target_attr acltxt allow_rule ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI RULE type:(groupdn ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Slapi_Entry DN:cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***END ACL INFO***************************** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***BEGIN ACL INFO[ Name: "selfservice:Self can write own password"]*** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACL Index:42 ACL_ELEVEL:7 [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI type:(write target_attr acltxt allow_rule ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI RULE type:(userdn ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Slapi_Entry DN:dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***END ACL INFO***************************** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***BEGIN ACL INFO[ Name: "Admins can write passwords"]*** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACL Index:43 ACL_ELEVEL:6 [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI type:(write delete add target_attr acltxt allow_rule ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ACI RULE type:(groupdn ) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Slapi_Entry DN:dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - ***END ACL INFO***************************** [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Num of ALLOW Handles:4, DENY handles:0 [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Processed attr:krbPrincipalKey for entry:uid=fbar2,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(272) " "permission:System: Change User password"" [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluating user uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test in group cn=System: Change User password,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test? [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrator,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Read User Kerberos Login Attributes,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Modify Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=RBAC Readers,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=System: Read Roles,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=System: Change User password,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - GroupEval:Looked at too many entries:(0, 1) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluated ACL_DONT_KNOW [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Returning UNDEFINED for groupdn evaluation. [06/Jun/2014:11:17:18 +0200] NSACLPlugin - 2. Evaluating ALLOW aci(42) " "selfservice:Self can write own password"" [06/Jun/2014:11:17:18 +0200] NSACLPlugin - 3. Evaluating ALLOW aci(273) " "permission:System: Change User password"" [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluating user uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test in group cn=System: Change User password,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test? [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrator,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Read User Kerberos Login Attributes,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Modify Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=RBAC Readers,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=System: Read Roles,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=System: Change User password,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - GroupEval:Looked at too many entries:(0, 1) [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluated ACL_DONT_KNOW [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Returning UNDEFINED for groupdn evaluation. [06/Jun/2014:11:17:18 +0200] NSACLPlugin - 4. Evaluating ALLOW aci(43) " "Admins can write passwords"" [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluating user uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test in group cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test? [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrator,cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=User Administrators,cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Read User Kerberos Login Attributes,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- In cn=System: Modify Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in uid=admin,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - -- Not in cn=admins,cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test [06/Jun/2014:11:17:18 +0200] NSACLPlugin - Evaluated ACL_FALSE [06/Jun/2014:11:17:18 +0200] NSACLPlugin - conn=87 op=4 (main): Deny write on entry(uid=fbar2,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test).attr(krbPrincipalKey) to uid=fbar,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test: no aci matched the subject by aci(43): aciname= "Admins can write passwords", acidn="dc=mkosek-fedora20,dc=test" From lkrispen at redhat.com Fri Jun 6 10:13:25 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 06 Jun 2014 12:13:25 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <5390F0E4.3080703@redhat.com> References: <538C39F6.2080006@redhat.com> <538EDC3C.1070301@redhat.com> <538F0724.2020600@redhat.com> <1401896497.28354.8.camel@willson.usersys.redhat.com> <538F43A6.3030501@redhat.com> <5390380C.3090004@redhat.com> <1401972353.21784.2.camel@willson.usersys.redhat.com> <53906D23.2090107@redhat.com> <539082D8.5060109@redhat.com> <1401988362.26048.2.camel@willson.usersys.redhat.com> <5390F0E4.3080703@redhat.com> Message-ID: <53919445.20107@redhat.com> >> >>> we need to be careful on the process, I have an idea how it could work, >>> but need to think a bit more about it >> I am all ears. >> >> Simo. >> > We already have several situations (CRL, DNSSEC, cert rotation) where > a single server has to do the job first and all the rest should rely > on that. > We can simply our life by making the initialization a special admin > initialized operation for the situations when we upgrade from earlier > versions. > So general topology plugin does not initialize anything automatically. > If we build a new deployment the ipa replica management tools will > drive the modifications as servers are added. > If it is an upgrade admin might go to IPA configuration and ray > build/rebuild topology. This will drop all segment information if > there is any and using master list from cn=masters connect to each > replica, query its replication agreements and create data for the > replicated tree. If some replica is not on line the operation will > report that replica can be connected and that topology is not complete. > I think this is acceptable for topology plugin to focus only on > keeping data in sync when replica management tools are invoked and mot > worry about initialization after migration. > I finally agree, especially after having done some experiments with a rapid prototype. If the topology plugin is started before the replication plugin and does changes to the shared tree, these are not replicated. If the topology plugin is started after the replication plugin I get a failure in replication that no csn is assigned, and the startup of the topology plugin fails. These might be bugs to be resolved, but I think I will follow Dmitri's scenario for now - improvements can come later From purpleidea at gmail.com Fri Jun 6 10:38:10 2014 From: purpleidea at gmail.com (James) Date: Fri, 6 Jun 2014 06:38:10 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet Message-ID: Hi FreeIPA, *intro* As some of you might know, I'm currently working on deploying multi-master replicas with puppet. Since it looks like there will be security implications, I wanted to start off by trying to build some confidence. I want to demonstrate that I am as paranoid about getting the security bits right as you all are. *cough* I'm looking at you Simo ;) I've just announced the first sane implementation for secret handling in puppet. Since everyone does this wrong, I thought I'd do it right, by pioneering a new technique. You can read about it here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ In short, the dm_password and admin_password never get touched by puppet, and are generated locally on the freeipa server. What this means is that puppet doesn't know what they are, and as a result, can't use them to accomplish admin tasks. *replicas* ipa-replica-prepare and ipa-replica-install work _too_ well. they're the one part of freeipa that are so easy to use by a human, but nearly impossible to use with puppet (without storing the password in puppet). puppet can't use them as is because they need you to enter a password (which i don't want it to have). Here is what I propose to do for accomplishing this. Please correct me if I've made a mistake, or recommend something different. ipa-replica-prepare seems to need the dm_password. This seems to be needed for symmetrically encrypting the bunch of files to transfer to the replica. Instead, I'll patch this process to allow use of a public key for asymetric encryption that is unique to the receiving replica. I'll make sure that each ipa server generates it's own keypair, and that the public halves are distributed to the sending hosts. I don't think there is any other need for the dm_password in ipa-replica-prepare. Did I miss something? ipa-replica-install needs the dm_password to decrypt the gpg file. Since I'm handling that with my asymmetric key pair, we don't need the password for that. mkosek was very kind in helping me dig through this part a bit, and it seems that the dm_password is needed to allow the replica to bind to the first server. I would need some help to find an alternative for this process. As was suggested, perhaps a one-time password could be generated and sent across the wire (with puppet) to the replica. Any mechanism that doesn't need the dm_password would be great. I don't think there is any other need for the dm_password in ipa-replica-install. Did I miss something? Of course if I store the dm_password in puppet, then it's easy to do this peering because it will be easy to use the password on each host. I could be done my puppet module already :) But I'm going out of my way to do it right, so that you'll all be proud of the work too! *symmetry* It would be especially elegant and beneficial to FreeIPA and the puppet module if the process of "peering" was symmetrical, that is to say, similar for any host. If I could use ipa-server-install to setup N hosts, and then run a secondary command to cause certain ones to "join" this would make the process much more natural for puppet. In addition, this would ensure that the configuration management itself is HA. Without this type of functionality, then if the first ipa server isn't available, then config management will be blocked. I would appreciate any recommendations on how to convert a previously installed ipa server into a replica. Of course it's fine that it will have it's data overwritten. Thanks again! Cheers, James From jcholast at redhat.com Fri Jun 6 10:50:49 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Jun 2014 12:50:49 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <52E11A60.10901@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> Message-ID: <53919D09.20302@redhat.com> On 23.1.2014 14:34, Jan Cholasta wrote: > On 22.1.2014 16:43, Simo Sorce wrote: >> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>> On 22.1.2014 15:34, Simo Sorce wrote: >>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>> Later in the patch you seem to be changing from needing >>>>>> managedby_host >>>>>> to needing write access to an entry, I am not sure I understand >>>>>> why that >>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>> original >>>>>> check is not right anymore ? >>>>> >>>>> The original check is wrong, see >>>>> . >>>>> >>>>> The check in my patch allows SAN only if the requesting host has write >>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>> right, but even if it is not, I think we should still check for write >>>>> access to the SAN services, so that access control can be (partially) >>>>> handled by ACIs. >>>> >>>> Right, I remembered that comment, but it just says to check the right >>>> object's managed-by, here instead you changed it to check if you can >>>> write the usercertificate. >>>> >>>> I guess it is the same *if* there is an ACI that gives write permission >>>> when the host is in the managed-by attribute, is that the reasoning ? >>> >>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>> service Certificates and kerberos keys" and "Hosts can manage other host >>> Certificates and kerberos keys". >>> >>> I think the check can be extended to users as well, so that requesting >>> certificate with SAN is allowed only to users which have write access to >>> the SAN services. > > I have done the modification, see attached patches. > >> >> Sounds good to me then, thanks for explaining. >> >> The patches also look good, but I would like someone to give them a try >> for a formal ack. > > OK, thanks. > Bump. I have added stricter validation of subject alt names as well as certificate extensions in general to the second patch. Updated patches attached. Note that you will need python-nss 0.15 in order to test, you can get a RPM for Fedora here: . Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work, because . -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.4-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.4-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 11151 bytes Desc: not available URL: From purpleidea at gmail.com Fri Jun 6 10:58:48 2014 From: purpleidea at gmail.com (James) Date: Fri, 6 Jun 2014 06:58:48 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <538C39F6.2080006@redhat.com> References: <538C39F6.2080006@redhat.com> Message-ID: On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote: > Ticket 4302 is a request for an enhancement: Move replication topology to > the shared tree One comment to add: It would be particularly useful if the interface used to set the topology is something sane that a single host can use to set its peers. Eg: host1$ ipa-topology-set-peers host2 host2$ ipa-topology-set-peers host3 host3$ ipa-topology-set-peers host4 host4$ ipa-topology-set-peers host1 # redundant, but okay... This way config management could define topologies in terms of algorithms. Eg: Ring topology: Order hostnames alphabetically. Peer with host name index of self + 1 (Example shown above) Star topology: Peer with every other host in list Pick two topology: Peer with each subsequent hosts in ordered list... And so on... If running the command changes the topology again, then that's great because changing the algorithm would re-arrange the graph :) Hope this made sense. Cheers, James From pviktori at redhat.com Fri Jun 6 11:04:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Jun 2014 13:04:29 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53906D43.2060707@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> Message-ID: <5391A03D.1030408@redhat.com> On 06/05/2014 03:14 PM, Petr Viktorin wrote: > On 06/04/2014 11:42 AM, Tomas Babej wrote: >> Hi, >> >> the following set of patches implements the ticket: >> >> https://fedorahosted.org/freeipa/ticket/4052 >> >> The refactoring touches both server and client bits, main features are: >> >> * easier inheritance and creation of new platform modules >> * all filesystem paths are defined as platform constants >> * platform related functionality is implemented as transparent platform >> tasks >> (as opposed to platform dependent implementations) >> * no need to implement your own authconfig class, since tasks encapsulate >> the relevant parts of the code >> >> More documentation, mainly on the part of the documenting the tasks >> contracts >> and the creation of own platform modules should follow later. >> > > Thanks for all the work! > I didn't test yet; actually I haven't read it all yet, but sharing the > first thoughts might make the review faster. If you'd rather have the > whole thing, just wait :) > > > 0202: OK > > 0203: > Can we remove the leading underscores from `__wait_for_open_ports`? I > don't think there's a good reason for that to be "private", let alone > super-annoyingly "private". > > It would be nice to have the Services' __init__s take an optional `api` > argument, and then use `self.api` everywhere. I'm certain we'd > appreciate it in the future. > > In SystemdService.restart, I think the comment is obsolete by now. But > If we want to keep it we should add a link to > https://bugs.freedesktop.org/show_bug.cgi?id=39824 > > Also, it's pointless to just fix whitespace issues and line length. If > you're cleaning up, please convert the code to actually idiomatic > Python, otherwise these are just changes for the sake of change. (Or > maybe for the sake of passing automated style checks, which is pretty > stupid. The real issues are those the tool doesn't report. There's a > nice summary on using the `pep8` tool like this in the last paragraph of > http://bugs.python.org/msg193909.) > > In PlatformService.start, use `with` for open files. Also flush() is > unnecessary before closing a file. > > In SystemdService.service_instance, > len(string) == 0 > translates to: > not string > > In SystemdService.parse_variables, > map(lambda x: y(x), z) > translates to: > [y(x) for x in z] > (plus you can skip the [ ] since you don't need a list) > > In SystemdService.stop/start > if 'context' in api.env and api.env.context in X: > translates to: > if getattr(api.env, 'context', None) in X: > > SystemdService.is_installed, the flag is not needed, just return directly. > > 0204: > When commenting what a function does, use a docstring. > > 0205: OK > 0206: OK > > 0207: > In system_units: again, a generator expression is better than > map(lambda, ...) > > In FedoraService.__init__, > len(string.split(c)) == 1 > translates to: > c not in string > > In FedoraDirectoryService, the comment applies just to restart(), could > you move it there? > > In FedoraDirectoryService.restart, there's `len(instance_name) > 0` again > > In FedoraCAService, can __wait_until_running have just one leading > underscore? I don't think we need to hide it. > > In FedoraCAService.__wait_until_running, there are some hardcoded paths. > Can we pull them from the paths module? It'll be easier to reuse if we > ever find out the class applies to more than Fedora. > (You could do it in some later patch of course.) > > 0208: > Again some hardcoded paths, would be nice to pull them from the paths > object > > I'm surprised you left the parentheses around `if` expressions, since > you're so meticulous about whitespace and line length... > > check_selinux_status, in the RuntimeError message, assumes that it's > called from an installation. This should at least be pointed out in the > docstring. > > There's no newline at the end of the file. > > 0209: > ipa-client-install, --noac help: "Red Hat" has two words. Also it's a > company; I don't think "Red Hat based distributions" is a correct use of > the trademark. In comments/class names it doesn't really matter but in > user-facing text we should try to be professional. > We can either go with "Fedora-based" here and sort this out in a RHEL > patch if needed, or better, adjust the help text (or visibility of the > option) based on if the platform uses authconfig. > > In configure_sshd_config, why did you remove `authorized_keys_changes = > candidate`? > > base.tasks: These need docstrings. Will those included in the > documentation that you want to provide later? > > base.{tasks,fedora}.restore_pre_ipa_client_configuration: line too long. > You fix this in a later patch, why not here? > > > Each of the functions configure_sssd_for_user_info_and_auth, > configure_ldap_for_user_info, configure_auto_homedir_creation now > execute authconfig. > > In the base.authconfig.Authconfig docstring, the example is wrong. > > In that docstring and in ipaplatform.fedora.tasks, instead of > auth_config.enable("sssd").\ > enable("sssdauth") > please use > auth_config.enable("sssd") > auth_config.enable("sssdauth") > In addition to PEP8 compliance (this is Python, not JQuery), it's more > diff-friendly. > Alternately, be pythonic and add support for: > auth_config.enable("sssd", "sssdauth") > auth_config.add_parameters(nisdomain=nisdomain): > > It seems that for every AuthConfig.execute(), you need to do > auth_config.add_option("update") > Why not roll that into execute(), with a (default) argument? > > AuthConfig.__build_args should lose the leading underscores. Nothing to > hide here; according to the docstring it's even part of the public > interface. I'd also move it (and execute()) to the base implementation, > since it's quite unlikely that authconfig would use different arguments > in other distros that support it (and they can override anyway). > > There's another hardcoded path, "/usr/sbin/authconfig". > > 0210: OK > It might be good to point to this patch in some docs, there are some > ideas for porting to System V distros. > > 0211: > I believe ipaplatform.paths.path_namespace doesn't exist yet. Should > these changes be in a later patch? > > I see more hardcodced paths. > > For logging, use multiple arguments instead of %, and str() is > unnecessary, e.g.: > root_logger.info("Failed to add CA to the systemwide " > "CA trust database: %s", e) > > > In backup_and_replace_hostname, please use the logger for the message, > so it ends up a logfile. (Do it in addition to the print if the logger > might be unconfigured.) > > In backup_and_replace_hostname, the `readlines` in `for line in > f.readlines():` is unnecessary. > > 0212: OK > 0213: OK > 0214: OK > 0215: Looks OK > (pylint should be enough to check this, haven't run it yet) > > 0216: > I see a lot of these lines: > from ipaplatform.paths import path_namespace as paths > I don't think it's healthy to have an object that you *always* import as > another name (actually in a single codebase we shouldn't need renaming > objects on import at all, but that would be a very minor nitpick). We > had some discussions about this, maybe I gave you the idea; sorry for > any miscommunication. (I was mostly scared at wanting to redefine a > module's __getattr__, which is some seriously arcane magic -- you should > only try it at home.) > > You can do better by just placing the class in a convenient place: > ipaplatform//paths_module.py: > class PathsNamespace(object): > ... > ipaplatform/paths_module.py ? ipaplatform//paths_module.py > ipaplatform/__init__.py: > from ipaplatform.paths_module import PathsNamespace > paths = PathsNamespace() > any other module: > from ipaplatform import paths > mkdir(paths.IMPORTANT_DIR) > > ipalib/__init__.py: I think your regex got too hungry here... > > I'd add a _TEMPLATE suffix to names of "paths" containing %s, to make it > clear what they are. > Continuing with 0216: ipaserver/install/httpinstance.py: NSS_CONF is already in paths; SSL_CONF should be added there as well. selinux_warning should use paths.SETSEBOOL. Regarding the integration tests, we'll probably want to have each host have a "paths" attribute and use that in the commands, since each can potentially be on a different platform. That can be done later, though. ipatests/test_xmlrpc/test_automount_plugin.py: this change is unnecessary 0217: OK 0218: OK 0219: As I said above, I'd prefer this renamed 0220: Looks OK 0221: Looks OK 0222: Similarly to paths, we should do `from ipaplatform import tasks`; the module can have an inconvenient name. > > When moving code around you remove the Authors: lines from the top of > the files, and replace them with yourself. I don't think that's a fair > thing to do. Functionally, I didn't find any regressions. -- Petr? From pviktori at redhat.com Fri Jun 6 11:47:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Jun 2014 13:47:09 +0200 Subject: [Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env In-Reply-To: References: Message-ID: <5391AA3D.1070401@redhat.com> On 06/06/2014 08:36 AM, Gabe Alford wrote: > Hello, > > Patch 21: > This is a patch for https://fedorahosted.org/freeipa/ticket/3724 Nope, doesn't work for me: nolog_replace expects a string. File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 639, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 1140, in main certificate_renewal_update(ca), File "/usr/sbin/ipa-upgradeconfig", line 691, in certificate_renewal_update ca.configure_renewal() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1444, in configure_renewal post_command='renew_ca_cert "%s"' % nickname) File "/usr/lib/python2.7/site-packages/ipapython/certmonger.py", line 431, in dogtag_start_tracking (stdout, stderr, returncode) = ipautil.run(args, nolog=[pin]) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 305, in run arg_string = nolog_replace(args, nolog) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 360, in nolog_replace string = string.replace(nolog_value, 'XXXXXXXX') I'd recommend something like ' '.join(shell_quote(a) for a in args). > Patch 22: > This is part of https://fedorahosted.org/freeipa/ticket/4316 and adds > the API to 'ipa env' > > One question that I had for adding 'ipa --version' is if using the > default optparse version argument would be sufficient/intended i.e. > version=('Version: %s, API_Version: %s' % (version, api_version) or if a > custom optparse argument is needed. I think the default will be just fine. Can you update the patch to add the option? -- Petr? From simo at redhat.com Fri Jun 6 12:00:10 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 08:00:10 -0400 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <53917C2A.9060702@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> Message-ID: <1402056010.9430.2.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: > On 05/31/2014 03:27 AM, Simo Sorce wrote: > > I have rebased theold patch attached to the ticket, unfortunately I > > haven't had time to test it yet, but didn't want to lose it in some > > branch. > > > > Simo. > > I tested the patch and it worked fine, code also reads OK. Thus, I am willing > to ACK it. > > I am just wondering if there is any scenario we could have missed, but I did > not find any. In there is no push back against the patch I may just push it. The only thing I would draw attention to is the fact that now I am sending back the error directly once we have a negative return from the function in which expiration is checked (ipapwd_authenticate). I could not see why we did, in fact, not do that before and I meant asking Nathaniel if he had an explicit reason why we do not, as he is the last one that did some significant refactoring in the bind preop plugin. Simo. -- Simo Sorce * Red Hat, Inc * New York From jpazdziora at redhat.com Fri Jun 6 12:03:31 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 6 Jun 2014 14:03:31 +0200 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: References: Message-ID: <20140606120331.GM1482@redhat.com> On Fri, Jun 06, 2014 at 06:38:10AM -0400, James wrote: > > I've just announced the first sane implementation for secret handling > in puppet. Since everyone does this wrong, I thought I'd do it right, > by pioneering a new technique. You can read about it here: > > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > In short, the dm_password and admin_password never get touched by > puppet, and are generated locally on the freeipa server. What this > means is that puppet doesn't know what they are, and as a result, > can't use them to accomplish admin tasks. Could we make this functionality part of the ipa-server-install script itself? It could be useful outside of puppet as well? Do you have any proposal how to go about ipa-client-install in puppet, without having the password stored/exposed there? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Fri Jun 6 12:26:51 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 08:26:51 -0400 Subject: [Freeipa-devel] Wikipedia articles mentioning FreeIPA In-Reply-To: <539174A5.7040407@redhat.com> References: <53917136.1080800@redhat.com> <539174A5.7040407@redhat.com> Message-ID: <1402057611.9430.6.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 09:58 +0200, Petr Viktorin wrote: > On 06/06/2014 09:43 AM, Petr Spacek wrote: > > Hello list, > > > > I accidentally came across RHEV wikipedia articles mentioning FreeIPA: > > https://en.wikipedia.org/wiki/FreeIPA > > https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization > > > > Those articles could use attention of wordsmith :-) I'm not saying it > > should be full of marketing buzzwords, it should be factually correct. > > > > > > https://en.wikipedia.org/wiki/FreeIPA > > says: > > "FreeIPA aims to provide support not just for Linux and Unix based > > computers but ultimately Microsoft Windows and Apple Macintosh computers > > also." > > > > > > https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Virtualization > > says: > > "It can acquire user and group information from an Active Directory > > service or FreeIPA Active Directory emulator," > > > > Have a nice day! > > > > Note that if you're a FreeIPA developer, especially a paid one, you > should read Wikipedia's Conflict of Interest page carefully before (not) > editing those pages. > http://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest I do not see any COI in amending factual errors. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jun 6 12:51:39 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 08:51:39 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: References: Message-ID: <1402059099.9430.8.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 06:38 -0400, James wrote: > Hi FreeIPA, > > *intro* > > As some of you might know, I'm currently working on deploying > multi-master replicas with puppet. Since it looks like there will be > security implications, I wanted to start off by trying to build some > confidence. I want to demonstrate that I am as paranoid about getting > the security bits right as you all are. *cough* I'm looking at you > Simo ;) I am cracking my knuckles already :-) Comments inline. > I've just announced the first sane implementation for secret handling > in puppet. Since everyone does this wrong, I thought I'd do it right, > by pioneering a new technique. You can read about it here: > > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > In short, the dm_password and admin_password never get touched by > puppet, and are generated locally on the freeipa server. What this > means is that puppet doesn't know what they are, and as a result, > can't use them to accomplish admin tasks. Ok let me try first to clarify what is the intent here. Clearly puppet has root level access to the system so you do not (should not ?) care much about preventing access to these systems, the aim is to not inadvertently divulge secrets through manifests and nothing else. Correct ? > *replicas* > > ipa-replica-prepare and ipa-replica-install work _too_ well. they're > the one part of freeipa that are so easy to use by a human, but nearly > impossible to use with puppet (without storing the password in > puppet). puppet can't use them as is because they need you to enter a > password (which i don't want it to have). Here is what I propose to do > for accomplishing this. Please correct me if I've made a mistake, or > recommend something different. > > ipa-replica-prepare seems to need the dm_password. This seems to be > needed for symmetrically encrypting the bunch of files to transfer to > the replica. Instead, I'll patch this process to allow use of a public > key for asymetric encryption that is unique to the receiving replica. > I'll make sure that each ipa server generates it's own keypair, and > that the public halves are distributed to the sending hosts. > > I don't think there is any other need for the dm_password in > ipa-replica-prepare. Did I miss something? Yes, the dm_password was chosen because it is needed to actually initialize and install the replica, so instead of asking it twice we just ask for it once and use it *also* to encrypt the prepared file. But the password is still currently absolutely necessary. But let me ask a more important question, how do you distribute the public keys securely ? Is it puppet fetching them from each replica-to-be server and sending them to the first master server ? > ipa-replica-install needs the dm_password to decrypt the gpg file. > Since I'm handling that with my asymmetric key pair, we don't need the > password for that. Beeep, sorry wrong answer for now :-) > mkosek was very kind in helping me dig through this > part a bit, and it seems that the dm_password is needed to allow the > replica to bind to the first server. It is also needed to actually store the DM password on the replica server itself in it's own cn=Directory Manager super user entry. Although I think we could send the hash for that. > I would need some help to find an > alternative for this process. As was suggested, perhaps a one-time > password could be generated and sent across the wire (with puppet) to > the replica. Any mechanism that doesn't need the dm_password would be > great. Forget custom schemes. The simplest way to handle this (which I wanted to do for a while) is to pre-create the replica's LDAP principal and keys at replica-prepare time so we can start right away with GSSAPI authentication for the first replication and create agreements directly using GSSAPI auth. This would in turn simplify replication agreements creation as we won't need anymore to do the dance where we create the agreement with a plain text bind and then we need to convert the agreement to use GSSAPI. > I don't think there is any other need for the dm_password in > ipa-replica-install. Did I miss something? See above, it needs the password to actually create the DM account at DS setup time. *also* the DM password is used to setup some parts of the dogtag CA so if any of your replica is also a CA clone you go straight back to needing the DM password. > Of course if I store the dm_password in puppet, then it's easy to do > this peering because it will be easy to use the password on each host. > I could be done my puppet module already :) But I'm going out of my > way to do it right, so that you'll all be proud of the work too! Ok, here is a quickest method to do what you want to do IMO: First of all, you need a DM password for the initial server and you need to store it somewhere because the admin must know what it is, there is no way around this. So I guess you are planning to store it in a file under /root in the master server or something like that. This means puppet has access to the DM password w/o storing it in the manifest. Use the DM password to do everything as usual AND create the asymmetric keys in the replicas and *securely* transmit them to the master. Now wrap the current replica file (yes it is already encrypted, who cares), AND the DM password into a new envelope encrypted with your public keys. Presto! Now you transfer the blob back to the replicas, and each replica can be scripted, and puppet has no passwords in its manifest. > *symmetry* > > It would be especially elegant and beneficial to FreeIPA and the > puppet module if the process of "peering" was symmetrical, that is to > say, similar for any host. If I could use ipa-server-install to setup > N hosts, and then run a secondary command to cause certain ones to > "join" this would make the process much more natural for puppet. This is intrinsically not possible. > In addition, this would ensure that the configuration management itself > is HA. Without this type of functionality, then if the first ipa > server isn't available, then config management will be blocked. Yeah, chicken-egg issues of bootstrapping infrastructures. I currently do not see any way around this. > I would appreciate any recommendations on how to convert a previously > installed ipa server into a replica. Of course it's fine that it will > have it's data overwritten. If you overwrite all data what is the point really ? You are still dependent on exactly ONE master replicating to all others first, until then you cannot do anything, as any operation you would do against any other server would be erased and wiped. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jun 6 13:03:33 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 09:03:33 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: References: <538C39F6.2080006@redhat.com> Message-ID: <1402059813.9430.10.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 06:58 -0400, James wrote: > On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote: > > Ticket 4302 is a request for an enhancement: Move replication topology to > > the shared tree > > > One comment to add: > > It would be particularly useful if the interface used to set the > topology is something sane that a single host can use to set its > peers. Eg: > > host1$ ipa-topology-set-peers host2 > host2$ ipa-topology-set-peers host3 > host3$ ipa-topology-set-peers host4 > host4$ ipa-topology-set-peers host1 # redundant, but okay... > > This way config management could define topologies in terms of algorithms. Eg: > > Ring topology: > Order hostnames alphabetically. > Peer with host name index of self + 1 > (Example shown above) > > Star topology: > Peer with every other host in list > > Pick two topology: > Peer with each subsequent hosts in ordered list... > > And so on... > If running the command changes the topology again, then that's great > because changing the algorithm would re-arrange the graph :) > > Hope this made sense. Oh it does! But I am dreaming even bigger, my aim is to end up (in the long run) with something like: ipa topology change --stellar host1 host2 host3 host4 host5 causes topology for those 5 servers only (ignores any other connection) to become: host2 | host3 - host1 - host5 | host4 So any agreement between host1 and 2,3,4,5 get wiped and replaced with the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not affected in any way and stay). And later on you'd be able to say ipa topology change --circular host1 host2 host3 host4 and you get: host1 - host2 | | host4 - host3 Note that if you previously did the stellar thing and you only have these 5 servers the actual complete topology ends up being like this: host5 | host1 - host2 | | host4 - host3 As the agreement between host1 and host5 is not touched by the second command. But this is in the far future IMO, we'll probably start by only implementing: ipa topology set-peering host1 host2 and ipa topology break-peering host3 host4 Ie creating and breaking segments in the topology tree only between pairs and storing/deleting the segment object in the shared tree. The reason is that the topology plugin will allow or disallow changes based on whether you are breaking the graph, and it is much simpler to do that if you change one object at a time. To do the nifty stuff above we'd need some staging area where we describe all the changes and then have a "commit" type change that would cause the topology plugin to do all the calculations and move stuff around inside at once (or refuse the commit if the change as a whole breaks the graph). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From jpazdziora at redhat.com Fri Jun 6 13:10:50 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 6 Jun 2014 15:10:50 +0200 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <1402059099.9430.8.camel@willson.usersys.redhat.com> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> Message-ID: <20140606131050.GP1482@redhat.com> On Fri, Jun 06, 2014 at 08:51:39AM -0400, Simo Sorce wrote: > > Clearly puppet has root level access to the system so you do not (should > not ?) care much about preventing access to these systems, the aim is to > not inadvertently divulge secrets through manifests and nothing else. And puppet logs. And forgetting the secrets around. With puppet you do not have interactive (password) prompt available so everything including secrets needs to be pre-created and pre-populated before the puppet apply starts. Or, where possible, generated and immediatelly encrypted -- I find that approach very clever. But unfortunately it can only be used for the initial FreeIPA server installation, it seems -- in all the subsequent operations, we need to pass the existing matching credential. I wonder if we could be able to pass the passwords to puppet via file descriptors from some invoking wrapper ... -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From edewata at redhat.com Fri Jun 6 13:45:33 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 06 Jun 2014 08:45:33 -0500 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <53907DEC.8050106@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> Message-ID: <5391C5FD.5060908@redhat.com> On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote: > ACK for patches #592-#628. I'll continue reviewing the rest. ACK for patches #633-639, #642, #644, #652, and #653. Patches #640 & #641 have an issue (see #19 below) that should be fixed before pushing. Other issues are minor/unrelated/suggestions that can be addressed separately. 13. The separators in the top right drop down menu shouldn't be focusable. To test this, click the menu, then hit tab several times. 14. In the certificates page, if I enter a search filter then hit Refresh (instead of Enter) it doesn't change the content based on the new search filter. I suppose a more intuitive behavior would be to rerun the search with the new filter, or reset the filter to the previous value. 15. In the certificates page, if I enter an invalid filter it will show an error dialog, then after I close it it will show the error message in the page. This is fine, but if I go to another page, then back, it will do the same thing as if the search is executed again. If the page is cached, it probably shouldn't display the error dialog, just the error message in the page. Alternatively, if the search failed it shouldn't be cached. 16. In the association adder dialog it's not clear if the filter applies to just the Available list or the Prospective list too. Maybe the placeholder text could say "Filter available ${other_entity}". 17. It looks like some facet-actions elements contain unnecessary blank ul.dropdown-menu elements which probably correspond to the number of menu items (see User's Actions button). 18. In the New Certificate dialog for Host, the instruction to create a CSR exceeds the dialog boundary. 19. The "View certificate" is missing from the Host's and Service's Action, probably because of the incorrect labels below: IPA.cert.view_action = function(spec) { // should be objects.cert.view_certificate_btn spec.label = spec.label || '@i18n:objects.cert.view'; that.execute_action = function(facet) { // should be objects.cert.view_certificate var title = text.get('@i18n:objects.cert.view_certificate_btn'); 20. The capitalization of "Certificate" is inconsistent in Host's and Service's Actions. 21. Should there be a link from the Host page to the Certificate page? Can the certificate serial number be displayed in the Host page? If we do this, it's probably not necessary to have Revoke/Restore Certificate actions in the Host page. Same thing with the Service page. 22. The add dialog for RADIUS Server uses a field label "Secret". Everywhere else in the RADIUS Server page it's called "Password" (e.g. Verify Password, Reset Password). -- Endi S. Dewata From redhatrises at gmail.com Fri Jun 6 15:02:09 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 6 Jun 2014 09:02:09 -0600 Subject: [Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env In-Reply-To: <5391AA3D.1070401@redhat.com> References: <5391AA3D.1070401@redhat.com> Message-ID: Patch 21: Update per recommendation Patch 22: Added version option as well as updated the manpage. Thanks, Gabe On Fri, Jun 6, 2014 at 5:47 AM, Petr Viktorin wrote: > On 06/06/2014 08:36 AM, Gabe Alford wrote: > >> Hello, >> >> Patch 21: >> This is a patch for https://fedorahosted.org/freeipa/ticket/3724 >> > > Nope, doesn't work for me: nolog_replace expects a string. > > File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 639, in run_script > return_value = main_function() > File "/usr/sbin/ipa-upgradeconfig", line 1140, in main > certificate_renewal_update(ca), > File "/usr/sbin/ipa-upgradeconfig", line 691, in > certificate_renewal_update > ca.configure_renewal() > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1444, in configure_renewal > post_command='renew_ca_cert "%s"' % nickname) > File "/usr/lib/python2.7/site-packages/ipapython/certmonger.py", line > 431, in dogtag_start_tracking > (stdout, stderr, returncode) = ipautil.run(args, nolog=[pin]) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 305, > in run > arg_string = nolog_replace(args, nolog) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 360, > in nolog_replace > string = string.replace(nolog_value, 'XXXXXXXX') > > > I'd recommend something like ' '.join(shell_quote(a) for a in args). > > > Patch 22: >> This is part of https://fedorahosted.org/freeipa/ticket/4316 and adds >> the API to 'ipa env' >> >> One question that I had for adding 'ipa --version' is if using the >> default optparse version argument would be sufficient/intended i.e. >> version=('Version: %s, API_Version: %s' % (version, api_version) or if a >> custom optparse argument is needed. >> > > I think the default will be just fine. Can you update the patch to add the > option? > > -- > Petr? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0022-2-Add-version-and-API-version.patch Type: text/x-patch Size: 3391 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0021-2-ipautil.run-args-log-message-is-confusing.patch Type: text/x-patch Size: 919 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jun 6 15:06:31 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 06 Jun 2014 11:06:31 -0400 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <1402056010.9430.2.camel@willson.usersys.redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> Message-ID: <1402067191.4323.31.camel@ipa.example.com> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: > > On 05/31/2014 03:27 AM, Simo Sorce wrote: > > > I have rebased theold patch attached to the ticket, unfortunately I > > > haven't had time to test it yet, but didn't want to lose it in some > > > branch. > > > > > > Simo. > > > > I tested the patch and it worked fine, code also reads OK. Thus, I am willing > > to ACK it. > > > > I am just wondering if there is any scenario we could have missed, but I did > > not find any. In there is no push back against the patch I may just push it. > The only thing I would draw attention to is the fact that now I am > sending back the error directly once we have a negative return from the > function in which expiration is checked (ipapwd_authenticate). > > I could not see why we did, in fact, not do that before and I meant > asking Nathaniel if he had an explicit reason why we do not, as he is > the last one that did some significant refactoring in the bind preop > plugin. In the current design, if ipapwd_authenticate() fails, we defer to 389ds for the actual response to the client. The purpose for this is so that verification of the first factor always behaves the same, regardless of what is in pre-bind. So ipapwd_authenticate() is not actually the "final" authentication. It is a preliminary authentication to determine if the user should be able to write kerberos keys and perform OTP sync. So checking expiration in pre-bind only protects these two operations. I presume that 389ds also checks password expiration. If this assumption is true, ipapwd_authenticate() SHOULD NOT return any response to the client. It should simply fail key-write/otp-sync silently and let dirsrv return the error to the client. The important point here is that so long as 389ds is verifying password expiration, using a correct-but-expired password will should not result in a bind in the current code. It will result in kerberos key writing and OTP sync. Do we actually care about protecting kerberos key writing and OTP sync from correct-but-expired passwords? If 389ds does not check password expiration, then we probably need to patch upstream 389ds or, at the very least, return an error to the client. Otherwise, if we don't care about protecting kerberos key writing and OTP sync from correct-but-expired passwords, this patch is entirely unnecessary. Otherwise, the patch is necessary, but should skip kerberos key writing and OTP sync and fall through silently to 389ds. Nathaniel From pvoborni at redhat.com Fri Jun 6 15:43:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 06 Jun 2014 17:43:22 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <5391C5FD.5060908@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> <5391C5FD.5060908@redhat.com> Message-ID: <5391E19A.5080806@redhat.com> On 6.6.2014 15:45, Endi Sukma Dewata wrote: > On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote: >> ACK for patches #592-#628. I'll continue reviewing the rest. > > ACK for patches #633-639, #642, #644, #652, and #653. Patches #640 & > #641 have an issue (see #19 below) that should be fixed before pushing. > Other issues are minor/unrelated/suggestions that can be addressed > separately. Thank you for the review. I've fixed issues: - #19, #20 in patch #640. And some low hanging fruit: - #16, in patch #637 - #17, in patch #612 - #13, in patch #612 The branch has been rebased to current master. Some comments bellow. For the rest (including issues #1-#12) I'll create tickets and/or fix them later. Some are existing issues. I am not able to reproduce issues #4 and #11. > > 13. The separators in the top right drop down menu shouldn't be > focusable. To test this, click the menu, then hit tab several times. > Fixed. Also disabled items are no longer focusable. > 14. In the certificates page, if I enter a search filter then hit > Refresh (instead of Enter) it doesn't change the content based on the > new search filter. I suppose a more intuitive behavior would be to rerun > the search with the new filter, or reset the filter to the previous value. > > 15. In the certificates page, if I enter an invalid filter it will show > an error dialog, then after I close it it will show the error message in > the page. This is fine, but if I go to another page, then back, it will > do the same thing as if the search is executed again. If the page is > cached, it probably shouldn't display the error dialog, just the error > message in the page. Alternatively, if the search failed it shouldn't be > cached. I don't think this page is cached -> the wrong command is executed every time which will show the dialog. > > 16. In the association adder dialog it's not clear if the filter applies > to just the Available list or the Prospective list too. Maybe the > placeholder text could say "Filter available ${other_entity}". Fixed > > 17. It looks like some facet-actions elements contain unnecessary blank > ul.dropdown-menu elements which probably correspond to the number of > menu items (see User's Actions button). Fixed DropdownWidget's _render_items method. > > 18. In the New Certificate dialog for Host, the instruction to create a > CSR exceeds the dialog boundary. caused by BS' CSS: code { white-space: nowrap; } I wonder if the best solution is to reset it to initial value in all dialogs. > > 19. The "View certificate" is missing from the Host's and Service's > Action, probably because of the incorrect labels below: > > IPA.cert.view_action = function(spec) { > > // should be objects.cert.view_certificate_btn > spec.label = spec.label || '@i18n:objects.cert.view'; > > that.execute_action = function(facet) { > > // should be objects.cert.view_certificate > var title = text.get('@i18n:objects.cert.view_certificate_btn'); Fixed > > 20. The capitalization of "Certificate" is inconsistent in Host's and > Service's Actions. Fixed > > 21. Should there be a link from the Host page to the Certificate page? > Can the certificate serial number be displayed in the Host page? If we > do this, it's probably not necessary to have Revoke/Restore Certificate > actions in the Host page. Same thing with the Service page. > > 22. The add dialog for RADIUS Server uses a field label "Secret". > Everywhere else in the RADIUS Server page it's called "Password" (e.g. > Verify Password, Reset Password). > -- Petr Vobornik From simo at redhat.com Fri Jun 6 15:43:47 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 11:43:47 -0400 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <1402067191.4323.31.camel@ipa.example.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> Message-ID: <1402069427.9430.16.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: > On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: > > On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: > > > On 05/31/2014 03:27 AM, Simo Sorce wrote: > > > > I have rebased theold patch attached to the ticket, unfortunately I > > > > haven't had time to test it yet, but didn't want to lose it in some > > > > branch. > > > > > > > > Simo. > > > > > > I tested the patch and it worked fine, code also reads OK. Thus, I am willing > > > to ACK it. > > > > > > I am just wondering if there is any scenario we could have missed, but I did > > > not find any. In there is no push back against the patch I may just push it. > > > The only thing I would draw attention to is the fact that now I am > > sending back the error directly once we have a negative return from the > > function in which expiration is checked (ipapwd_authenticate). > > > > I could not see why we did, in fact, not do that before and I meant > > asking Nathaniel if he had an explicit reason why we do not, as he is > > the last one that did some significant refactoring in the bind preop > > plugin. > > In the current design, if ipapwd_authenticate() fails, we defer to 389ds > for the actual response to the client. The purpose for this is so that > verification of the first factor always behaves the same, regardless of > what is in pre-bind. > > So ipapwd_authenticate() is not actually the "final" authentication. It > is a preliminary authentication to determine if the user should be able > to write kerberos keys and perform OTP sync. So checking expiration in > pre-bind only protects these two operations. > > I presume that 389ds also checks password expiration. If this assumption > is true, ipapwd_authenticate() SHOULD NOT return any response to the > client. It should simply fail key-write/otp-sync silently and let dirsrv > return the error to the client. 389ds would check it if we were using 389ds native password policies but we are not. So we need to check on our own, which is what this patch implements. > The important point here is that so long as 389ds is verifying password > expiration, using a correct-but-expired password will should not result > in a bind in the current code. It will result in kerberos key writing > and OTP sync. Do we actually care about protecting kerberos key writing > and OTP sync from correct-but-expired passwords? No, but that's not the point. > If 389ds does not check password expiration, then we probably need to > patch upstream 389ds or, at the very least, return an error to the > client. It is not a 389ds bug, it is just an integration issue due to the fact IPA uses a different schema for password policies (for compatibility with the Kerberos schema). > Otherwise, if we don't care about protecting kerberos key writing and > OTP sync from correct-but-expired passwords, this patch is entirely > unnecessary. > > Otherwise, the patch is necessary, but should skip kerberos key writing > and OTP sync and fall through silently to 389ds. If we fall through to 389ds then authentication will succeed. So from this discussion it seem to me we achieve the goal of the patch and returning an error directly is ok. Unless Nathaniel has something *against* returning an error in this place I think we are good to go. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Jun 6 15:47:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 06 Jun 2014 11:47:11 -0400 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <1402069427.9430.16.camel@willson.usersys.redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> Message-ID: <1402069631.4323.35.camel@ipa.example.com> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: > > On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: > > > On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: > > > > On 05/31/2014 03:27 AM, Simo Sorce wrote: > > > > > I have rebased theold patch attached to the ticket, unfortunately I > > > > > haven't had time to test it yet, but didn't want to lose it in some > > > > > branch. > > > > > > > > > > Simo. > > > > > > > > I tested the patch and it worked fine, code also reads OK. Thus, I am willing > > > > to ACK it. > > > > > > > > I am just wondering if there is any scenario we could have missed, but I did > > > > not find any. In there is no push back against the patch I may just push it. > > > > > The only thing I would draw attention to is the fact that now I am > > > sending back the error directly once we have a negative return from the > > > function in which expiration is checked (ipapwd_authenticate). > > > > > > I could not see why we did, in fact, not do that before and I meant > > > asking Nathaniel if he had an explicit reason why we do not, as he is > > > the last one that did some significant refactoring in the bind preop > > > plugin. > > > > In the current design, if ipapwd_authenticate() fails, we defer to 389ds > > for the actual response to the client. The purpose for this is so that > > verification of the first factor always behaves the same, regardless of > > what is in pre-bind. > > > > So ipapwd_authenticate() is not actually the "final" authentication. It > > is a preliminary authentication to determine if the user should be able > > to write kerberos keys and perform OTP sync. So checking expiration in > > pre-bind only protects these two operations. > > > > I presume that 389ds also checks password expiration. If this assumption > > is true, ipapwd_authenticate() SHOULD NOT return any response to the > > client. It should simply fail key-write/otp-sync silently and let dirsrv > > return the error to the client. > > 389ds would check it if we were using 389ds native password policies but > we are not. So we need to check on our own, which is what this patch > implements. > > > The important point here is that so long as 389ds is verifying password > > expiration, using a correct-but-expired password will should not result > > in a bind in the current code. It will result in kerberos key writing > > and OTP sync. Do we actually care about protecting kerberos key writing > > and OTP sync from correct-but-expired passwords? > > No, but that's not the point. > > > If 389ds does not check password expiration, then we probably need to > > patch upstream 389ds or, at the very least, return an error to the > > client. > > It is not a 389ds bug, it is just an integration issue due to the fact > IPA uses a different schema for password policies (for compatibility > with the Kerberos schema). > > > Otherwise, if we don't care about protecting kerberos key writing and > > OTP sync from correct-but-expired passwords, this patch is entirely > > unnecessary. > > > > Otherwise, the patch is necessary, but should skip kerberos key writing > > and OTP sync and fall through silently to 389ds. > > If we fall through to 389ds then authentication will succeed. > > So from this discussion it seem to me we achieve the goal of the patch > and returning an error directly is ok. > > Unless Nathaniel has something *against* returning an error in this > place I think we are good to go. Looks good to me. ACK. Nathaniel From dpal at redhat.com Fri Jun 6 16:12:01 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Jun 2014 12:12:01 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1402059813.9430.10.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1402059813.9430.10.camel@willson.usersys.redhat.com> Message-ID: <5391E851.9020209@redhat.com> On 06/06/2014 09:03 AM, Simo Sorce wrote: > On Fri, 2014-06-06 at 06:58 -0400, James wrote: >> On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote: >>> Ticket 4302 is a request for an enhancement: Move replication topology to >>> the shared tree >> >> One comment to add: >> >> It would be particularly useful if the interface used to set the >> topology is something sane that a single host can use to set its >> peers. Eg: >> >> host1$ ipa-topology-set-peers host2 >> host2$ ipa-topology-set-peers host3 >> host3$ ipa-topology-set-peers host4 >> host4$ ipa-topology-set-peers host1 # redundant, but okay... >> >> This way config management could define topologies in terms of algorithms. Eg: >> >> Ring topology: >> Order hostnames alphabetically. >> Peer with host name index of self + 1 >> (Example shown above) >> >> Star topology: >> Peer with every other host in list >> >> Pick two topology: >> Peer with each subsequent hosts in ordered list... >> >> And so on... >> If running the command changes the topology again, then that's great >> because changing the algorithm would re-arrange the graph :) >> >> Hope this made sense. > Oh it does! > > But I am dreaming even bigger, my aim is to end up (in the long run) > with something like: > > ipa topology change --stellar host1 host2 host3 host4 host5 > > causes topology for those 5 servers only (ignores any other connection) > to become: > > host2 > | > host3 - host1 - host5 > | > host4 > > So any agreement between host1 and 2,3,4,5 get wiped and replaced with > the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not > affected in any way and stay). > > And later on you'd be able to say > ipa topology change --circular host1 host2 host3 host4 > > and you get: > > host1 - host2 > | | > host4 - host3 > > Note that if you previously did the stellar thing and you only have > these 5 servers the actual complete topology ends up being like this: > > host5 > | > host1 - host2 > | | > host4 - host3 > > As the agreement between host1 and host5 is not touched by the second > command. > > But this is in the far future IMO, we'll probably start by only > implementing: > > ipa topology set-peering host1 host2 > and > ipa topology break-peering host3 host4 > > Ie creating and breaking segments in the topology tree only between > pairs and storing/deleting the segment object in the shared tree. > > The reason is that the topology plugin will allow or disallow changes > based on whether you are breaking the graph, and it is much simpler to > do that if you change one object at a time. To do the nifty stuff above > we'd need some staging area where we describe all the changes and then > have a "commit" type change that would cause the topology plugin to do > all the calculations and move stuff around inside at once (or refuse the > commit if the change as a whole breaks the graph). > > HTH, > Simo. > I was thinking about the commit and staging too. I think this approach will be beneficial for the "rebuild from existing non replicated agreements" use case too. The logic for the use case that I described in other branch of this discussion will be: - Collect all info by contacting all the servers. - Save in staging - Analyze that topology makes sense and graph is not broken (error out if it is) - Start transaction - Put the data into the replicated tree - Stop transaction - Start replicating -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From lkrispen at redhat.com Fri Jun 6 16:22:53 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 06 Jun 2014 18:22:53 +0200 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <5391E851.9020209@redhat.com> References: <538C39F6.2080006@redhat.com> <1402059813.9430.10.camel@willson.usersys.redhat.com> <5391E851.9020209@redhat.com> Message-ID: <5391EADD.1090900@redhat.com> On 06/06/2014 06:12 PM, Dmitri Pal wrote: > On 06/06/2014 09:03 AM, Simo Sorce wrote: >> On Fri, 2014-06-06 at 06:58 -0400, James wrote: >>> On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz >>> wrote: >>>> Ticket 4302 is a request for an enhancement: Move replication >>>> topology to >>>> the shared tree >>> >>> One comment to add: >>> >>> It would be particularly useful if the interface used to set the >>> topology is something sane that a single host can use to set its >>> peers. Eg: >>> >>> host1$ ipa-topology-set-peers host2 >>> host2$ ipa-topology-set-peers host3 >>> host3$ ipa-topology-set-peers host4 >>> host4$ ipa-topology-set-peers host1 # redundant, but okay... >>> >>> This way config management could define topologies in terms of >>> algorithms. Eg: >>> >>> Ring topology: >>> Order hostnames alphabetically. >>> Peer with host name index of self + 1 >>> (Example shown above) >>> >>> Star topology: >>> Peer with every other host in list >>> >>> Pick two topology: >>> Peer with each subsequent hosts in ordered list... >>> >>> And so on... >>> If running the command changes the topology again, then that's great >>> because changing the algorithm would re-arrange the graph :) >>> >>> Hope this made sense. >> Oh it does! >> >> But I am dreaming even bigger, my aim is to end up (in the long run) >> with something like: >> >> ipa topology change --stellar host1 host2 host3 host4 host5 >> >> causes topology for those 5 servers only (ignores any other connection) >> to become: >> >> host2 >> | >> host3 - host1 - host5 >> | >> host4 >> >> So any agreement between host1 and 2,3,4,5 get wiped and replaced with >> the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not >> affected in any way and stay). >> >> And later on you'd be able to say >> ipa topology change --circular host1 host2 host3 host4 >> >> and you get: >> >> host1 - host2 >> | | >> host4 - host3 >> >> Note that if you previously did the stellar thing and you only have >> these 5 servers the actual complete topology ends up being like this: >> >> host5 >> | >> host1 - host2 >> | | >> host4 - host3 >> >> As the agreement between host1 and host5 is not touched by the second >> command. >> >> But this is in the far future IMO, we'll probably start by only >> implementing: >> >> ipa topology set-peering host1 host2 >> and >> ipa topology break-peering host3 host4 >> >> Ie creating and breaking segments in the topology tree only between >> pairs and storing/deleting the segment object in the shared tree. >> >> The reason is that the topology plugin will allow or disallow changes >> based on whether you are breaking the graph, and it is much simpler to >> do that if you change one object at a time. To do the nifty stuff above >> we'd need some staging area where we describe all the changes and then >> have a "commit" type change that would cause the topology plugin to do >> all the calculations and move stuff around inside at once (or refuse the >> commit if the change as a whole breaks the graph). >> >> HTH, >> Simo. >> > I was thinking about the commit and staging too. I think this approach > will be beneficial for the "rebuild from existing non replicated > agreements" use case too. > The logic for the use case that I described in other branch of this > discussion will be: > - Collect all info by contacting all the servers. > - Save in staging > - Analyze that topology makes sense and graph is not broken (error out > if it is) > - Start transaction > - Put the data into the replicated tree > - Stop transaction > - Start replicating ok, so this will be handled outside of the topology plugin, a future step could be to define topology types and connectivity rules and have the topology plugin to verify this From npmccallum at redhat.com Fri Jun 6 17:04:37 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 06 Jun 2014 13:04:37 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <5390121C.5070402@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> <1401309865.4631.5.camel@ipa.example.com> <5390121C.5070402@redhat.com> Message-ID: <1402074277.4323.37.camel@ipa.example.com> On Thu, 2014-06-05 at 08:45 +0200, Jan Cholasta wrote: > On 28.5.2014 22:44, Nathaniel McCallum wrote: > > On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: > >> On 13.5.2014 19:12, Nathaniel McCallum wrote: > >>> On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: > >>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: > >>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: > >>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: > >>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: > >>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: > >>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: > >>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: > >>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the > >>>>>>>>>>>>>> introduction of SELFDN support. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Admins, as before, have full access to all token permissions. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Normal users have read/search/compare access to all of the non-secret > >>>>>>>>>>>>>> data for tokens assigned to them, whether protected or non-protected. > >>>>>>>>>>>>>> Users can add or delete non-protected tokens and modify most of their > >>>>>>>>>>>>>> metadata. However they cannot create, delete or modify protected tokens. > >>>>>>>>>>>>>> Regardless of whether the token is protected or not, users cannot change > >>>>>>>>>>>>>> a token's ownership or unique identity. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> In contrast, admins can create protected tokens. This protects the token > >>>>>>>>>>>>>> from deletion or modification when assigned to users. Additionally, when > >>>>>>>>>>>>>> a user account is deleted, the assigned non-protected tokens are deleted > >>>>>>>>>>>>>> but the protected tokens are merely orphaned. This permits the token to > >>>>>>>>>>>>>> be reassigned without having to recreate it. This last point is > >>>>>>>>>>>>>> particularly useful in the case of hardware tokens. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. > >>>>>>>>>>>>> This new version makes ipatokenDisabled visible for token owners. It is > >>>>>>>>>>>>> also writable if the token is non-protected. This additionally fixes: > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 > >>>>>>>>>>>> This new version changes the way the default value of protected is setup > >>>>>>>>>>>> in accordance with the changes made for the review of my patch 0048.2. > >>>>>>>>>>>> > >>>>>>>>>>>> Nathaniel > >>>>>>>>>>> Is using the ipatokenprotected attribute the final design? > >>>>>>>>>> No. Alternate designs are welcome. The code is easy enough to modify. > >>>>>>>>>> > >>>>>>>>>>> I did not dig too deep into this, but I think it might be better to > >>>>>>>>>>> instead use the managedby attribute on a token to limit who can delete > >>>>>>>>>>> (or administer in other way) the token. On otptoken-add, managedby would > >>>>>>>>>>> be set to the "whoami" user DN, unless run with --protected, in which > >>>>>>>>>>> case managedby would be left empty. Then, when deleting a user, the > >>>>>>>>>>> token would be deleted only if the user manages the token. > >>>>>>>>>> It seems to me that the mechanics of this are roughly the same as > >>>>>>>>>> protected, just with a different syntax. The cost of this is more > >>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses (is > >>>>>>>>>> this possible?) instead of a simple filter. If there is a clear benefit, > >>>>>>>>>> we can justify the more obtuse syntax. > >>>>>>>>> > >>>>>>>>> We usually try not to create new attributes until it is fully justified. > >>>>>>>>> I would like Simo to chime in on this. > >>>>>>>> > >>>>>>>> I would also prefer to reuse existing attributes and mechanism if > >>>>>>>> possible and if it will not preclude future work. > >>>>>>>> > >>>>>>>> In this case, it "sounds" like managed-by has the appropriate meaning: > >>>>>>>> "who manages the token ?" -> myself, admin, other, none ? > >>>>>>>> > >>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between > >>>>>>>> using managed-by vs a new attribute ? > >>>>>>> > >>>>>>> These are the ACIs using the protected mechanism: > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) > >>>>>>> userattr = "ipatokenOwner#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > >>>>>>> see HOTP details"; allow (read, search, compare) userattr = > >>>>>>> "ipatokenOwner#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = > >>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = > >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || > >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; > >>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) > >>>>>>> > >>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; > >>>>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = > >>>>>>> "ipatokenOwner#SELFDN";) > >>>>>>> > >>>>>>> This is what they look like using managedBy (I have not tested this): > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) > >>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) > >>>>>>> userattr = "managedBy#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow > >>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can > >>>>>>> see HOTP details"; allow (read, search, compare) userattr = > >>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > >>>>>>> "managedBy#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || > >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; > >>>>>>> allow (write) userattr = "managedBy#USERDN";) > >>>>>>> > >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>>>>>> "Managers can delete tokens"; allow (delete) userattr = > >>>>>>> "managedBy#USERDN";) > >>>>>>> > >>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and > >>>>>>> userattr = "managedBy#SELFDN";) > >>>>>>> > >>>>>>> In short: > >>>>>>> 1. Owner and manager get read, search and compare. > >>>>>>> 2. Manager gets write (to select attributes) and delete. > >>>>>>> 3. Users can create self-managed tokens for themselves only. > >>>>>>> > >>>>>>> The otptoken-add command should gain the following defaults: > >>>>>>> 1. The owner defaults to the user adding the token. > >>>>>>> 2. If owner == user adding token, managedBy defaults to owner. > >>>>>>> 3. Otherwise, managedBy defaults to None. > >>>>>>> > >>>>>>> This means that if neither owner nor managedBy are specified, the > >>>>>>> default is a self-owned, self-managed token. Likewise, if a different > >>>>>>> owner is specified, no manager is assumed. > >>>>>>> > >>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above > >>>>>>> syntax. This will become clear during testing if we want this approach. > >>>>>>> > >>>>>>> Does this look sane? > >>>>>> > >>>>>> I am not entirely sure your ACI syntax is always right for the second > >>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner > >>>>>> once for manager). > >>>>>> > >>>>>> I think the read ACIs do not need to list managedby ? Do we plan to have > >>>>>> a manager that is another regular user but not the owner nor an admin ? > >>>>>> > >>>>>> In any case I prefer the sytnax that uses managedby, as it has more > >>>>>> potential. > >>>>> > >>>>> Attached is a new version of the patch which implements the feature > >>>>> using managedBy instead of ipatokenProtected. One important thing needs > >>>>> to be said about this patch. I am not exposing managedBy in either the > >>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > >>>>> expose this similar to owner or as a relationship? > >>>> > >>>> I would expose it, as a relationship. (Note that ipatokenowner should > >>>> ideally be represented as a relationship too, but the framework does not > >>>> support 1-to-many relationships ATM.) > >>> > >>> So since this is a 1-to-many relationship we shouldn't expose it? > >>> > >>> Or should I do it like owner is currently done? > >> > >> Do it like managedby is done in the host plugin (see > >> "attribute_members", "relationships", etc.) > >> > >>> > >>>> > >>>> Just curious, why are the ACIs divided like this: > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers > >>>> can read basic token info"; allow (read, search, compare) userattr = > >>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > >>>> details"; allow (read, search, compare) userattr = > >>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > >>>> "Users/managers can see HOTP details"; allow (read, search, compare) > >>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > >>>> > >>>> IMHO you could make them less complex by dividing them like this: > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > >>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can > >>>> read token details"; allow (read, search, compare) userattr = > >>>> "ipatokenOwner#USERDN";) > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel > >>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || > >>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers > >>>> can read token details"; allow (read, search, compare) userattr = > >>>> "managedBy#USERDN";) > >>> > >>> The first set is organized by objectClass. The second by userattr. I > >>> have no strong opinion on this matter, though performance is probably a > >>> consideration. Do any DS guys want to chime in? > >> > >> I would still like to know someone else's opinion on this, but if > >> there's none, let's keep it your way. > >> > >>> > >>>> Would it make sense to keep --protected as a flag in otptoken-add as a > >>>> shortcut for "entry_attrs['managedby'] = None"? > >>> > >>> I can't think of a use case for this. The only use case I *can* think of > >>> is an admin creating a non-protected token for a user. > >> > >> OK. > >> > >>> > >>>> Would it make sense to default managedby to the current bind DN in > >>>> otptoken-add, even if it's not a user DN? (Do we want to allow running > >>>> otptoken-add by hosts/services/other non-users?) > >>> > >>> No idea. Dmitri? > >> > >> We can add this later if necessary. > >> > >>> > >>>> Is orphaning a token when a user is deleted only if it is not managed by > >>>> any other users the intended behavior? It just seems sort of strange to > >>>> me, since it changes the token from unprotected to protected. > >>> > >>> I don't think that is the behavior. We orphan the token if the owner is > >>> not listed as a manager. If the owner is listed as a manager, we delete > >>> the token. > >>> > >>> Put another way, protected tokens are orphaned and unprotected tokens > >>> are deleted. > >>> > >>> If I didn't implement that, please point out my bug. > >> > >> Sorry, my bad, your code is right. You can make it simpler, though: > >> > >> orphan = [x for x in token.get('managedby', []) if x == dn] > >> > >> (The "len() == 0" check is not necessary and using list comprehensions > >> makes the code more readable than using filter.) > > > > The attached version fixes all the above issues. Two issues that may > > remain: > > 1. There is no option to set managedBy during otptoken-add or > > otptoken-mod. This is probably okay. > > Yes. I guess this bit is not needed anymore: > > # If owner was not specified, default to the person adding > this token. > - if 'ipatokenowner' not in entry_attrs: > + # If managedby was not specified, attempt a sensible default. > + if 'ipatokenowner' not in entry_attrs or 'managedby' not in > entry_attrs: > result = self.api.Command.user_find(whoami=True)['result'] > if result: > cur_uid = result[0]['uid'][0] > - entry_attrs.setdefault('ipatokenowner', cur_uid) > + prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) > + if cur_uid == prev_uid: > + entry_attrs.setdefault('managedby', result[0]['dn']) This code is still needed. Read the patch description. And, FYI, 'managedby' is correct in this case, not 'managedby_user'. I tested. > > 2. I can't figure out how to get the framework to actually show > > managedBy in command output (like otptoken-show). This means you can > > add/remove relationships using otptoken-add-managedby and > > otptoken-remove-managedby, but you can't actually see the list of > > managers. What am I missing? > > In the hbacrule or selinuxusermap plugins it is done by adding an > "invisible" param to the object plugin, like this: > > Str('managedby_user?', > label=_('Manager'), > flags=['no_create', 'no_update', 'no_search'], > ), Done. > > > > Also, it would be helpful if someone with DS expertise could answer the > > question about the performance of the ACI structure options as listed > > above. We still need this. Ludwig? > You should update the code in user_del to use managedby_user instead of > managedby, otherwise it won't really work. Done. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0049a.2-Add-support-for-managedBy-to-tokens.patch Type: text/x-patch Size: 25028 bytes Desc: not available URL: From sbose at redhat.com Fri Jun 6 17:24:14 2014 From: sbose at redhat.com (Sumit Bose) Date: Fri, 6 Jun 2014 19:24:14 +0200 Subject: [Freeipa-devel] [RFC] Extdom plugin enhancement: grouplist Message-ID: <20140606172414.GQ5752@localhost.localdomain> Hi, I've created a design page about enhancing the extdom plugin to send the list of groups of a user together with the POSIX data to IPA clients with SSSD at http://www.freeipa.org/page/V4/Extdom_plugin_enhancement_grouplist For your convenience the text can be found below as well. Comments and suggestions are welcome. bye, Sumit = Overview = Currently on FreeIPA clients the full list of group-memberships for users from trusted domains is only available for authenticated users. Authentication is needed because the group-memberships are extracted from the PAC which is a part of the Kerberos ticket of the user. For un-authenticated users only the primary POSIX group is available. With the introduction of SSSD's ipa-server-mode IPA servers can resolve the group memberships for user from trusted domains even for un-authenticated users by reading them from the AD DCs of the trusted domains directly. This data should be made available to the IPA clients as well. = Use Cases = * Calling the 'id' command on a IPA client or calling getgrouplist() in * a process should return the full list of secondary groups for any user * from a trusted domain without requiring that the user has to log in * first ** [https://fedorahosted.org/freeipa/ticket/4031 RFE Support initgroups for unauthenticated AD users] FreeIPA ticket ** [https://fedorahosted.org/sssd/ticket/2159 RFE Support initgroups for unauthenticated AD users] SSSD ticket = Design = The IPA extdom plugin is already called by SSSD running on the IPA clients to translate SID to names or POSIX IDs. It can be enhanced to return the secondary groups as well. To make this change backward compatible in the sense that newer client can still work with older servers * a new OID can be added to the extdom plugin, currently it uses * 2.16.840.1.113730.3.8.10.4 , if we agree on this approach it might be * possible to just add a ".1" to the OID. With this the client can * determine from reading the rootDSE if the server supports this * operation or not. * the client just sends the new request and assumes in the case of a * specific error the request is not supported. A suitable error code * might be LDAP_UNWILLING_TO_PERFORM which is currently only returned by * the extdom plugin if either there is no request data or if there are * issues reading and understanding the first enumeration in the request * data (see Implementation section for more details). If the request was parsed successful the extdom plugin will return the secondary groups for the given user as a list of fully qualified group names. Additionally the POSIX user data (UID, GID, gecos, home-directory and shell) can be send. This would reduce the number of requests to the extdom plugin, because refreshing user and group-membership data often happen together. Please note that UID and GID may change due to user-views. But as long as this feature is implemented after user-views everything what is needed will be available. = Implementation = == Request == The current request looks like this: /* We expect the following request: * ExtdomRequestValue ::= SEQUENCE { * inputType ENUMERATED { * sid (1), * name (2), * posix uid (3), * posix gid (3) * }, * requestType ENUMERATED { * simple (1), * full (2) * }, * data InputData * } * * InputData ::= CHOICE { * sid OCTET STRING, * name NameDomainData * uid PosixUid, * gid PosixGid * } * * NameDomainData ::= SEQUENCE { * domain_name OCTET STRING, * object_name OCTET STRING * } * * PosixUid ::= SEQUENCE { * domain_name OCTET STRING, * uid INTEGER * } * * PosixGid ::= SEQUENCE { * domain_name OCTET STRING, * gid INTEGER * } */ Basically only a new request type must be added, e.g. * requestType ENUMERATED { * simple (1), * full (2) * full_with_groups (3) * }, But as mentioned before the LDAP_UNWILLING_TO_PERFORM error code is only send if there are issues with the inputType. The requestType is evaluated later in the existing code and the quite generic LDAP_OPERATIONS_ERROR error code is returned if an unexpected value is found. This would make the detection based on error code much more fragile. I would suggest if we do not want to use a new OID to indicate the feature, that the inputType is extended as well, e.g. by adding 128 or 256 to the values. Nevertheless I think it is less error prone to use a new OID. == Processing the request == The extdom plugin will call getgrouplist() and the resolve the fully qualified names by calling getgrgid(). By default groups from the local IPA domain are returned unqualified and the local domain name should be added in this case so that the response only contains fully qualified group names. There are two things to note here. First getgrgid() returns the full list of group members which might cause some unneeded overhead e.g. with respect to memory allocation. Second easiest way to determine if a domain name is fully qualified is to look for a '@' character. But this will only work if the full_name_format option is not changed from the default. Both can be fixed by adding a call to libsss_nss_idmap to map a GID to user and domain name. If it turns out the such a call is needed it can be added later and the extdom plugin can be updated accordingly. Additionally the extdom plugin call getpwnam() with user-view code to get the data of the POSIX user entry. == Response == Currently the response looks like: /* We send to follwing response: * ExtdomResponseValue ::= SEQUENCE { * responseType ENUMERATED { * sid (1), * name (2), * posix_user (3), * posix_group (4) * }, * data OutputData * } * * OutputData ::= CHOICE { * sid OCTET STRING, * name NameDomainData, * user PosixUser, * group PosixGroup * } * * NameDomainData ::= SEQUENCE { * domain_name OCTET STRING, * object_name OCTET STRING * } * * PosixUser ::= SEQUENCE { * domain_name OCTET STRING, * user_name OCTET STRING, * uid INTEGER * gid INTEGER * } * * PosixGroup ::= SEQUENCE { * domain_name OCTET STRING, * group_name OCTET STRING, * gid INTEGER * } */ Here a new responds type e.g. posix_user_grouplist (5) is needed which returns OutputData user_grouplist PosixUserGrouplist as PosixUser ::= SEQUENCE { domain_name OCTET STRING, user_name OCTET STRING, uid INTEGER gid INTEGER gecos OCTET STRING, home_directory OCTET STRING, shell OCTET STRING, grouplist GroupNameList } GroupNameList ::= SEQUENCE OF groupname OCTET STRING Since the new response type will only be returned if requested by the client there are no compatibility concerns because older clients cannot request it. =Feature Management = The extdom plugin is automatically configured during ipa-adtrust-install. No additional configuration is needed. == UI == n/a == CLI == n/a = Major configuration options and enablement = No additional configuration is needed. If chosen a new OID can indicate that the feature is available. = Replication = n/a = Updates and Upgrades = If the extdom plugin is already configured updating the plugin binary will automatically make the new feature available. = Dependencies = n/a = External Impact = SSSD must be able to detect the presence of the new feature by checking to new OID or a LDAP error code. = Backup and Restore = n/a = Test Plan = Besides running integration tests with a separate IPA client the plugin can be exercised manually on the server as well and since the extdom plugin uses standard libc and SSS interfaces IPA users can be requested via the extdom plugin as well. This mean the plugin can be tested on the server without established trust which I think would make it possible to include it in the CI tests as well. The current version of the extdom plugin can be manually tested in the following way: $ cat extdom_req_user_admin.asc Example Example.Sid2NameRequestValue inputType 2 requestType 1 data name data.name.domain_name ipa20.devel data.name.object_name admin $ asn1Coding extdom_req.asn extdom_req_user_admin.asc Parse: done. var=Example, value=Example.Sid2NameRequestValue var=inputType, value=2 var=requestType, value=1 var=data, value=name var=data.name.domain_name, value=ipa20.devel var=data.name.object_name, value=admin name:NULL type:SEQUENCE name:inputType type:ENUMERATED value:0x02 name:requestType type:ENUMERATED value:0x01 name:data type:CHOICE name:name type:SEQUENCE name:domain_name type:OCT_STR value:69706132302e646576656c name:object_name type:OCT_STR value:61646d696e Coding: SUCCESS ----------------- Number of bytes=30 30 1c 0a 01 02 0a 01 01 30 14 04 0b 69 70 61 32 30 2e 64 65 76 65 6c 04 05 61 64 6d 69 6e ----------------- OutputFile=extdom_req_user_admin.out Writing: done. $ cat extdom_req_user_admin.out | base64 MBwKAQIKAQEwFAQLaXBhMjAuZGV2ZWwEBWFkbWlu $ ldapexop -Y GSSAPI 2.16.840.1.113730.3.8.10.4::MBwKAQIKAQEwFAQLaXBhMjAuZGV2ZWwEBWFkbWlu SASL/GSSAPI authentication started SASL username: admin at IPA20.DEVEL SASL SSF: 56 SASL data security layer installed. # extended operation response oid: 2.16.840.1.113730.3.8.10.4 data:: MDIKAQEELVMtMS01LTIxLTEyMjMyODkxODgtMzE5ODQ0MDM1My0zMzAwMjExMDMyLTUwMA= = $ echo -n MDIKAQEELVMtMS01LTIxLTEyMjMyODkxODgtMzE5ODQ0MDM1My0zMzAwMjExMDMyLTUwMA== |base64 -d > extdom_resp_user_admin.bin $ asn1Decoding extdom_resp.asn extdom_resp_user_admin.bin Example.Sid2NameResponseValue Parse: done. Decoding: SUCCESS DECODING RESULT: name:NULL type:SEQUENCE name:responseType type:ENUMERATED value:0x01 name:data type:CHOICE name:sid type:OCT_STR value:532d312d352d32312d313232333238393138382d333139383434303335332d333330303231313033322d353030 $ echo 532d312d352d32312d313232333238393138382d333139383434303335332d333330303231313033322d353030 | xxd -r -p S-1-5-21-1223289188-3198440353-3300211032-500 = RFE Author = [[User:Sbose|Sumit Bose]] From pspacek at redhat.com Fri Jun 6 17:46:24 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Jun 2014 19:46:24 +0200 Subject: [Freeipa-devel] [PATCH 0263-0265] Support root master zone in LDAP & Follow BIND semantics for forwarders Message-ID: <5391FE70.6030405@redhat.com> Hello, This patch set contains necessary changes for supporting root master zone in LDAP. I had to remove one hack so now we follow BIND semantics for forwarders. Please see commit messages. https://fedorahosted.org/bind-dyndb-ldap/ticket/122 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0263-Refactor-DN-DNS-name-conversion.patch Type: text/x-patch Size: 10129 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0264-Support-root-master-zone-in-LDAP-Follow-BIND-semanti.patch Type: text/x-patch Size: 2607 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0265-Remove-unused-str_-functions.patch Type: text/x-patch Size: 5480 bytes Desc: not available URL: From purpleidea at gmail.com Fri Jun 6 17:51:05 2014 From: purpleidea at gmail.com (James) Date: Fri, 06 Jun 2014 13:51:05 -0400 Subject: [Freeipa-devel] Move replication topology to the shared tree In-Reply-To: <1402059813.9430.10.camel@willson.usersys.redhat.com> References: <538C39F6.2080006@redhat.com> <1402059813.9430.10.camel@willson.usersys.redhat.com> Message-ID: <1402077065.10825.4.camel@freed> On Fri, 2014-06-06 at 09:03 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 06:58 -0400, James wrote: > > On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz wrote: > > > Ticket 4302 is a request for an enhancement: Move replication topology to > > > the shared tree > > > > > > One comment to add: > > > > It would be particularly useful if the interface used to set the > > topology is something sane that a single host can use to set its > > peers. Eg: > > > > host1$ ipa-topology-set-peers host2 > > host2$ ipa-topology-set-peers host3 > > host3$ ipa-topology-set-peers host4 > > host4$ ipa-topology-set-peers host1 # redundant, but okay... > > > > This way config management could define topologies in terms of algorithms. Eg: > > > > Ring topology: > > Order hostnames alphabetically. > > Peer with host name index of self + 1 > > (Example shown above) > > > > Star topology: > > Peer with every other host in list > > > > Pick two topology: > > Peer with each subsequent hosts in ordered list... > > > > And so on... > > If running the command changes the topology again, then that's great > > because changing the algorithm would re-arrange the graph :) > > > > Hope this made sense. > > Oh it does! > > But I am dreaming even bigger, Then I like you :) > my aim is to end up (in the long run) > with something like: > > ipa topology change --stellar host1 host2 host3 host4 host5 > > causes topology for those 5 servers only (ignores any other connection) > to become: > > host2 > | > host3 - host1 - host5 > | > host4 > > So any agreement between host1 and 2,3,4,5 get wiped and replaced with > the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not > affected in any way and stay). > > And later on you'd be able to say > ipa topology change --circular host1 host2 host3 host4 > > and you get: > > host1 - host2 > | | > host4 - host3 > > Note that if you previously did the stellar thing and you only have > these 5 servers the actual complete topology ends up being like this: > > host5 > | > host1 - host2 > | | > host4 - host3 > > As the agreement between host1 and host5 is not touched by the second > command. > > But this is in the far future IMO, we'll probably start by only > implementing: > > ipa topology set-peering host1 host2 > and > ipa topology break-peering host3 host4 Sounds good to me. > > Ie creating and breaking segments in the topology tree only between > pairs and storing/deleting the segment object in the shared tree. > > The reason is that the topology plugin will allow or disallow changes > based on whether you are breaking the graph, and it is much simpler to > do that if you change one object at a time. To do the nifty stuff above > we'd need some staging area where we describe all the changes and then > have a "commit" type change that would cause the topology plugin to do > all the calculations and move stuff around inside at once (or refuse the > commit if the change as a whole breaks the graph). I like this idea of the staging area. If a ticket or BZ happens, and someone remembers, please cc me :) Cheers! > > HTH, > Simo. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Fri Jun 6 18:06:48 2014 From: purpleidea at gmail.com (James) Date: Fri, 06 Jun 2014 14:06:48 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <1402059099.9430.8.camel@willson.usersys.redhat.com> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> Message-ID: <1402078008.10825.19.camel@freed> On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 06:38 -0400, James wrote: > > Hi FreeIPA, > > > > *intro* > > > > As some of you might know, I'm currently working on deploying > > multi-master replicas with puppet. Since it looks like there will be > > security implications, I wanted to start off by trying to build some > > confidence. I want to demonstrate that I am as paranoid about getting > > the security bits right as you all are. *cough* I'm looking at you > > Simo ;) > > I am cracking my knuckles already :-) > > Comments inline. > > > I've just announced the first sane implementation for secret handling > > in puppet. Since everyone does this wrong, I thought I'd do it right, > > by pioneering a new technique. You can read about it here: > > > > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > > > In short, the dm_password and admin_password never get touched by > > puppet, and are generated locally on the freeipa server. What this > > means is that puppet doesn't know what they are, and as a result, > > can't use them to accomplish admin tasks. > > Ok let me try first to clarify what is the intent here. > > Clearly puppet has root level access to the system so you do not (should > not ?) care much about preventing access to these systems, the aim is to > not inadvertently divulge secrets through manifests and nothing else. > > Correct ? Basically yes. Secrets should not *touch* puppet. When (if) in the future puppet has less access to the system, it won't even be able to snoop passwords. > > > *replicas* > > > > ipa-replica-prepare and ipa-replica-install work _too_ well. they're > > the one part of freeipa that are so easy to use by a human, but nearly > > impossible to use with puppet (without storing the password in > > puppet). puppet can't use them as is because they need you to enter a > > password (which i don't want it to have). Here is what I propose to do > > for accomplishing this. Please correct me if I've made a mistake, or > > recommend something different. > > > > ipa-replica-prepare seems to need the dm_password. This seems to be > > needed for symmetrically encrypting the bunch of files to transfer to > > the replica. Instead, I'll patch this process to allow use of a public > > key for asymetric encryption that is unique to the receiving replica. > > I'll make sure that each ipa server generates it's own keypair, and > > that the public halves are distributed to the sending hosts. > > > > I don't think there is any other need for the dm_password in > > ipa-replica-prepare. Did I miss something? > > Yes, the dm_password was chosen because it is needed to actually > initialize and install the replica, so instead of asking it twice we > just ask for it once and use it *also* to encrypt the prepared file. But > the password is still currently absolutely necessary. Okay... But it's only needed for encryption on replica-prepare side, right? > > But let me ask a more important question, how do you distribute the > public keys securely ? Is it puppet fetching them from each > replica-to-be server and sending them to the first master server ? Yes. That is one approach. > > > ipa-replica-install needs the dm_password to decrypt the gpg file. > > Since I'm handling that with my asymmetric key pair, we don't need the > > password for that. > > Beeep, sorry wrong answer for now :-) Ah, I felt the electric shock... > > > mkosek was very kind in helping me dig through this > > part a bit, and it seems that the dm_password is needed to allow the > > replica to bind to the first server. > > It is also needed to actually store the DM password on the replica > server itself in it's own cn=Directory Manager super user entry. > Although I think we could send the hash for that. This is what I was thinking... I'll need to know how to extract this, send it (encrypted), and use it instead of --password > > > I would need some help to find an > > alternative for this process. As was suggested, perhaps a one-time > > password could be generated and sent across the wire (with puppet) to > > the replica. Any mechanism that doesn't need the dm_password would be > > great. > > Forget custom schemes. > > The simplest way to handle this (which I wanted to do for a while) is to > pre-create the replica's LDAP principal and keys at replica-prepare time > so we can start right away with GSSAPI authentication for the first > replication and create agreements directly using GSSAPI auth. This would > in turn simplify replication agreements creation as we won't need > anymore to do the dance where we create the agreement with a plain text > bind and then we need to convert the agreement to use GSSAPI. This of course sounds fine to me. As long as it meets my criteria of not needing the password, it should work. Is this an easy patch? IOW something that I could test a build of within the next month at the latest? > > > I don't think there is any other need for the dm_password in > > ipa-replica-install. Did I miss something? > > See above, it needs the password to actually create the DM account at DS > setup time. *also* the DM password is used to setup some parts of the > dogtag CA so if any of your replica is also a CA clone you go straight > back to needing the DM password. Which I understand we could get around by passing around the (salted?) hashed password, correct? > > > Of course if I store the dm_password in puppet, then it's easy to do > > this peering because it will be easy to use the password on each host. > > I could be done my puppet module already :) But I'm going out of my > > way to do it right, so that you'll all be proud of the work too! > > Ok, here is a quickest method to do what you want to do IMO: > > First of all, you need a DM password for the initial server and you need > to store it somewhere because the admin must know what it is, there is > no way around this. > So I guess you are planning to store it in a file under /root in the > master server or something like that. This means puppet has access to > the DM password w/o storing it in the manifest. Wrong. The whole idea is I want to keep puppet's grubby hands off the password. I generate the password on the host, encrypt it with the admin's public key, and never store it unencrypted. More details here: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > Use the DM password to do everything as usual AND create the asymmetric > keys in the replicas and *securely* transmit them to the master. Keep in mind I'm only transmitting public keys, so it doesn't have to be secure as long as I know verify the identity. > > Now wrap the current replica file (yes it is already encrypted, who > cares), AND the DM password into a new envelope encrypted with your > public keys. > > Presto! Now you transfer the blob back to the replicas, and each replica > can be scripted, and puppet has no passwords in its manifest. This approach won't work because the first axiom is incorrect. To do this, I would have to keep the dm_password around on each host with a key that could be read and used by anyone with root. So effectively I might as well store the password in puppet. > > > *symmetry* > > > > It would be especially elegant and beneficial to FreeIPA and the > > puppet module if the process of "peering" was symmetrical, that is to > > say, similar for any host. If I could use ipa-server-install to setup > > N hosts, and then run a secondary command to cause certain ones to > > "join" this would make the process much more natural for puppet. > > This is intrinsically not possible. That is unfortunate. I could hack a version of this where by each host runs the installer, but the ones that need to peer start by running: ipa-server-install --uninstall && ipa-replica-install but that is less elegant that the solution existing natively. > > > In addition, this would ensure that the configuration management itself > > is HA. Without this type of functionality, then if the first ipa > > server isn't available, then config management will be blocked. > > Yeah, chicken-egg issues of bootstrapping infrastructures. I currently > do not see any way around this. See my above idea for a dirty hack. (--uninstall) > > > I would appreciate any recommendations on how to convert a previously > > installed ipa server into a replica. Of course it's fine that it will > > have it's data overwritten. > > If you overwrite all data what is the point really ? You are still > dependent on exactly ONE master replicating to all others first, until > then you cannot do anything, as any operation you would do against any > other server would be erased and wiped. The point is that nothing in your config management process (think 100% automatic without human intervention) can stall. Even if something fails, there's a path by which it can continue, even if it means wiping out a server. Highly available config management is necessary for certain futures. > > HTH, > Simo. > Thanks for reading! James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Fri Jun 6 18:12:14 2014 From: purpleidea at gmail.com (James) Date: Fri, 06 Jun 2014 14:12:14 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <20140606120331.GM1482@redhat.com> References: <20140606120331.GM1482@redhat.com> Message-ID: <1402078334.10825.23.camel@freed> On Fri, 2014-06-06 at 14:03 +0200, Jan Pazdziora wrote: > On Fri, Jun 06, 2014 at 06:38:10AM -0400, James wrote: > > > > I've just announced the first sane implementation for secret handling > > in puppet. Since everyone does this wrong, I thought I'd do it right, > > by pioneering a new technique. You can read about it here: > > > > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ > > > > In short, the dm_password and admin_password never get touched by > > puppet, and are generated locally on the freeipa server. What this > > means is that puppet doesn't know what they are, and as a result, > > can't use them to accomplish admin tasks. > > Could we make this functionality part of the ipa-server-install script > itself? It could be useful outside of puppet as well? Actually, that is an interesting question! You could for certain use cases, although the amount of different use cases I am currently supporting in the code makes it probably not useful. So I would probably not recommend this. I would wait six months for puppet-ipa to stabilize, and then see what common functionality can be merged into FreeIPA. I already have a few items that could if you're interested in specifics (we can talk offline). > > Do you have any proposal how to go about ipa-client-install in puppet, > without having the password stored/exposed there? Actually Yes! This is a tricky operation in puppet, but it all fully works. It automatically uses an exported one time password from the host. I should probably write up an article on this process. It has more features too. If you want to play in the code, ping me offline or on IRC, and I can orient you on the steps. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From purpleidea at gmail.com Fri Jun 6 18:17:01 2014 From: purpleidea at gmail.com (James) Date: Fri, 06 Jun 2014 14:17:01 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <20140606131050.GP1482@redhat.com> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> <20140606131050.GP1482@redhat.com> Message-ID: <1402078621.10825.28.camel@freed> On Fri, 2014-06-06 at 15:10 +0200, Jan Pazdziora wrote: > On Fri, Jun 06, 2014 at 08:51:39AM -0400, Simo Sorce wrote: > > > > Clearly puppet has root level access to the system so you do not (should > > not ?) care much about preventing access to these systems, the aim is to > > not inadvertently divulge secrets through manifests and nothing else. > > And puppet logs. And forgetting the secrets around. Right... A good reason to not store anything in puppet. > > With puppet you do not have interactive (password) prompt available so > everything including secrets needs to be pre-created and pre-populated > before the puppet apply starts. Or, where possible, generated and > immediatelly encrypted -- I find that approach very clever. Thanks :) > But > unfortunately it can only be used for the initial FreeIPA server > installation, it seems -- in all the subsequent operations, we need to > pass the existing matching credential. Right... This is what I'm trying to work around. I only need this for additional replicas. The single master case is basically *solved*. But it's no fun to stop there... > > I wonder if we could be able to pass the passwords to puppet via file > descriptors from some invoking wrapper ... See my comment on: https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ about an interactive password helper. This could be useful for something when puppet-freeipa is being used with other tools that insist on telling it the password... Functionally the issues with the replicas don't dissapear. We have to pretend that the password is still "forgotten" after initial install of first master. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From npmccallum at redhat.com Fri Jun 6 18:33:47 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 06 Jun 2014 14:33:47 -0400 Subject: [Freeipa-devel] [PATCHES] Update plugins to use Registry API Message-ID: <1402079627.4323.42.camel@ipa.example.com> I kept seeing the old plugin registration style when writing/reviewing code and I decided to fix it. Attached are patches to update the remaining 31 plugins from the old plugin registration style to the new style. This would be a great starting point for someone new to doing reviews. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0031-Update-trust-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 7183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0030-Update-sudorule-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 8235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0029-Update-sudocmdgroup-plugin-to-support-new-Registry-A.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0028-Update-sudocmd-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2093 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0027-Update-service-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0026-Update-selinuxusermap-plugin-to-support-new-Registry.patch Type: text/x-patch Size: 4599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0025-Update-selfservice-plugin-to-support-new-Registry-AP.patch Type: text/x-patch Size: 2586 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0024-Update-role-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0023-Update-realmdomains-plugin-to-support-new-Registry-A.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-Update-pkinit-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-Update-passwd-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-Update-netgroup-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-Update-misc-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1490 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-Update-migration-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Update-kerberos-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Update-internal-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1286 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Update-idrange-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2296 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Update-hostgroup-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Update-host-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Update-hbactest-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Update-hbacsvcgroup-plugin-to-support-new-Registry-A.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Update-hbacsvc-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Update-hbacrule-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 5469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Update-group-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3429 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Update-dns-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 7268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Update-delegation-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Update-config-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1816 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Update-cert-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 2795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Update-batch-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 1015 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Update-automount-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 6034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-user-plugin-to-support-new-Registry-API.patch Type: text/x-patch Size: 3538 bytes Desc: not available URL: From edewata at redhat.com Fri Jun 6 18:35:53 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 06 Jun 2014 13:35:53 -0500 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <5391E19A.5080806@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> <5391C5FD.5060908@redhat.com> <5391E19A.5080806@redhat.com> Message-ID: <53920A09.5030001@redhat.com> On 6/6/2014 10:43 AM, Petr Vobornik wrote: > On 6.6.2014 15:45, Endi Sukma Dewata wrote: >> On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote: >>> ACK for patches #592-#628. I'll continue reviewing the rest. >> >> ACK for patches #633-639, #642, #644, #652, and #653. Patches #640 & >> #641 have an issue (see #19 below) that should be fixed before pushing. >> Other issues are minor/unrelated/suggestions that can be addressed >> separately. > > Thank you for the review. > > I've fixed issues: > > - #19, #20 in patch #640. > > And some low hanging fruit: > - #16, in patch #637 > - #17, in patch #612 > - #13, in patch #612 > > The branch has been rebased to current master. ACK. > I am not able to reproduce issues #4 and #11. >> 4. In the list page (e.g. Users) in mobile mode the Refresh button may overlap the search box. Here's what I saw as I was adjusting the page width: http://edewata.fedorapeople.org/ipa/images/snapshot1.png http://edewata.fedorapeople.org/ipa/images/snapshot2.png http://edewata.fedorapeople.org/ipa/images/snapshot3.png Notice that in snapshot #2 the search box is partially covered by the Refresh button. >> 11. In desktop mode the QR code for new OTP token is displayed outside the dialog box. Here's what I saw: http://edewata.fedorapeople.org/ipa/images/snapshot4.png >> 18. In the New Certificate dialog for Host, the instruction to create a >> CSR exceeds the dialog boundary. > > caused by BS' CSS: > code { > white-space: nowrap; > } > > I wonder if the best solution is to reset it to initial value in all > dialogs. Alternatively, the sample command could be broken into two lines. >> 20. The capitalization of "Certificate" is inconsistent in Host's and >> Service's Actions. > > Fixed The "View certificate" is still inconsistent though. -- Endi S. Dewata From simo at redhat.com Fri Jun 6 18:43:04 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Jun 2014 14:43:04 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <1402078008.10825.19.camel@freed> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> <1402078008.10825.19.camel@freed> Message-ID: <1402080184.9430.30.camel@willson.usersys.redhat.com> On Fri, 2014-06-06 at 14:06 -0400, James wrote: > On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: > > Yes, the dm_password was chosen because it is needed to actually > > initialize and install the replica, so instead of asking it twice we > > just ask for it once and use it *also* to encrypt the prepared file. But > > the password is still currently absolutely necessary. > Okay... But it's only needed for encryption on replica-prepare side, > right? We use it to encrypt the package and also to check that it is indeed the correct password by performing a successful bind to LDAP. I think we may be using it also to generate the certificates for the replica, but I haven't looked at that code for a while and may be remembering incorrectly. > > But let me ask a more important question, how do you distribute the > > public keys securely ? Is it puppet fetching them from each > > replica-to-be server and sending them to the first master server ? > Yes. That is one approach. What did you have in mind ? > > It is also needed to actually store the DM password on the replica > > server itself in it's own cn=Directory Manager super user entry. > > Although I think we could send the hash for that. > This is what I was thinking... I'll need to know how to extract this, > send it (encrypted), and use it instead of --password It might be greppable out of the dse.ldif file I think. > > > I would need some help to find an > > > alternative for this process. As was suggested, perhaps a one-time > > > password could be generated and sent across the wire (with puppet) to > > > the replica. Any mechanism that doesn't need the dm_password would be > > > great. > > > > Forget custom schemes. > > > > The simplest way to handle this (which I wanted to do for a while) is to > > pre-create the replica's LDAP principal and keys at replica-prepare time > > so we can start right away with GSSAPI authentication for the first > > replication and create agreements directly using GSSAPI auth. This would > > in turn simplify replication agreements creation as we won't need > > anymore to do the dance where we create the agreement with a plain text > > bind and then we need to convert the agreement to use GSSAPI. > > This of course sounds fine to me. As long as it meets my criteria of not > needing the password, it should work. Is this an easy patch? IOW > something that I could test a build of within the next month at the > latest? Well, you may not need a password (you do because you need to be DM on the replica to create replication agreements, but we can do some magic there and use ldapi as root I guess) but you'll need a keytab, which is a secret, just like a password and must not be exposed to anyone and anything just like the DM password. But that wouldn't be a problem, the keytab would be in the encrypted prepared file. > > > I don't think there is any other need for the dm_password in > > > ipa-replica-install. Did I miss something? > > > > See above, it needs the password to actually create the DM account at DS > > setup time. *also* the DM password is used to setup some parts of the > > dogtag CA so if any of your replica is also a CA clone you go straight > > back to needing the DM password. > Which I understand we could get around by passing around the (salted?) > hashed password, correct? Not for the CA, unfortunately the CA requires the DM password in the clear. > > > Of course if I store the dm_password in puppet, then it's easy to do > > > this peering because it will be easy to use the password on each host. > > > I could be done my puppet module already :) But I'm going out of my > > > way to do it right, so that you'll all be proud of the work too! > > > > Ok, here is a quickest method to do what you want to do IMO: > > > > First of all, you need a DM password for the initial server and you need > > to store it somewhere because the admin must know what it is, there is > > no way around this. > > So I guess you are planning to store it in a file under /root in the > > master server or something like that. This means puppet has access to > > the DM password w/o storing it in the manifest. > Wrong. The whole idea is I want to keep puppet's grubby hands off the > password. I generate the password on the host, encrypt it with the > admin's public key, and never store it unencrypted. More details here: > https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/ Sure, I do not mean that puppet needs to transport it in the clear, but it gets to know it in the abstract, either because it generates it (on the ipa server) or because it transports it (encrypted) and unpacks it in the replicas. But the fact is a certain points it must have access to it to do the initial install. > > Use the DM password to do everything as usual AND create the asymmetric > > keys in the replicas and *securely* transmit them to the master. > Keep in mind I'm only transmitting public keys, so it doesn't have to be > secure as long as I know verify the identity. Bzzzzzzzzt. How do I know that "these are the public key I am looking for" if they are not transmitted securely ? If someone can sneak in an additional key or replace a public key in transit now it gets access to everything as soon you transmit the encrypted package! > > Now wrap the current replica file (yes it is already encrypted, who > > cares), AND the DM password into a new envelope encrypted with your > > public keys. > > > > Presto! Now you transfer the blob back to the replicas, and each replica > > can be scripted, and puppet has no passwords in its manifest. > > This approach won't work because the first axiom is incorrect. To do > this, I would have to keep the dm_password around on each host with a > key that could be read and used by anyone with root. So effectively I > might as well store the password in puppet. Look, at the moment there is no way around that, you have to have the DM password *or* an equivalent secret to install replicas, there is simply no way around that. You need to transport some form of credentials from the master ipa server to the replicas because the replicas need to authenticate to the master in order to be allowed to become replicas. It is as simple as that, whether it is the DM password, or a keytab, or something else. > > > *symmetry* > > > > > > It would be especially elegant and beneficial to FreeIPA and the > > > puppet module if the process of "peering" was symmetrical, that is to > > > say, similar for any host. If I could use ipa-server-install to setup > > > N hosts, and then run a secondary command to cause certain ones to > > > "join" this would make the process much more natural for puppet. > > > > This is intrinsically not possible. > That is unfortunate. I could hack a version of this where by each host > runs the installer, but the ones that need to peer start by running: > > ipa-server-install --uninstall && ipa-replica-install > > but that is less elegant that the solution existing natively. It is not about being inelegant, it is about being useless to me. > > > In addition, this would ensure that the configuration management itself > > > is HA. Without this type of functionality, then if the first ipa > > > server isn't available, then config management will be blocked. > > > > Yeah, chicken-egg issues of bootstrapping infrastructures. I currently > > do not see any way around this. > > See my above idea for a dirty hack. (--uninstall) install; uninstall; replica-install ... the first 2 steps are a no-op. > The point is that nothing in your config management process (think 100% > automatic without human intervention) can stall. Even if something > fails, there's a path by which it can continue, even if it means wiping > out a server. Highly available config management is necessary for > certain futures. Sure, if the first server install fails you wipe and restart, where is the problem ? Simo. -- Simo Sorce * Red Hat, Inc * New York From purpleidea at gmail.com Fri Jun 6 21:57:27 2014 From: purpleidea at gmail.com (James) Date: Fri, 06 Jun 2014 17:57:27 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <1402080184.9430.30.camel@willson.usersys.redhat.com> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> <1402078008.10825.19.camel@freed> <1402080184.9430.30.camel@willson.usersys.redhat.com> Message-ID: <1402091847.10825.40.camel@freed> On Fri, 2014-06-06 at 14:43 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 14:06 -0400, James wrote: > > On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: > > > But let me ask a more important question, how do you distribute the > > > public keys securely ? Is it puppet fetching them from each > > > replica-to-be server and sending them to the first master server ? > > Yes. That is one approach. > > What did you have in mind ? Actually, I'm good with this. If someone is unnecessarily paranoid I could probably mangle this over SSH, but I'd like to avoid it. It still requires distributing the SSH fingerprints over puppet... > > > > It is also needed to actually store the DM password on the replica > > > server itself in it's own cn=Directory Manager super user entry. > > > Although I think we could send the hash for that. > > This is what I was thinking... I'll need to know how to extract this, > > send it (encrypted), and use it instead of --password > > It might be greppable out of the dse.ldif file I think. Can you help me with the specific commands for a Proof Of Concept? I have found /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif (attached) How do I find a password in there? ( I couldn't see any ) How do I get that back in on the destination replica side once I find it? > > > > > > The simplest way to handle this (which I wanted to do for a while) is to > > > pre-create the replica's LDAP principal and keys at replica-prepare time > > > so we can start right away with GSSAPI authentication for the first > > > replication and create agreements directly using GSSAPI auth. This would > > > in turn simplify replication agreements creation as we won't need > > > anymore to do the dance where we create the agreement with a plain text > > > bind and then we need to convert the agreement to use GSSAPI. > > > > This of course sounds fine to me. As long as it meets my criteria of not > > needing the password, it should work. Is this an easy patch? IOW > > something that I could test a build of within the next month at the > > latest? > > Well, you may not need a password (you do because you need to be DM on > the replica to create replication agreements, but we can do some magic > there and use ldapi as root I guess) but you'll need a keytab, which is > a secret, just like a password and must not be exposed to anyone and > anything just like the DM password. But that wouldn't be a problem, the > keytab would be in the encrypted prepared file. Great! Can you show to me how to do this part please? * Generate this specific keytab * Use it to complete the ipa-replica-install process > > > > > I don't think there is any other need for the dm_password in > > > > ipa-replica-install. Did I miss something? > > > > > > See above, it needs the password to actually create the DM account at DS > > > setup time. *also* the DM password is used to setup some parts of the > > > dogtag CA so if any of your replica is also a CA clone you go straight > > > back to needing the DM password. > > Which I understand we could get around by passing around the (salted?) > > hashed password, correct? > > Not for the CA, unfortunately the CA requires the DM password in the > clear. I'll skip over doing the CA part for now... Sounds like I need to break this into smaller challenges ;) > > > Use the DM password to do everything as usual AND create the asymmetric > > > keys in the replicas and *securely* transmit them to the master. > > Keep in mind I'm only transmitting public keys, so it doesn't have to be > > secure as long as I know verify the identity. > > Bzzzzzzzzt. How do I know that "these are the public key I am looking > for" if they are not transmitted securely ? > If someone can sneak in an additional key or replace a public key in > transit now it gets access to everything as soon you transmit the > encrypted package! Agreed. As discussed, I'm assuming that Puppet master has securely authenticated it's individual puppet clients, and I am relying on that trust to pass the public keys around. > > > > Now wrap the current replica file (yes it is already encrypted, who > > > cares), AND the DM password into a new envelope encrypted with your > > > public keys. > > > > > > Presto! Now you transfer the blob back to the replicas, and each replica > > > can be scripted, and puppet has no passwords in its manifest. > > > > This approach won't work because the first axiom is incorrect. To do > > this, I would have to keep the dm_password around on each host with a > > key that could be read and used by anyone with root. So effectively I > > might as well store the password in puppet. > > Look, at the moment there is no way around that, you have to have the DM > password *or* an equivalent secret to install replicas, there is simply > no way around that. You need to transport some form of credentials from > the master ipa server to the replicas because the replicas need to > authenticate to the master in order to be allowed to become replicas. > It is as simple as that, whether it is the DM password, or a keytab, or > something else. I'd like to learn how to do this keytab solution for this scenario, or perhaps use an OTP to authenticate... The OTP would be carried in the pseudo-secure puppet channel. > > > > > *symmetry* > > > > > > > > It would be especially elegant and beneficial to FreeIPA and the > > > > puppet module if the process of "peering" was symmetrical, that is to > > > > say, similar for any host. If I could use ipa-server-install to setup > > > > N hosts, and then run a secondary command to cause certain ones to > > > > "join" this would make the process much more natural for puppet. > > > > > > This is intrinsically not possible. > > That is unfortunate. I could hack a version of this where by each host > > runs the installer, but the ones that need to peer start by running: > > > > ipa-server-install --uninstall && ipa-replica-install > > > > but that is less elegant that the solution existing natively. > > It is not about being inelegant, it is about being useless to me. hehe, fair enough. I'll try and think if I can come up with a POC of why it's needed. If it turns out to be a requirement, we can revisit it. > > > > > In addition, this would ensure that the configuration management itself > > > > is HA. Without this type of functionality, then if the first ipa > > > > server isn't available, then config management will be blocked. > > > > > > Yeah, chicken-egg issues of bootstrapping infrastructures. I currently > > > do not see any way around this. > > > > See my above idea for a dirty hack. (--uninstall) > > install; uninstall; replica-install ... the first 2 steps are a no-op. Agreed. It wasn't about trying to simplify down to a no-op, it was about having a path in the state graph of going from installed => replica. Currently you can do: uninstalled => installed. installed => uninstalled. uninstalled => replica-ed. But no: installed => replica-ed. So until that pathway is is possible, I will have to "fake it" by doing an installed => uninstalled, so that I can turn an installed machine into a replica. Cheers, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Fri Jun 6 22:22:33 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Jun 2014 16:22:33 -0600 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <1402091847.10825.40.camel@freed> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> <1402078008.10825.19.camel@freed> <1402080184.9430.30.camel@willson.usersys.redhat.com> <1402091847.10825.40.camel@freed> Message-ID: <53923F29.3020500@redhat.com> On 06/06/2014 03:57 PM, James wrote: > On Fri, 2014-06-06 at 14:43 -0400, Simo Sorce wrote: >> On Fri, 2014-06-06 at 14:06 -0400, James wrote: >>> On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: > >>>> But let me ask a more important question, how do you distribute the >>>> public keys securely ? Is it puppet fetching them from each >>>> replica-to-be server and sending them to the first master server ? >>> Yes. That is one approach. >> What did you have in mind ? > Actually, I'm good with this. If someone is unnecessarily paranoid I > could probably mangle this over SSH, but I'd like to avoid it. It still > requires distributing the SSH fingerprints over puppet... > >>>> It is also needed to actually store the DM password on the replica >>>> server itself in it's own cn=Directory Manager super user entry. >>>> Although I think we could send the hash for that. >>> This is what I was thinking... I'll need to know how to extract this, >>> send it (encrypted), and use it instead of --password >> It might be greppable out of the dse.ldif file I think. > Can you help me with the specific commands for a Proof Of Concept? > I have found /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > (attached) grep nsslapd-rootpw /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif The pwdhash command can be used to create a hashed password. > > How do I find a password in there? ( I couldn't see any ) > How do I get that back in on the destination replica side once I find > it? >>>> The simplest way to handle this (which I wanted to do for a while) is to >>>> pre-create the replica's LDAP principal and keys at replica-prepare time >>>> so we can start right away with GSSAPI authentication for the first >>>> replication and create agreements directly using GSSAPI auth. This would >>>> in turn simplify replication agreements creation as we won't need >>>> anymore to do the dance where we create the agreement with a plain text >>>> bind and then we need to convert the agreement to use GSSAPI. >>> This of course sounds fine to me. As long as it meets my criteria of not >>> needing the password, it should work. Is this an easy patch? IOW >>> something that I could test a build of within the next month at the >>> latest? >> Well, you may not need a password (you do because you need to be DM on >> the replica to create replication agreements, but we can do some magic >> there and use ldapi as root I guess) but you'll need a keytab, which is >> a secret, just like a password and must not be exposed to anyone and >> anything just like the DM password. But that wouldn't be a problem, the >> keytab would be in the encrypted prepared file. > Great! Can you show to me how to do this part please? > * Generate this specific keytab > * Use it to complete the ipa-replica-install process > >>>>> I don't think there is any other need for the dm_password in >>>>> ipa-replica-install. Did I miss something? >>>> See above, it needs the password to actually create the DM account at DS >>>> setup time. *also* the DM password is used to setup some parts of the >>>> dogtag CA so if any of your replica is also a CA clone you go straight >>>> back to needing the DM password. >>> Which I understand we could get around by passing around the (salted?) >>> hashed password, correct? >> Not for the CA, unfortunately the CA requires the DM password in the >> clear. > I'll skip over doing the CA part for now... Sounds like I need to break > this into smaller challenges ;) > >>>> Use the DM password to do everything as usual AND create the asymmetric >>>> keys in the replicas and *securely* transmit them to the master. >>> Keep in mind I'm only transmitting public keys, so it doesn't have to be >>> secure as long as I know verify the identity. >> Bzzzzzzzzt. How do I know that "these are the public key I am looking >> for" if they are not transmitted securely ? >> If someone can sneak in an additional key or replace a public key in >> transit now it gets access to everything as soon you transmit the >> encrypted package! > Agreed. As discussed, I'm assuming that Puppet master has securely > authenticated it's individual puppet clients, and I am relying on that > trust to pass the public keys around. > >>>> Now wrap the current replica file (yes it is already encrypted, who >>>> cares), AND the DM password into a new envelope encrypted with your >>>> public keys. >>>> >>>> Presto! Now you transfer the blob back to the replicas, and each replica >>>> can be scripted, and puppet has no passwords in its manifest. >>> This approach won't work because the first axiom is incorrect. To do >>> this, I would have to keep the dm_password around on each host with a >>> key that could be read and used by anyone with root. So effectively I >>> might as well store the password in puppet. >> Look, at the moment there is no way around that, you have to have the DM >> password *or* an equivalent secret to install replicas, there is simply >> no way around that. You need to transport some form of credentials from >> the master ipa server to the replicas because the replicas need to >> authenticate to the master in order to be allowed to become replicas. >> It is as simple as that, whether it is the DM password, or a keytab, or >> something else. > I'd like to learn how to do this keytab solution for this scenario, or > perhaps use an OTP to authenticate... The OTP would be carried in the > pseudo-secure puppet channel. > >>>>> *symmetry* >>>>> >>>>> It would be especially elegant and beneficial to FreeIPA and the >>>>> puppet module if the process of "peering" was symmetrical, that is to >>>>> say, similar for any host. If I could use ipa-server-install to setup >>>>> N hosts, and then run a secondary command to cause certain ones to >>>>> "join" this would make the process much more natural for puppet. >>>> This is intrinsically not possible. >>> That is unfortunate. I could hack a version of this where by each host >>> runs the installer, but the ones that need to peer start by running: >>> >>> ipa-server-install --uninstall && ipa-replica-install >>> >>> but that is less elegant that the solution existing natively. >> It is not about being inelegant, it is about being useless to me. > hehe, fair enough. I'll try and think if I can come up with a POC of why > it's needed. If it turns out to be a requirement, we can revisit it. > >>>>> In addition, this would ensure that the configuration management itself >>>>> is HA. Without this type of functionality, then if the first ipa >>>>> server isn't available, then config management will be blocked. >>>> Yeah, chicken-egg issues of bootstrapping infrastructures. I currently >>>> do not see any way around this. >>> See my above idea for a dirty hack. (--uninstall) >> install; uninstall; replica-install ... the first 2 steps are a no-op. > Agreed. It wasn't about trying to simplify down to a no-op, it was about > having a path in the state graph of going from installed => replica. > Currently you can do: > > uninstalled => installed. > installed => uninstalled. > uninstalled => replica-ed. > > But no: > > installed => replica-ed. > > So until that pathway is is possible, I will have to "fake it" by doing > an installed => uninstalled, so that I can turn an installed machine > into a replica. > > Cheers, > James > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at gmail.com Sat Jun 7 03:59:20 2014 From: purpleidea at gmail.com (James) Date: Fri, 6 Jun 2014 23:59:20 -0400 Subject: [Freeipa-devel] Multi-master replication with puppet In-Reply-To: <53923F29.3020500@redhat.com> References: <1402059099.9430.8.camel@willson.usersys.redhat.com> <1402078008.10825.19.camel@freed> <1402080184.9430.30.camel@willson.usersys.redhat.com> <1402091847.10825.40.camel@freed> <53923F29.3020500@redhat.com> Message-ID: On Fri, Jun 6, 2014 at 6:22 PM, Rich Megginson wrote: > > grep nsslapd-rootpw /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif > > The pwdhash command can be used to create a hashed password. Ah, brilliant, this works great, thanks!! From mkosek at redhat.com Mon Jun 9 06:21:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Jun 2014 08:21:29 +0200 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <1402069631.4323.35.camel@ipa.example.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> Message-ID: <53955269.8060301@redhat.com> On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: > On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: >> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: >>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: >>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: >>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: >>>>>> I have rebased theold patch attached to the ticket, unfortunately I >>>>>> haven't had time to test it yet, but didn't want to lose it in some >>>>>> branch. >>>>>> >>>>>> Simo. >>>>> >>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am willing >>>>> to ACK it. >>>>> >>>>> I am just wondering if there is any scenario we could have missed, but I did >>>>> not find any. In there is no push back against the patch I may just push it. >>> >>>> The only thing I would draw attention to is the fact that now I am >>>> sending back the error directly once we have a negative return from the >>>> function in which expiration is checked (ipapwd_authenticate). >>>> >>>> I could not see why we did, in fact, not do that before and I meant >>>> asking Nathaniel if he had an explicit reason why we do not, as he is >>>> the last one that did some significant refactoring in the bind preop >>>> plugin. >>> >>> In the current design, if ipapwd_authenticate() fails, we defer to 389ds >>> for the actual response to the client. The purpose for this is so that >>> verification of the first factor always behaves the same, regardless of >>> what is in pre-bind. >>> >>> So ipapwd_authenticate() is not actually the "final" authentication. It >>> is a preliminary authentication to determine if the user should be able >>> to write kerberos keys and perform OTP sync. So checking expiration in >>> pre-bind only protects these two operations. >>> >>> I presume that 389ds also checks password expiration. If this assumption >>> is true, ipapwd_authenticate() SHOULD NOT return any response to the >>> client. It should simply fail key-write/otp-sync silently and let dirsrv >>> return the error to the client. >> >> 389ds would check it if we were using 389ds native password policies but >> we are not. So we need to check on our own, which is what this patch >> implements. >> >>> The important point here is that so long as 389ds is verifying password >>> expiration, using a correct-but-expired password will should not result >>> in a bind in the current code. It will result in kerberos key writing >>> and OTP sync. Do we actually care about protecting kerberos key writing >>> and OTP sync from correct-but-expired passwords? >> >> No, but that's not the point. >> >>> If 389ds does not check password expiration, then we probably need to >>> patch upstream 389ds or, at the very least, return an error to the >>> client. >> >> It is not a 389ds bug, it is just an integration issue due to the fact >> IPA uses a different schema for password policies (for compatibility >> with the Kerberos schema). >> >>> Otherwise, if we don't care about protecting kerberos key writing and >>> OTP sync from correct-but-expired passwords, this patch is entirely >>> unnecessary. >>> >>> Otherwise, the patch is necessary, but should skip kerberos key writing >>> and OTP sync and fall through silently to 389ds. >> >> If we fall through to 389ds then authentication will succeed. >> >> So from this discussion it seem to me we achieve the goal of the patch >> and returning an error directly is ok. >> >> Unless Nathaniel has something *against* returning an error in this >> place I think we are good to go. > > Looks good to me. ACK. > > Nathaniel > Ok, thanks for discussion and double checking! Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 Martin From mkosek at redhat.com Mon Jun 9 08:59:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Jun 2014 10:59:09 +0200 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <53955269.8060301@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> Message-ID: <5395775D.8080609@redhat.com> On 06/09/2014 08:21 AM, Martin Kosek wrote: > On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: >> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: >>> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: >>>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: >>>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: >>>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: >>>>>>> I have rebased theold patch attached to the ticket, unfortunately I >>>>>>> haven't had time to test it yet, but didn't want to lose it in some >>>>>>> branch. >>>>>>> >>>>>>> Simo. >>>>>> >>>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am willing >>>>>> to ACK it. >>>>>> >>>>>> I am just wondering if there is any scenario we could have missed, but I did >>>>>> not find any. In there is no push back against the patch I may just push it. >>>> >>>>> The only thing I would draw attention to is the fact that now I am >>>>> sending back the error directly once we have a negative return from the >>>>> function in which expiration is checked (ipapwd_authenticate). >>>>> >>>>> I could not see why we did, in fact, not do that before and I meant >>>>> asking Nathaniel if he had an explicit reason why we do not, as he is >>>>> the last one that did some significant refactoring in the bind preop >>>>> plugin. >>>> >>>> In the current design, if ipapwd_authenticate() fails, we defer to 389ds >>>> for the actual response to the client. The purpose for this is so that >>>> verification of the first factor always behaves the same, regardless of >>>> what is in pre-bind. >>>> >>>> So ipapwd_authenticate() is not actually the "final" authentication. It >>>> is a preliminary authentication to determine if the user should be able >>>> to write kerberos keys and perform OTP sync. So checking expiration in >>>> pre-bind only protects these two operations. >>>> >>>> I presume that 389ds also checks password expiration. If this assumption >>>> is true, ipapwd_authenticate() SHOULD NOT return any response to the >>>> client. It should simply fail key-write/otp-sync silently and let dirsrv >>>> return the error to the client. >>> >>> 389ds would check it if we were using 389ds native password policies but >>> we are not. So we need to check on our own, which is what this patch >>> implements. >>> >>>> The important point here is that so long as 389ds is verifying password >>>> expiration, using a correct-but-expired password will should not result >>>> in a bind in the current code. It will result in kerberos key writing >>>> and OTP sync. Do we actually care about protecting kerberos key writing >>>> and OTP sync from correct-but-expired passwords? >>> >>> No, but that's not the point. >>> >>>> If 389ds does not check password expiration, then we probably need to >>>> patch upstream 389ds or, at the very least, return an error to the >>>> client. >>> >>> It is not a 389ds bug, it is just an integration issue due to the fact >>> IPA uses a different schema for password policies (for compatibility >>> with the Kerberos schema). >>> >>>> Otherwise, if we don't care about protecting kerberos key writing and >>>> OTP sync from correct-but-expired passwords, this patch is entirely >>>> unnecessary. >>>> >>>> Otherwise, the patch is necessary, but should skip kerberos key writing >>>> and OTP sync and fall through silently to 389ds. >>> >>> If we fall through to 389ds then authentication will succeed. >>> >>> So from this discussion it seem to me we achieve the goal of the patch >>> and returning an error directly is ok. >>> >>> Unless Nathaniel has something *against* returning an error in this >>> place I think we are good to go. >> >> Looks good to me. ACK. >> >> Nathaniel >> > > Ok, thanks for discussion and double checking! > > Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 > > Martin I just read a question in the ticket from alonbl about how password change should work on the LDAP level: https://fedorahosted.org/freeipa/ticket/1539#comment:29 Are we ready to say that from now on, expired passwords cannot be changed via LDAP? I.e. this workflow will no longer work: $ ipa user-add --first=Foo --last Bar expired --random -------------------- Added user "expired" -------------------- User login: expired First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/expired GECOS: Foo Bar Login shell: /bin/sh Kerberos principal: expired at MKOSEK-FEDORA20.TEST Email address: expired at mkosek-fedora20.test Random password: qiCjofo.2pfT UID: 1170600026 GID: 1170600026 Password: True Member of groups: ipausers Kerberos keys available: True $ ldappasswd -h `hostname` -D uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -x -w qiCjofo.2pfT uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -a qiCjofo.2pfT -s Secret123 ldap_bind: Invalid credentials (49) additional info: The user password is expired Thanks, Martin From pviktori at redhat.com Mon Jun 9 10:01:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 12:01:33 +0200 Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <53955269.8060301@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> Message-ID: <539585FD.30308@redhat.com> On 06/09/2014 08:21 AM, Martin Kosek wrote: > On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: >> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: >>> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: >>>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: >>>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: >>>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: >>>>>>> I have rebased theold patch attached to the ticket, unfortunately I >>>>>>> haven't had time to test it yet, but didn't want to lose it in some >>>>>>> branch. >>>>>>> >>>>>>> Simo. >>>>>> >>>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am willing >>>>>> to ACK it. >>>>>> >>>>>> I am just wondering if there is any scenario we could have missed, but I did >>>>>> not find any. In there is no push back against the patch I may just push it. >>>> >>>>> The only thing I would draw attention to is the fact that now I am >>>>> sending back the error directly once we have a negative return from the >>>>> function in which expiration is checked (ipapwd_authenticate). >>>>> >>>>> I could not see why we did, in fact, not do that before and I meant >>>>> asking Nathaniel if he had an explicit reason why we do not, as he is >>>>> the last one that did some significant refactoring in the bind preop >>>>> plugin. >>>> >>>> In the current design, if ipapwd_authenticate() fails, we defer to 389ds >>>> for the actual response to the client. The purpose for this is so that >>>> verification of the first factor always behaves the same, regardless of >>>> what is in pre-bind. >>>> >>>> So ipapwd_authenticate() is not actually the "final" authentication. It >>>> is a preliminary authentication to determine if the user should be able >>>> to write kerberos keys and perform OTP sync. So checking expiration in >>>> pre-bind only protects these two operations. >>>> >>>> I presume that 389ds also checks password expiration. If this assumption >>>> is true, ipapwd_authenticate() SHOULD NOT return any response to the >>>> client. It should simply fail key-write/otp-sync silently and let dirsrv >>>> return the error to the client. >>> >>> 389ds would check it if we were using 389ds native password policies but >>> we are not. So we need to check on our own, which is what this patch >>> implements. >>> >>>> The important point here is that so long as 389ds is verifying password >>>> expiration, using a correct-but-expired password will should not result >>>> in a bind in the current code. It will result in kerberos key writing >>>> and OTP sync. Do we actually care about protecting kerberos key writing >>>> and OTP sync from correct-but-expired passwords? >>> >>> No, but that's not the point. >>> >>>> If 389ds does not check password expiration, then we probably need to >>>> patch upstream 389ds or, at the very least, return an error to the >>>> client. >>> >>> It is not a 389ds bug, it is just an integration issue due to the fact >>> IPA uses a different schema for password policies (for compatibility >>> with the Kerberos schema). >>> >>>> Otherwise, if we don't care about protecting kerberos key writing and >>>> OTP sync from correct-but-expired passwords, this patch is entirely >>>> unnecessary. >>>> >>>> Otherwise, the patch is necessary, but should skip kerberos key writing >>>> and OTP sync and fall through silently to 389ds. >>> >>> If we fall through to 389ds then authentication will succeed. >>> >>> So from this discussion it seem to me we achieve the goal of the patch >>> and returning an error directly is ok. >>> >>> Unless Nathaniel has something *against* returning an error in this >>> place I think we are good to go. >> >> Looks good to me. ACK. >> >> Nathaniel >> > > Ok, thanks for discussion and double checking! > > Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 Hello, This patch broke some of our tests. ipatests.test_ipaserver.test_changepw:test_changepw.test_invalid_auth ipatests.test_xmlrpc.test_user_plugin:test_denied_bind_with_expired_principal.test_1_bind_as_test_user ipatests.test_xmlrpc.test_user_plugin:test_denied_bind_with_expired_principal.test_3_bind_as_renewed_test_user fail with: INVALID_CREDENTIALS: {'info': 'The user password is expired', 'desc': 'Invalid credentials'} ipatests.test_ipaserver.test_changepw:test_changepw.test_pwpolicy_error fails with: AssertionError: 'invalid-password' != 'policy-error' ipatests.test_ipaserver.test_changepw:test_changepw.test_pwpolicy_success fails with: AssertionError: 'invalid-password' != 'ok' -- Petr? From mkosek at redhat.com Mon Jun 9 10:11:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Jun 2014 12:11:17 +0200 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <5395775D.8080609@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> Message-ID: <53958845.6010003@redhat.com> On 06/09/2014 10:59 AM, Martin Kosek wrote: > On 06/09/2014 08:21 AM, Martin Kosek wrote: >> On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: >>> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: >>>> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: >>>>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: >>>>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: >>>>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: >>>>>>>> I have rebased theold patch attached to the ticket, unfortunately I >>>>>>>> haven't had time to test it yet, but didn't want to lose it in some >>>>>>>> branch. >>>>>>>> >>>>>>>> Simo. >>>>>>> >>>>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am willing >>>>>>> to ACK it. >>>>>>> >>>>>>> I am just wondering if there is any scenario we could have missed, but I did >>>>>>> not find any. In there is no push back against the patch I may just push it. >>>>> >>>>>> The only thing I would draw attention to is the fact that now I am >>>>>> sending back the error directly once we have a negative return from the >>>>>> function in which expiration is checked (ipapwd_authenticate). >>>>>> >>>>>> I could not see why we did, in fact, not do that before and I meant >>>>>> asking Nathaniel if he had an explicit reason why we do not, as he is >>>>>> the last one that did some significant refactoring in the bind preop >>>>>> plugin. >>>>> >>>>> In the current design, if ipapwd_authenticate() fails, we defer to 389ds >>>>> for the actual response to the client. The purpose for this is so that >>>>> verification of the first factor always behaves the same, regardless of >>>>> what is in pre-bind. >>>>> >>>>> So ipapwd_authenticate() is not actually the "final" authentication. It >>>>> is a preliminary authentication to determine if the user should be able >>>>> to write kerberos keys and perform OTP sync. So checking expiration in >>>>> pre-bind only protects these two operations. >>>>> >>>>> I presume that 389ds also checks password expiration. If this assumption >>>>> is true, ipapwd_authenticate() SHOULD NOT return any response to the >>>>> client. It should simply fail key-write/otp-sync silently and let dirsrv >>>>> return the error to the client. >>>> >>>> 389ds would check it if we were using 389ds native password policies but >>>> we are not. So we need to check on our own, which is what this patch >>>> implements. >>>> >>>>> The important point here is that so long as 389ds is verifying password >>>>> expiration, using a correct-but-expired password will should not result >>>>> in a bind in the current code. It will result in kerberos key writing >>>>> and OTP sync. Do we actually care about protecting kerberos key writing >>>>> and OTP sync from correct-but-expired passwords? >>>> >>>> No, but that's not the point. >>>> >>>>> If 389ds does not check password expiration, then we probably need to >>>>> patch upstream 389ds or, at the very least, return an error to the >>>>> client. >>>> >>>> It is not a 389ds bug, it is just an integration issue due to the fact >>>> IPA uses a different schema for password policies (for compatibility >>>> with the Kerberos schema). >>>> >>>>> Otherwise, if we don't care about protecting kerberos key writing and >>>>> OTP sync from correct-but-expired passwords, this patch is entirely >>>>> unnecessary. >>>>> >>>>> Otherwise, the patch is necessary, but should skip kerberos key writing >>>>> and OTP sync and fall through silently to 389ds. >>>> >>>> If we fall through to 389ds then authentication will succeed. >>>> >>>> So from this discussion it seem to me we achieve the goal of the patch >>>> and returning an error directly is ok. >>>> >>>> Unless Nathaniel has something *against* returning an error in this >>>> place I think we are good to go. >>> >>> Looks good to me. ACK. >>> >>> Nathaniel >>> >> >> Ok, thanks for discussion and double checking! >> >> Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 >> >> Martin > > I just read a question in the ticket from alonbl about how password change > should work on the LDAP level: > > https://fedorahosted.org/freeipa/ticket/1539#comment:29 > > Are we ready to say that from now on, expired passwords cannot be changed via > LDAP? I.e. this workflow will no longer work: > > $ ipa user-add --first=Foo --last Bar expired --random > -------------------- > Added user "expired" > -------------------- > User login: expired > First name: Foo > Last name: Bar > Full name: Foo Bar > Display name: Foo Bar > Initials: FB > Home directory: /home/expired > GECOS: Foo Bar > Login shell: /bin/sh > Kerberos principal: expired at MKOSEK-FEDORA20.TEST > Email address: expired at mkosek-fedora20.test > Random password: qiCjofo.2pfT > UID: 1170600026 > GID: 1170600026 > Password: True > Member of groups: ipausers > Kerberos keys available: True > > $ ldappasswd -h `hostname` -D > uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -x -w qiCjofo.2pfT > uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -a qiCjofo.2pfT -s > Secret123 > ldap_bind: Invalid credentials (49) > additional info: The user password is expired > > Thanks, > Martin As noted in other part of this thread, this also breaks password changes via Web UI as the hooks use LDAP (and not kadmin) to update passwords. Given all sort of issues we get, I am thinking we should just revert it unless there is a quick fix available. Martin From alonbl at redhat.com Mon Jun 9 10:15:34 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 9 Jun 2014 06:15:34 -0400 (EDT) Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <53958845.6010003@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> Message-ID: <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Martin Kosek" > To: "Nathaniel McCallum" , "Simo Sorce" > Cc: "freeipa-devel" > Sent: Monday, June 9, 2014 1:11:17 PM > Subject: Re: [Freeipa-devel] Expired passwords cannot be changed via LDAP > > On 06/09/2014 10:59 AM, Martin Kosek wrote: > > On 06/09/2014 08:21 AM, Martin Kosek wrote: > >> On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: > >>> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: > >>>> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: > >>>>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: > >>>>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: > >>>>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: > >>>>>>>> I have rebased theold patch attached to the ticket, unfortunately I > >>>>>>>> haven't had time to test it yet, but didn't want to lose it in some > >>>>>>>> branch. > >>>>>>>> > >>>>>>>> Simo. > >>>>>>> > >>>>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am > >>>>>>> willing > >>>>>>> to ACK it. > >>>>>>> > >>>>>>> I am just wondering if there is any scenario we could have missed, > >>>>>>> but I did > >>>>>>> not find any. In there is no push back against the patch I may just > >>>>>>> push it. > >>>>> > >>>>>> The only thing I would draw attention to is the fact that now I am > >>>>>> sending back the error directly once we have a negative return from > >>>>>> the > >>>>>> function in which expiration is checked (ipapwd_authenticate). > >>>>>> > >>>>>> I could not see why we did, in fact, not do that before and I meant > >>>>>> asking Nathaniel if he had an explicit reason why we do not, as he is > >>>>>> the last one that did some significant refactoring in the bind preop > >>>>>> plugin. > >>>>> > >>>>> In the current design, if ipapwd_authenticate() fails, we defer to > >>>>> 389ds > >>>>> for the actual response to the client. The purpose for this is so that > >>>>> verification of the first factor always behaves the same, regardless of > >>>>> what is in pre-bind. > >>>>> > >>>>> So ipapwd_authenticate() is not actually the "final" authentication. It > >>>>> is a preliminary authentication to determine if the user should be able > >>>>> to write kerberos keys and perform OTP sync. So checking expiration in > >>>>> pre-bind only protects these two operations. > >>>>> > >>>>> I presume that 389ds also checks password expiration. If this > >>>>> assumption > >>>>> is true, ipapwd_authenticate() SHOULD NOT return any response to the > >>>>> client. It should simply fail key-write/otp-sync silently and let > >>>>> dirsrv > >>>>> return the error to the client. > >>>> > >>>> 389ds would check it if we were using 389ds native password policies but > >>>> we are not. So we need to check on our own, which is what this patch > >>>> implements. > >>>> > >>>>> The important point here is that so long as 389ds is verifying password > >>>>> expiration, using a correct-but-expired password will should not result > >>>>> in a bind in the current code. It will result in kerberos key writing > >>>>> and OTP sync. Do we actually care about protecting kerberos key writing > >>>>> and OTP sync from correct-but-expired passwords? > >>>> > >>>> No, but that's not the point. > >>>> > >>>>> If 389ds does not check password expiration, then we probably need to > >>>>> patch upstream 389ds or, at the very least, return an error to the > >>>>> client. > >>>> > >>>> It is not a 389ds bug, it is just an integration issue due to the fact > >>>> IPA uses a different schema for password policies (for compatibility > >>>> with the Kerberos schema). > >>>> > >>>>> Otherwise, if we don't care about protecting kerberos key writing and > >>>>> OTP sync from correct-but-expired passwords, this patch is entirely > >>>>> unnecessary. > >>>>> > >>>>> Otherwise, the patch is necessary, but should skip kerberos key writing > >>>>> and OTP sync and fall through silently to 389ds. > >>>> > >>>> If we fall through to 389ds then authentication will succeed. > >>>> > >>>> So from this discussion it seem to me we achieve the goal of the patch > >>>> and returning an error directly is ok. > >>>> > >>>> Unless Nathaniel has something *against* returning an error in this > >>>> place I think we are good to go. > >>> > >>> Looks good to me. ACK. > >>> > >>> Nathaniel > >>> > >> > >> Ok, thanks for discussion and double checking! > >> > >> Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 > >> > >> Martin > > > > I just read a question in the ticket from alonbl about how password change > > should work on the LDAP level: > > > > https://fedorahosted.org/freeipa/ticket/1539#comment:29 > > > > Are we ready to say that from now on, expired passwords cannot be changed > > via > > LDAP? I.e. this workflow will no longer work: > > > > $ ipa user-add --first=Foo --last Bar expired --random > > -------------------- > > Added user "expired" > > -------------------- > > User login: expired > > First name: Foo > > Last name: Bar > > Full name: Foo Bar > > Display name: Foo Bar > > Initials: FB > > Home directory: /home/expired > > GECOS: Foo Bar > > Login shell: /bin/sh > > Kerberos principal: expired at MKOSEK-FEDORA20.TEST > > Email address: expired at mkosek-fedora20.test > > Random password: qiCjofo.2pfT > > UID: 1170600026 > > GID: 1170600026 > > Password: True > > Member of groups: ipausers > > Kerberos keys available: True > > > > $ ldappasswd -h `hostname` -D > > uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -x -w > > qiCjofo.2pfT > > uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -a qiCjofo.2pfT > > -s > > Secret123 > > ldap_bind: Invalid credentials (49) > > additional info: The user password is expired > > > > Thanks, > > Martin > > As noted in other part of this thread, this also breaks password changes via > Web UI as the hooks use LDAP (and not kadmin) to update passwords. > > Given all sort of issues we get, I am thinking we should just revert it > unless > there is a quick fix available. The fix should be for the password modify to work within anonymous bind if old password is specified. I am not sure why IPA enforces non anonymous bind for this extended request. Applications should also be modified to perform anonymous bind, exactly per this reason. Searching why IPA requires non anonymous bind is what led me to this bug... :) > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pviktori at redhat.com Mon Jun 9 10:22:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 12:22:23 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments Message-ID: <53958ADF.3050306@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll make a slightly less invasive patch for 3.x. Basically, the version argument is now expected for all commands (including e.g. ping & env), and also when calling the commands in_server. If it's not given, a message is returned, so this should should only really affect tests that check the output strictly. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0571-ipalib.frontend-Do-API-version-check-before-converti.patch Type: text/x-patch Size: 7161 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 9 10:27:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Jun 2014 12:27:17 +0200 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> Message-ID: <53958C05.8060905@redhat.com> On 06/09/2014 12:15 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Martin Kosek" >> To: "Nathaniel McCallum" , "Simo Sorce" >> Cc: "freeipa-devel" >> Sent: Monday, June 9, 2014 1:11:17 PM >> Subject: Re: [Freeipa-devel] Expired passwords cannot be changed via LDAP >> >> On 06/09/2014 10:59 AM, Martin Kosek wrote: >>> On 06/09/2014 08:21 AM, Martin Kosek wrote: >>>> On 06/06/2014 05:47 PM, Nathaniel McCallum wrote: >>>>> On Fri, 2014-06-06 at 11:43 -0400, Simo Sorce wrote: >>>>>> On Fri, 2014-06-06 at 11:06 -0400, Nathaniel McCallum wrote: >>>>>>> On Fri, 2014-06-06 at 08:00 -0400, Simo Sorce wrote: >>>>>>>> On Fri, 2014-06-06 at 10:30 +0200, Martin Kosek wrote: >>>>>>>>> On 05/31/2014 03:27 AM, Simo Sorce wrote: >>>>>>>>>> I have rebased theold patch attached to the ticket, unfortunately I >>>>>>>>>> haven't had time to test it yet, but didn't want to lose it in some >>>>>>>>>> branch. >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>> >>>>>>>>> I tested the patch and it worked fine, code also reads OK. Thus, I am >>>>>>>>> willing >>>>>>>>> to ACK it. >>>>>>>>> >>>>>>>>> I am just wondering if there is any scenario we could have missed, >>>>>>>>> but I did >>>>>>>>> not find any. In there is no push back against the patch I may just >>>>>>>>> push it. >>>>>>> >>>>>>>> The only thing I would draw attention to is the fact that now I am >>>>>>>> sending back the error directly once we have a negative return from >>>>>>>> the >>>>>>>> function in which expiration is checked (ipapwd_authenticate). >>>>>>>> >>>>>>>> I could not see why we did, in fact, not do that before and I meant >>>>>>>> asking Nathaniel if he had an explicit reason why we do not, as he is >>>>>>>> the last one that did some significant refactoring in the bind preop >>>>>>>> plugin. >>>>>>> >>>>>>> In the current design, if ipapwd_authenticate() fails, we defer to >>>>>>> 389ds >>>>>>> for the actual response to the client. The purpose for this is so that >>>>>>> verification of the first factor always behaves the same, regardless of >>>>>>> what is in pre-bind. >>>>>>> >>>>>>> So ipapwd_authenticate() is not actually the "final" authentication. It >>>>>>> is a preliminary authentication to determine if the user should be able >>>>>>> to write kerberos keys and perform OTP sync. So checking expiration in >>>>>>> pre-bind only protects these two operations. >>>>>>> >>>>>>> I presume that 389ds also checks password expiration. If this >>>>>>> assumption >>>>>>> is true, ipapwd_authenticate() SHOULD NOT return any response to the >>>>>>> client. It should simply fail key-write/otp-sync silently and let >>>>>>> dirsrv >>>>>>> return the error to the client. >>>>>> >>>>>> 389ds would check it if we were using 389ds native password policies but >>>>>> we are not. So we need to check on our own, which is what this patch >>>>>> implements. >>>>>> >>>>>>> The important point here is that so long as 389ds is verifying password >>>>>>> expiration, using a correct-but-expired password will should not result >>>>>>> in a bind in the current code. It will result in kerberos key writing >>>>>>> and OTP sync. Do we actually care about protecting kerberos key writing >>>>>>> and OTP sync from correct-but-expired passwords? >>>>>> >>>>>> No, but that's not the point. >>>>>> >>>>>>> If 389ds does not check password expiration, then we probably need to >>>>>>> patch upstream 389ds or, at the very least, return an error to the >>>>>>> client. >>>>>> >>>>>> It is not a 389ds bug, it is just an integration issue due to the fact >>>>>> IPA uses a different schema for password policies (for compatibility >>>>>> with the Kerberos schema). >>>>>> >>>>>>> Otherwise, if we don't care about protecting kerberos key writing and >>>>>>> OTP sync from correct-but-expired passwords, this patch is entirely >>>>>>> unnecessary. >>>>>>> >>>>>>> Otherwise, the patch is necessary, but should skip kerberos key writing >>>>>>> and OTP sync and fall through silently to 389ds. >>>>>> >>>>>> If we fall through to 389ds then authentication will succeed. >>>>>> >>>>>> So from this discussion it seem to me we achieve the goal of the patch >>>>>> and returning an error directly is ok. >>>>>> >>>>>> Unless Nathaniel has something *against* returning an error in this >>>>>> place I think we are good to go. >>>>> >>>>> Looks good to me. ACK. >>>>> >>>>> Nathaniel >>>>> >>>> >>>> Ok, thanks for discussion and double checking! >>>> >>>> Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 >>>> >>>> Martin >>> >>> I just read a question in the ticket from alonbl about how password change >>> should work on the LDAP level: >>> >>> https://fedorahosted.org/freeipa/ticket/1539#comment:29 >>> >>> Are we ready to say that from now on, expired passwords cannot be changed >>> via >>> LDAP? I.e. this workflow will no longer work: >>> >>> $ ipa user-add --first=Foo --last Bar expired --random >>> -------------------- >>> Added user "expired" >>> -------------------- >>> User login: expired >>> First name: Foo >>> Last name: Bar >>> Full name: Foo Bar >>> Display name: Foo Bar >>> Initials: FB >>> Home directory: /home/expired >>> GECOS: Foo Bar >>> Login shell: /bin/sh >>> Kerberos principal: expired at MKOSEK-FEDORA20.TEST >>> Email address: expired at mkosek-fedora20.test >>> Random password: qiCjofo.2pfT >>> UID: 1170600026 >>> GID: 1170600026 >>> Password: True >>> Member of groups: ipausers >>> Kerberos keys available: True >>> >>> $ ldappasswd -h `hostname` -D >>> uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -x -w >>> qiCjofo.2pfT >>> uid=expired,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test -a qiCjofo.2pfT >>> -s >>> Secret123 >>> ldap_bind: Invalid credentials (49) >>> additional info: The user password is expired >>> >>> Thanks, >>> Martin >> >> As noted in other part of this thread, this also breaks password changes via >> Web UI as the hooks use LDAP (and not kadmin) to update passwords. >> >> Given all sort of issues we get, I am thinking we should just revert it >> unless >> there is a quick fix available. > > The fix should be for the password modify to work within anonymous bind if old password is specified. I am not sure why IPA enforces non anonymous bind for this extended request. > > Applications should also be modified to perform anonymous bind, exactly per this reason. > > Searching why IPA requires non anonymous bind is what led me to this bug... :) Simo, do you know the historical reason why this is enforced in ipapwd_chpwop? By quickly looking at the code it should not be difficult to fix, but devil is in details and we need to be very cautious in this function. Martin From pviktori at redhat.com Mon Jun 9 11:21:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 13:21:34 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments In-Reply-To: <53958ADF.3050306@redhat.com> References: <53958ADF.3050306@redhat.com> Message-ID: <539598BE.5030607@redhat.com> On 06/09/2014 12:22 PM, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll > make a slightly less invasive patch for 3.x. > > Basically, the version argument is now expected for all commands > (including e.g. ping & env), and also when calling the commands in_server. > If it's not given, a message is returned, so this should should only > really affect tests that check the output strictly. > For the 3.x maintenance branches, here's a much smaller fix. This only checks the version if it was given. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-3-3-pviktori-0571-ipalib.frontend-Do-API-version-check-before-converti.patch Type: text/x-patch Size: 1136 bytes Desc: not available URL: From pviktori at redhat.com Mon Jun 9 12:20:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 14:20:27 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed In-Reply-To: <53918C14.2080204@redhat.com> References: <538F4CA1.4070501@redhat.com> <53918C14.2080204@redhat.com> Message-ID: <5395A68B.9090502@redhat.com> On 06/06/2014 11:38 AM, Martin Kosek wrote: > On 06/04/2014 06:43 PM, Petr Viktorin wrote: >> Hello, >> I try to think about any kind of data the user might have in LDAP, but in the >> spirit of YAGNI, I'll deal with the various corner cases in IPA's historic >> default permissions as I go along. >> >> Patch 0568 adds support for the case where the default permissions changed in >> something else than attribute lists. Needed for the 'Change User password' >> permission. >> >> Patch 0569 converts user permissions to managed. >> >> Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697 > > > 1) Add aci has targetfilter part - is that intentional? Yes. From the permission plugin''s point of view, it's part of the definition of --type user (i.e. "this applies to users"). Regardless I think it should be there. > # ipa permission-show 'System: Add Users' --all --raw > ... > aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl > "permission:System: Add Users";allow (add) groupdn = "ldap:///cn=System: Add > Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test";) > > This part IS effective though, so it may not be a bad thing at all, to keep it > in the ACI: > > # ldapadd -Y GSSAPI > SASL/GSSAPI authentication started > SASL username: fbar at MKOSEK-FEDORA20.TEST > SASL SSF: 56 > SASL data security layer installed. > dn: cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test > objectclass: top > objectclass: nscontainer > cn: foo > > adding new entry "cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test" > ldap_add: Insufficient access (50) > additional info: Insufficient 'add' privilege to add the entry > 'cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test'. > > # ipa user-add --first=Foo --last Bar fbar2 > ------------------ > Added user "fbar2" > ------------------ > User login: fbar2 > First name: Foo > ... > > 2) System: Add User to default group > > I was wondering whether we should keep the AluCI in cn=groups container or > directly with the group, but I think the group itself is a good idea. (Unless > someone deletes and recreates it). Hm, this is a good point. If the ipausers group is deleted, there'll be an permission with a missing ACI that can't be created. That could be quite annoying. I put the ACI it in the container. > 3) System: Change User password > > I hit some nasty DS error which prevented authorized user to update password. > ACI log attached. Ludwig, does that ring any bell? > > The ACI itself looks OK though as after I restarted DS, it started to work. > Maybe DS did not cache the ACIs properly after upgrade? Which DS version are you using? > 4) When running user unit tests, I found couple issues: > > a) Some attributes we may still miss in the permissions: > - krbPrincipalExpiration > - userclass > - ipaUserAuthType > - preferredLanguage > > I am thinking we could base Modify Users permission on the read one and add > regular attributes there I put in userclass and preferredLanguage. I'm not sure about the other two; should regular user admins be able to change these? > b) Read membership ACIs for users and groups miss "member" attribute and thus > indirect/direct processing goes wrong. Added. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0568.3-managed-perm-updater-Handle-case-where-we-changed-de.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0569.3-Convert-User-default-permissions-to-managed.patch Type: text/x-patch Size: 14960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0570.3-Add-missing-attributes-to-User-managed-permissions.patch Type: text/x-patch Size: 2758 bytes Desc: not available URL: From simo at redhat.com Mon Jun 9 12:51:17 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 9 Jun 2014 08:51:17 -0400 (EDT) Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <53958C05.8060905@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> Message-ID: <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> > On 06/09/2014 12:15 PM, Alon Bar-Lev wrote: > >> From: "Martin Kosek" > >> Given all sort of issues we get, I am thinking we should just revert it > >> unless > >> there is a quick fix available. > > The fix should be for the password modify to work within anonymous bind if > > old password is specified. I am not sure why IPA enforces non anonymous > > bind for this extended request. > > > > Applications should also be modified to perform anonymous bind, exactly per > > this reason. > > > > Searching why IPA requires non anonymous bind is what led me to this bug... > > :) > > Simo, do you know the historical reason why this is enforced in > ipapwd_chpwop? When we started we wanted to allow password changes using GSSAPI for bind instead of password based authentication, and we ended up not implementing the "old-password" based one at all... > By quickly looking at the code it should not be difficult to fix, but devil > is in details and we need to be very cautious in this function. We just need to be careful about what operations are done, but indeed it shouldn't be difficult, I am just not sure it is quick enough for you. I can take a look in a few. Simo. From simo at redhat.com Mon Jun 9 12:54:28 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 9 Jun 2014 08:54:28 -0400 (EDT) Subject: [Freeipa-devel] Patch for #1539 In-Reply-To: <539585FD.30308@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <53917C2A.9060702@redhat.com> <1402056010.9430.2.camel@willson.usersys.redhat.com> <1402067191.4323.31.camel@ipa.example.com> <1402069427.9430.16.camel@willson.usersys.redhat.com> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <539585FD.30308@redhat.com> Message-ID: <1325602188.20108285.1402318468274.JavaMail.zimbra@redhat.com> > > Pushed to master: bfdbd3b6ad7c437e7dd293d2488b2d53f4ea7ba6 > > Hello, > This patch broke some of our tests. > > ipatests.test_ipaserver.test_changepw:test_changepw.test_invalid_auth > ipatests.test_xmlrpc.test_user_plugin:test_denied_bind_with_expired_principal.test_1_bind_as_test_user > ipatests.test_xmlrpc.test_user_plugin:test_denied_bind_with_expired_principal.test_3_bind_as_renewed_test_user > > fail with: INVALID_CREDENTIALS: {'info': 'The user password is expired', > 'desc': 'Invalid credentials'} > > > ipatests.test_ipaserver.test_changepw:test_changepw.test_pwpolicy_error > > fails with: AssertionError: 'invalid-password' != 'policy-error' > > > ipatests.test_ipaserver.test_changepw:test_changepw.test_pwpolicy_success > > fails with: AssertionError: 'invalid-password' != 'ok' I guess we need to fix some of these tests, but first we need to fix password change with expired credentials to work when the old password is provided. This will not work with non-password based mechanisms though ... Simo. From simo at redhat.com Mon Jun 9 13:01:27 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 9 Jun 2014 09:01:27 -0400 (EDT) Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> Message-ID: <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> > > >> From: "Martin Kosek" > > > >> Given all sort of issues we get, I am thinking we should just revert it > > >> unless > > >> there is a quick fix available. Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. Thoughts? Simo. From dpal at redhat.com Mon Jun 9 13:08:50 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Jun 2014 09:08:50 -0400 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> Message-ID: <5395B1E2.9050104@redhat.com> On 06/09/2014 09:01 AM, Simo Sorce wrote: >>>>> From: "Martin Kosek" >>>>> Given all sort of issues we get, I am thinking we should just revert it >>>>> unless >>>>> there is a quick fix available. > Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. > > Thoughts? > > Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I am also concerned about the OTP flows with this change. IMO we might not be ready for this change one way or another. Backing out or adding a default switch turning the feature off works for me. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Mon Jun 9 13:40:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Jun 2014 15:40:07 +0200 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <5395B1E2.9050104@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> <5395B1E2.9050104@redhat.com> Message-ID: <5395B937.3030908@redhat.com> On 06/09/2014 03:08 PM, Dmitri Pal wrote: > On 06/09/2014 09:01 AM, Simo Sorce wrote: >>>>>> From: "Martin Kosek" >>>>>> Given all sort of issues we get, I am thinking we should just revert it >>>>>> unless >>>>>> there is a quick fix available. >> Instead of reverting I am thinking we may want to make this optional by >> adding a configuration parameter that defaults to False for now. Once we can >> manage better the password change we can turn it on by deault, in the >> meanwhile admins can choose by themselves the lesser evil. >> >> Thoughts? >> >> Simo. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I am also concerned about the OTP flows with this change. > IMO we might not be ready for this change one way or another. > Backing out or adding a default switch turning the feature off works for me. I do not like the proposal very much. It sounds like "oops, this breaks FreeIPA, let's hide it with configuration option and fix later". This would not be a simple fix, we know that Web UI and possibly other workflows are broken unless we introduce password changes via anonymous binds (and thus utilize oldPassword piece). We would also need to make sure the setting is not read with every LDAP bind, otherwise it would also have some performance impact, our BINDs are already slow (see https://fedorahosted.org/freeipa/ticket/3892). If this can be indeed fixed, let us do it before 4.0 Beta (we are talking about 2 weeks of time in ideal scenario) or revert until we are ready. Martin From pvoborni at redhat.com Mon Jun 9 13:46:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 09 Jun 2014 15:46:22 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <53920A09.5030001@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> <5391C5FD.5060908@redhat.com> <5391E19A.5080806@redhat.com> <53920A09.5030001@redhat.com> Message-ID: <5395BAAE.6080507@redhat.com> On 6.6.2014 20:35, Endi Sukma Dewata wrote: > On 6/6/2014 10:43 AM, Petr Vobornik wrote: >> On 6.6.2014 15:45, Endi Sukma Dewata wrote: >>> On 6/5/2014 9:25 AM, Endi Sukma Dewata wrote: >>>> ACK for patches #592-#628. I'll continue reviewing the rest. >>> >>> ACK for patches #633-639, #642, #644, #652, and #653. Patches #640 & >>> #641 have an issue (see #19 below) that should be fixed before pushing. >>> Other issues are minor/unrelated/suggestions that can be addressed >>> separately. >> >> Thank you for the review. >> >> I've fixed issues: >> >> - #19, #20 in patch #640. >> >> And some low hanging fruit: >> - #16, in patch #637 >> - #17, in patch #612 >> - #13, in patch #612 >> >> The branch has been rebased to current master. > > ACK. I've fixed issues #4, #2, #20 and #18. Commits in the branch, no rebase. With these 4 changes we are ready for the push. I'll squash them, if necessary. > >> I am not able to reproduce issues #4 and #11. > >>> 4. In the list page (e.g. Users) in mobile mode the Refresh button >>> may overlap the search box. > > Here's what I saw as I was adjusting the page width: > http://edewata.fedorapeople.org/ipa/images/snapshot1.png > http://edewata.fedorapeople.org/ipa/images/snapshot2.png > http://edewata.fedorapeople.org/ipa/images/snapshot3.png > > Notice that in snapshot #2 the search box is partially covered by the > Refresh button. > >>> 11. In desktop mode the QR code for new OTP token is displayed >>> outside the dialog box. > > Here's what I saw: > http://edewata.fedorapeople.org/ipa/images/snapshot4.png Fixed, both were Firefox-only issues. > >>> 18. In the New Certificate dialog for Host, the instruction to create a >>> CSR exceeds the dialog boundary. >> >> caused by BS' CSS: >> code { >> white-space: nowrap; >> } >> >> I wonder if the best solution is to reset it to initial value in all >> dialogs. > > Alternatively, the sample command could be broken into two lines. IMHO the style is better, because it's more general and easier for copy&paste. I've also added word-wrap to break very long subjects. > >>> 20. The capitalization of "Certificate" is inconsistent in Host's and >>> Service's Actions. >> >> Fixed > > The "View certificate" is still inconsistent though. > Shame on me :) -- Petr Vobornik From mbasti at redhat.com Mon Jun 9 13:59:56 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 09 Jun 2014 15:59:56 +0200 Subject: [Freeipa-devel] [PATCH 0064] python-kerberos update in freeipa.spec.in Message-ID: <1402322396.2279.8.camel@unused-4-145.brq.redhat.com> Patch attached. View the patch for more details. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0064-Python-kerberos-update-in-freeipa.spec.in.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: From npmccallum at redhat.com Mon Jun 9 14:03:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 09 Jun 2014 10:03:11 -0400 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> Message-ID: <1402322591.2883.4.camel@ipa.example.com> On Mon, 2014-06-09 at 09:01 -0400, Simo Sorce wrote: > > > >> From: "Martin Kosek" > > > > > >> Given all sort of issues we get, I am thinking we should just revert it > > > >> unless > > > >> there is a quick fix available. > > Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. > > Thoughts? I'm not a fan of introducing a new configuration parameter for a temporary workaround. My preference is to revert it and have a small project for the next release which handles all the "non-authenticated" corner cases. This would include: * Expired passwords * Password changes * Token syncing * Unauthenticated RPCs (rpcserver.py rework) * others? I think there is some value to be gained by thinking about these problems as a whole and devising a set of consistent mechanisms for them. Nathaniel From npmccallum at redhat.com Mon Jun 9 14:08:30 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 09 Jun 2014 10:08:30 -0400 Subject: [Freeipa-devel] [PATCH 0064] python-kerberos update in freeipa.spec.in In-Reply-To: <1402322396.2279.8.camel@unused-4-145.brq.redhat.com> References: <1402322396.2279.8.camel@unused-4-145.brq.redhat.com> Message-ID: <1402322910.2883.5.camel@ipa.example.com> On Mon, 2014-06-09 at 15:59 +0200, Martin Basti wrote: > Patch attached. > View the patch for more details. ACK From pvoborni at redhat.com Mon Jun 9 14:08:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 09 Jun 2014 16:08:50 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <5390DDE1.1010502@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> <1401912616.597.7.camel@willson.usersys.redhat.com> <5390DDE1.1010502@redhat.com> Message-ID: <5395BFF2.1050109@redhat.com> On 5.6.2014 23:15, Dmitri Pal wrote: > On 06/04/2014 04:10 PM, Simo Sorce wrote: >> On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote: >>> On 06/04/2014 05:35 PM, Simo Sorce wrote: >>>> On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: >>>>> On 06/04/2014 08:34 AM, Martin Kosek wrote: >>>>> ... >>>>>> Users >>>>>> - Users >>>>>> - Groups >>>>>> - SUDO >>>>>> >>>>>> Hosts >>>>>> - Hosts >>>>>> - Host groups >>>>>> - Services >>>>>> - Netgroups >>>>>> - Automount >>>>>> >>>>>> Authentication >>>>>> - OTP Tokens >>>>>> - Password Policy >>>>>> - Kerberos Ticket Policy >>>>>> >>>>>> Policy >>>>>> - HBAC >>>>>> - SELinux User Maps >>>>>> - Automember >>>>> Alternatively, we could rename Policy to "Authorization" as both >>>>> HBAC and >>>>> SELinux is about authorizing what an authenticated user can do. We >>>>> would just >>>>> need to move Automember to different place, though this one is >>>>> difficult - it >>>>> relates both to Users and Hosts, just like Netgroup. >>>> I do not see the need to do Policy -> Authorization but Automember >>>> is in >>>> the wrong place imo. >>>> >>>> The first tab should be Users -> Accounts and include automember in it >>>> as automember is about groupings ? >>>> >>>> Actually I would merge the current Users and Hosts tabs into >>>> 'Accounts' (or maybe 'Identities' ?) and add Automember. >>>> >>>> Simo. >>>> >>> Automember is about grouping both users and hosts. I put it under Policy >>> originally as it basically is a policy, when are certain users/hosts >>> automember'ed. >>> >>> I would personally not merge Users and Hosts top level menus to one >>> top level >>> menu as that would spoil the whole reason why this effort is done, >>> i.e. have at >>> most 7 items in the second level bar to make things clearer. >>> >>> To me, it seemed a good idea to split Users and Hosts to achieve the >>> target as >>> it separates well the intent what one wants to do. Now we have it all >>> under >>> Identity (including DNS and Realm Domains) which is messy. >> Unfortunately some of your groupings make little sense to me: >> - why is SUDO under Users ?? >> It's a security policy and those policies are equally related to users, >> groups and hosts. >> - why "policies" are under authentication ? >> Both password policies and Kerberos Ticket policies have nothing to do >> with the authentication part, but with changing password and with which >> features are allowed on tickets. >> - why automember is in Policy ? >> It is just autoconfiguration it doesn't enforce any policy on its own >> >>> But I am pretty open to counter-proposals which keeps the UX >>> requirement of 7 >>> second level items. >>> >>> Martin >> This is how it makes sense to me as a logical grouping: >> >> Accounts/Identity (7): >> - Users >> - Groups >> - Hosts >> - Host Groups >> - Netgroups >> - Services >> - Automember >> >> ^ These are all identity or identity-grouping related objects/actions > > +1 What are the chances that we will add some other identity to manage in a future? > >> >> Policies (6): >> - Sudo >> - HBAC >> - SELinux User Maps >> - OTP Tokens (*) >> - Password Policies >> - Kerberos ticket Policies >> >> ^ These are all Security Policies an admin cares about > > +1, with the note, i.e. OTP does not belong there > >> >> Directory (6): >> - Permissions >> - Privileges >> - Roles >> - Delegation >> NOTE: the 4 above can be merged into a single 'Authorization' entry >> perhaps > > May be it should be and "Administration" tab, I do not like the title. I > understand where the directory comes from but this is IMo not intuitive > for someone who does not know what is under the hood. >> - Replication Topology +1 that they should be together. They configure the "tool" and not "data". Current "IPA Server" item name may be more suitable. >> - Views (future) >> >> ^ Everything that deals with direct LDAP access/view > > > I think views do not belong here. They belong in the same place where > the trusts are. > >> >> Network Services (4): >> - Automount >> - DNS >> - CA >> - Vault (future) - Radius Server Proxies >> >> ^ All the additional network services or configuration of network >> related services > > +1 > >> >> Configuration (3): >> - Trusts >> - ID Ranges >> - Realm Domains >> - Global - OTP Tokens ? >> >> ^ Anything that does not fit the above categories. > > +1 > >> >> Docs: >> - whatever :) >> >> >> (*) The only doubt I have is about OTP Tokens, it may be worth taking >> them off Policies and putting them into a new tab which in future may >> also sport a pointer to user certificates management: > > Yeah, may be for now we put OTP as a top level for now and have tokens > and create a RADIUS page to manage radius proxies? We already have "RADIUS Servers" menu item for Radius s. proxies. Martin forgot it in his proposal. > In future when we add other credentials we can rename it and add smart > card related options. > >> >> Authentication: >> - OTP Tokens >> - User Certificates (future) With "Documentation", "Authentication" would be the 7th top level item. Ideal number of top level items is about 5-6. Because we have to fit into 768px (minimum screen size before it's switched to compact menu). This functionality is provided by PatternFly. Also take into considerations that languages such as Spanish have much longer expressions. -- Petr Vobornik From pviktori at redhat.com Mon Jun 9 14:31:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 16:31:18 +0200 Subject: [Freeipa-devel] [PATCHES 21-22] ipautil log messages and API version to env In-Reply-To: References: <5391AA3D.1070401@redhat.com> Message-ID: <5395C536.6070202@redhat.com> On 06/06/2014 05:02 PM, Gabe Alford wrote: > Patch 21: > Update per recommendation > > Patch 22: > Added version option as well as updated the manpage. > > Thanks, > > Gabe > > Great! Thanks, ACK, pushed to master: 2a8c509567754877ed0188784d7c38250484be48 In the future, you can put typo fixes in a separate patch, so it's easier to backport/revert individual changes. -- Petr? From simo at redhat.com Mon Jun 9 14:42:50 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Jun 2014 10:42:50 -0400 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <5395BFF2.1050109@redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> <1401912616.597.7.camel@willson.usersys.redhat.com> <5390DDE1.1010502@redhat.com> <5395BFF2.1050109@redhat.com> Message-ID: <1402324970.9430.45.camel@willson.usersys.redhat.com> On Mon, 2014-06-09 at 16:08 +0200, Petr Vobornik wrote: > >> Accounts/Identity (7): > >> - Users > >> - Groups > >> - Hosts > >> - Host Groups > >> - Netgroups > >> - Services > >> - Automember > >> > >> ^ These are all identity or identity-grouping related > objects/actions > > > > +1 > > What are the chances that we will add some other identity to manage in > a future? I am not foreseeing anything in the core, but we can move Automember under configuration is we want to. > >> Directory (6): > >> - Permissions > >> - Privileges > >> - Roles > >> - Delegation > >> NOTE: the 4 above can be merged into a single 'Authorization' entry > >> perhaps > > > > May be it should be and "Administration" tab, I do not like the > > title. I understand where the directory comes from but this is IMo > > not intuitive for someone who does not know what is under the hood. > >> - Replication Topology > > > +1 that they should be together. They configure the "tool" and not > "data". Current "IPA Server" item name may be more suitable. Well this is not related to just the one server, but the whole set of servers. Maybe the plural "IPA Servers" ? > >> - Views (future) > >> > >> ^ Everything that deals with direct LDAP access/view > > > > > > I think views do not belong here. They belong in the same place > > where the trusts are. Just a FYI: I do not think views and trust should be in the same place. Views will also be available for regular IPA server with no trusts, the 2 are not strictly related. Views IMO really belong here with other directory configuration items. > > > >> > >> Network Services (4): > >> - Automount > >> - DNS > >> - CA > >> - Vault (future) > - Radius Server Proxies Isn't this strictly related to OTP ? I would put it in the same place. > >> > >> ^ All the additional network services or configuration of network > >> related services > > > > +1 > > > >> > >> Configuration (3): > >> - Trusts > >> - ID Ranges > >> - Realm Domains > >> - Global > - OTP Tokens ? > >> > >> ^ Anything that does not fit the above categories. > > > > +1 > > > >> > >> Docs: > >> - whatever :) > >> > >> > >> (*) The only doubt I have is about OTP Tokens, it may be worth > >> taking them off Policies and putting them into a new tab which in > >> future may also sport a pointer to user certificates management: > > > > Yeah, may be for now we put OTP as a top level for now and have > > tokens and create a RADIUS page to manage radius proxies? > > > We already have "RADIUS Servers" menu item for Radius s. proxies. > Martin forgot it in his proposal. > > > In future when we add other credentials we can rename it and add > > smart card related options. > > > >> > >> Authentication: > >> - OTP Tokens > >> - User Certificates (future) > > > With "Documentation", "Authentication" would be the 7th top level > item. > Ideal number of top level items is about 5-6. Because we have to fit > into 768px (minimum screen size before it's switched to compact menu). Why the minimum is 768 ? Maybe we can drop Documentation from the top level ? Or make it really small by using a "?" as the menu symbol ? :) Maybe we should stop using full names but instead get a set of icons that represent each item and have the name only as a tooltip ? This way the first level menu bar sizing would be consistent regardless of the language. > This functionality is provided by PatternFly. > > Also take into considerations that languages such as Spanish have much > longer expressions. Yeah maybe we should just avoid names here and use icons+tooltips/hover instead. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Mon Jun 9 15:28:33 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 09 Jun 2014 17:28:33 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0064 Update DNSSEC attributes/record types Message-ID: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4328 Petr please make the WebUI patch review (0062) :-) Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0059-DNSSEC-remove-unsuported-records.patch Type: text/x-patch Size: 22390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0060-DNSSEC-added-NSEC3PARAM-record-type.patch Type: text/x-patch Size: 31764 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0061-DNSSEC-webui-update-DNSSEC-attributes.patch Type: text/x-patch Size: 6106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0062-Tests-remove-unused-records-from-tests.patch Type: text/x-patch Size: 4691 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0063-Tests-tests-for-NSEC3PARAM-records.patch Type: text/x-patch Size: 3167 bytes Desc: not available URL: From dpal at redhat.com Mon Jun 9 15:54:55 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Jun 2014 11:54:55 -0400 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <1402322591.2883.4.camel@ipa.example.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> <1402322591.2883.4.camel@ipa.example.com> Message-ID: <5395D8CF.1070608@redhat.com> On 06/09/2014 10:03 AM, Nathaniel McCallum wrote: > On Mon, 2014-06-09 at 09:01 -0400, Simo Sorce wrote: >>>>>> From: "Martin Kosek" >>>>>> Given all sort of issues we get, I am thinking we should just revert it >>>>>> unless >>>>>> there is a quick fix available. >> Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. >> >> Thoughts? > I'm not a fan of introducing a new configuration parameter for a > temporary workaround. > > My preference is to revert it and have a small project for the next > release which handles all the "non-authenticated" corner cases. This > would include: > * Expired passwords > * Password changes > * Token syncing > * Unauthenticated RPCs (rpcserver.py rework) > * others? > > I think there is some value to be gained by thinking about these > problems as a whole and devising a set of consistent mechanisms for > them. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel +1 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pvoborni at redhat.com Mon Jun 9 16:31:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 09 Jun 2014 18:31:54 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <1402324970.9430.45.camel@willson.usersys.redhat.com> References: <538C8338.1040502@redhat.com> <538D7F1E.2010802@redhat.com> <538D8751.9030302@redhat.com> <538E3B38.7010709@redhat.com> <538EBE0F.3060302@redhat.com> <538EC03F.3060103@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> <1401912616.597.7.camel@willson.usersys.redhat.com> <5390DDE1.1010502@redhat.com> <5395BFF2.1050109@redhat.com> <1402324970.9430.45.camel@willson.usersys.redhat.com> Message-ID: <5395E17A.2050507@redhat.com> On 9.6.2014 16:42, Simo Sorce wrote: > On Mon, 2014-06-09 at 16:08 +0200, Petr Vobornik wrote: >>>> Accounts/Identity (7): >>>> - Users >>>> - Groups >>>> - Hosts >>>> - Host Groups >>>> - Netgroups >>>> - Services >>>> - Automember >>>> >>>> ^ These are all identity or identity-grouping related >> objects/actions >>> >>> +1 >> >> What are the chances that we will add some other identity to manage in >> a future? > > I am not foreseeing anything in the core, but we can move Automember > under configuration is we want to. > >>>> Directory (6): >>>> - Permissions >>>> - Privileges >>>> - Roles >>>> - Delegation >>>> NOTE: the 4 above can be merged into a single 'Authorization' entry >>>> perhaps >>> >>> May be it should be and "Administration" tab, I do not like the >>> title. I understand where the directory comes from but this is IMo >>> not intuitive for someone who does not know what is under the hood. >>>> - Replication Topology >> >> >> +1 that they should be together. They configure the "tool" and not >> "data". Current "IPA Server" item name may be more suitable. > > Well this is not related to just the one server, but the whole set of > servers. Maybe the plural "IPA Servers" ? > >>>> - Views (future) >>>> >>>> ^ Everything that deals with direct LDAP access/view >>> >>> >>> I think views do not belong here. They belong in the same place >>> where the trusts are. > > Just a FYI: I do not think views and trust should be in the same place. > Views will also be available for regular IPA server with no trusts, the > 2 are not strictly related. Views IMO really belong here with other > directory configuration items. > >>> >>>> >>>> Network Services (4): >>>> - Automount >>>> - DNS >>>> - CA >>>> - Vault (future) >> - Radius Server Proxies > > Isn't this strictly related to OTP ? I would put it in the same place. > >>>> >>>> ^ All the additional network services or configuration of network >>>> related services >>> >>> +1 >>> >>>> >>>> Configuration (3): >>>> - Trusts >>>> - ID Ranges >>>> - Realm Domains >>>> - Global >> - OTP Tokens ? >>>> >>>> ^ Anything that does not fit the above categories. >>> >>> +1 >>> >>>> >>>> Docs: >>>> - whatever :) >>>> >>>> >>>> (*) The only doubt I have is about OTP Tokens, it may be worth >>>> taking them off Policies and putting them into a new tab which in >>>> future may also sport a pointer to user certificates management: >>> >>> Yeah, may be for now we put OTP as a top level for now and have >>> tokens and create a RADIUS page to manage radius proxies? >> >> >> We already have "RADIUS Servers" menu item for Radius s. proxies. >> Martin forgot it in his proposal. >> >>> In future when we add other credentials we can rename it and add >>> smart card related options. >>> >>>> >>>> Authentication: >>>> - OTP Tokens >>>> - User Certificates (future) >> >> >> With "Documentation", "Authentication" would be the 7th top level >> item. >> Ideal number of top level items is about 5-6. Because we have to fit >> into 768px (minimum screen size before it's switched to compact menu). > > Why the minimum is 768 ? It's Bootstrap's minimum width of a small device(tablet). Navbar's collapse threshold (@grid-float-breakpoint) is set to this value by default. It's possible to increase it but I don't think it's the best approach - collapsed menu is harder to use. It can be solved in different manner but it requires additional work. > > Maybe we can drop Documentation from the top level ? Or make it really > small by using a "?" as the menu symbol ? :) I like this. > > Maybe we should stop using full names but instead get a set of icons > that represent each item and have the name only as a tooltip ? > > This way the first level menu bar sizing would be consistent regardless > of the language. It would solve the issue, but we should be consistent with other projects as well. Also, it would require very good icons. I'm afraid that it would be harder to use for newcomers. But probably better for experienced users. Kyle what's your take? > >> This functionality is provided by PatternFly. >> >> Also take into considerations that languages such as Spanish have much >> longer expressions. > > Yeah maybe we should just avoid names here and use icons+tooltips/hover > instead. > -- Petr Vobornik From rcritten at redhat.com Mon Jun 9 17:39:44 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Jun 2014 13:39:44 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1379705747.30999.25.camel@willson.li.ssimo.org> References: <1379705747.30999.25.camel@willson.li.ssimo.org> Message-ID: <5395F160.9050701@redhat.com> Simo Sorce wrote: > This patch set is an initial implementation of ticket #3859 > > It seem to be working fine in my initial testing but I have not yet > tested all cases. > > However I wonted to throw it on the list to get some initial feedback > about the choices I made wrt access control and ipa-getkeytab flags and > default behavior. > > In particular, the current patch set would require us to make > host/service keytabs readable by the requesting party (whoever that is, > admin or host itself) in order to allow it to get back the actual > keytab. I am not sure this is ideal. Also write access to the keytab is > still all is needed to allow someone to change it. > > Neither is ideal, but it was simpler as a first implementation. In > particular I think we should allow either permission indipendently, and > it should be something an admin can change. However I do not like > allowing normal writes or reads to these attributes, mostly because w/o > access to the master key nobody can really make sense of actually > reading out the contents of KrbPrincipalKey or could write a blob that > can be successfully decrypted. > > So I was wondering if we might want to prevent both reading and writing > via LDAP (except via extended operations) and instead use another method > to determine access patterns. > > As for ipa-getkeytab is everyone ok with tryin the new method first and > always falling back to the old one (if a password has been provided) ? 0001 Needs a rebase. I did my best for testing. In check_service_name() why not just initialize name to NULL rather than assigning it twice? Or is the value of name undefined if krb5_* fails? get_realm_backend() should probably have a comment on why returning NULL is ok (either because there is no sdn or because there is no be). It appears that things will eventually fail in get_entry_by_principal() I think the Access Strategy comment needs to be expanded (or dropped) in is_allowed_to_access_keys() In the fatal error in is_allowed_to_access_keys() should the error include the bound user and the resource they attempted to modify? 0002 ACK 0003 Nit: typo in commit, extedned I'd prefer unique error messages for each ber decode failure. Why is write access always required in ipapwd_getkeytab()? Would there be a case where a principal can only re-fetch existing keys? Since getnew is defined as a boolean in the ASN.1, is the conditional if (getnew == 0) preferred over just if (getnew)? Some errors read "Out of Memory" and others "allocation failed". I think with a fatal error the line number is included in the error. If I'm wrong then perhaps something specific to the allocation should be included. The error message to the call ber_decode_krb5_key_data() doesn't seem to match. 0004 More duplicated error messages, e.g. Missing reply control 0005 More duplicated error messages, Failed to parse key data Typo, Incopatible Functionality-wise. Retrieving a keytab from a service without one fails in a strange way: # ipa-getkeytab -r -s `hostname` -p test1/`hostname` -k /tmp/test.kt Operation failed! Insufficient access rights Failed to get keytab I suppose a new permission is needed to add the ability to re-fetch keytabs. Should the admins group be able to do this out-of-the box? Maybe this is ok, I don't know, but it looks wierd. I fetched with -r the same keytab a number of times and this is what it contains: # klist -kt /tmp/test.kt Keytab name: FILE:/tmp/test.kt KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM The krbPrincipalKey value remained constant. rob From kybaker at redhat.com Mon Jun 9 17:43:42 2014 From: kybaker at redhat.com (Kyle Baker) Date: Mon, 9 Jun 2014 13:43:42 -0400 (EDT) Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <5395E17A.2050507@redhat.com> References: <538C8338.1040502@redhat.com> <1401896126.28354.2.camel@willson.usersys.redhat.com> <538F6AE7.4050308@redhat.com> <1401912616.597.7.camel@willson.usersys.redhat.com> <5390DDE1.1010502@redhat.com> <5395BFF2.1050109@redhat.com> <1402324970.9430.45.camel@willson.usersys.redhat.com> <5395E17A.2050507@redhat.com> Message-ID: <946176414.27862761.1402335822286.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 9.6.2014 16:42, Simo Sorce wrote: > > On Mon, 2014-06-09 at 16:08 +0200, Petr Vobornik wrote: > >>>> Accounts/Identity (7): > >>>> - Users > >>>> - Groups > >>>> - Hosts > >>>> - Host Groups > >>>> - Netgroups > >>>> - Services > >>>> - Automember > >>>> > >>>> ^ These are all identity or identity-grouping related > >> objects/actions > >>> > >>> +1 > >> > >> What are the chances that we will add some other identity to manage in > >> a future? > > > > I am not foreseeing anything in the core, but we can move Automember > > under configuration is we want to. > > > >>>> Directory (6): > >>>> - Permissions > >>>> - Privileges > >>>> - Roles > >>>> - Delegation > >>>> NOTE: the 4 above can be merged into a single 'Authorization' entry > >>>> perhaps > >>> > >>> May be it should be and "Administration" tab, I do not like the > >>> title. I understand where the directory comes from but this is IMo > >>> not intuitive for someone who does not know what is under the hood. > >>>> - Replication Topology > >> > >> > >> +1 that they should be together. They configure the "tool" and not > >> "data". Current "IPA Server" item name may be more suitable. > > > > Well this is not related to just the one server, but the whole set of > > servers. Maybe the plural "IPA Servers" ? > > > >>>> - Views (future) > >>>> > >>>> ^ Everything that deals with direct LDAP access/view > >>> > >>> > >>> I think views do not belong here. They belong in the same place > >>> where the trusts are. > > > > Just a FYI: I do not think views and trust should be in the same place. > > Views will also be available for regular IPA server with no trusts, the > > 2 are not strictly related. Views IMO really belong here with other > > directory configuration items. > > > >>> > >>>> > >>>> Network Services (4): > >>>> - Automount > >>>> - DNS > >>>> - CA > >>>> - Vault (future) > >> - Radius Server Proxies > > > > Isn't this strictly related to OTP ? I would put it in the same place. > > > >>>> > >>>> ^ All the additional network services or configuration of network > >>>> related services > >>> > >>> +1 > >>> > >>>> > >>>> Configuration (3): > >>>> - Trusts > >>>> - ID Ranges > >>>> - Realm Domains > >>>> - Global > >> - OTP Tokens ? > >>>> > >>>> ^ Anything that does not fit the above categories. > >>> > >>> +1 > >>> > >>>> > >>>> Docs: > >>>> - whatever :) > >>>> > >>>> > >>>> (*) The only doubt I have is about OTP Tokens, it may be worth > >>>> taking them off Policies and putting them into a new tab which in > >>>> future may also sport a pointer to user certificates management: > >>> > >>> Yeah, may be for now we put OTP as a top level for now and have > >>> tokens and create a RADIUS page to manage radius proxies? > >> > >> > >> We already have "RADIUS Servers" menu item for Radius s. proxies. > >> Martin forgot it in his proposal. > >> > >>> In future when we add other credentials we can rename it and add > >>> smart card related options. > >>> > >>>> > >>>> Authentication: > >>>> - OTP Tokens > >>>> - User Certificates (future) > >> > >> > >> With "Documentation", "Authentication" would be the 7th top level > >> item. > >> Ideal number of top level items is about 5-6. Because we have to fit > >> into 768px (minimum screen size before it's switched to compact menu). > > > > Why the minimum is 768 ? > > It's Bootstrap's minimum width of a small device(tablet). Navbar's > collapse threshold (@grid-float-breakpoint) is set to this value by default. > > It's possible to increase it but I don't think it's the best approach - > collapsed menu is harder to use. It can be solved in different manner > but it requires additional work. > > > > > Maybe we can drop Documentation from the top level ? Or make it really > > small by using a "?" as the menu symbol ? :) > > I like this. > > > > > Maybe we should stop using full names but instead get a set of icons > > that represent each item and have the name only as a tooltip ? > > > > This way the first level menu bar sizing would be consistent regardless > > of the language. > > It would solve the issue, but we should be consistent with other > projects as well. Also, it would require very good icons. I'm afraid > that it would be harder to use for newcomers. But probably better for > experienced users. > > Kyle what's your take? Icons which represent anything outside of common actions prove to be difficult to recognize for new or experienced users - depending on the amount. I think this concern would better be served by collapsing the top level to less options. Things related to administration of the tool like documentation could live on the top right near the login. This should be treated differently as it is not a currency a tool manages, but an app utility. It is okay if the top level collapses at the 768 width. This is the desired functionality for tablet size. Generally if we have no more than 7 words at the top level we should be fine. > > > > >> This functionality is provided by PatternFly. > >> > >> Also take into considerations that languages such as Spanish have much > >> longer expressions. > > > > Yeah maybe we should just avoid names here and use icons+tooltips/hover > > instead. > > > > -- > Petr Vobornik > From pviktori at redhat.com Mon Jun 9 18:08:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 20:08:27 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type Message-ID: <5395F81B.80900@redhat.com> Having another verification tool should help reviewing the permission patches. To avoid conflicts, apply on top of my patches 0568-0570 (Write User permissions). 0572: I tried to make the ACIs generated by the permission plugin as predictable as possible, but I missed one place it's affected by dict/set iteration order (which is undefined). Here's a fix. 0573: Minor refactoring to make the next patch easier. 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs to do is generate the file; comparing can be done bit-by-bit. I do run the validation results through difflib, but frankly it's easier just to use Git. 0575: Make 'permission' the default bind rule type for managed permissions. Rationale in the commit message. Run makeaci to verify this doesn't change the result. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0572-permission-plugin-Sort-rights-when-writing-the-ACI.patch Type: text/x-patch Size: 973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0573-Add-method-to-enumerate-managed-permission-templates.patch Type: text/x-patch Size: 3373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0574-Add-ACI.txt.patch Type: text/x-patch Size: 26104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0575-Make-permission-the-default-bind-type-for-managed-pe.patch Type: text/x-patch Size: 12580 bytes Desc: not available URL: From pviktori at redhat.com Mon Jun 9 18:21:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Jun 2014 20:21:01 +0200 Subject: [Freeipa-devel] [PATCH] 0576 Split long docstrings that were recently modified Message-ID: <5395FB0D.6090107@redhat.com> Hello, Some big plugin module docstrings were modified. This means translators will need to re-translate the whole string. To avoid the extra work in the future, I've split the strings we changed since the last time ipa.pot was regenerated. See: http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings Once this is accepted, I'll update Transifex to let people contribute translations for 4.0. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0576-Split-long-docstrings-that-were-recently-modified.patch Type: text/x-patch Size: 8939 bytes Desc: not available URL: From simo at redhat.com Mon Jun 9 19:02:29 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Jun 2014 15:02:29 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <5395F160.9050701@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> Message-ID: <1402340549.9430.58.camel@willson.usersys.redhat.com> On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > This patch set is an initial implementation of ticket #3859 > > > > It seem to be working fine in my initial testing but I have not yet > > tested all cases. > > > > However I wonted to throw it on the list to get some initial feedback > > about the choices I made wrt access control and ipa-getkeytab flags and > > default behavior. > > > > In particular, the current patch set would require us to make > > host/service keytabs readable by the requesting party (whoever that is, > > admin or host itself) in order to allow it to get back the actual > > keytab. I am not sure this is ideal. Also write access to the keytab is > > still all is needed to allow someone to change it. > > > > Neither is ideal, but it was simpler as a first implementation. In > > particular I think we should allow either permission indipendently, and > > it should be something an admin can change. However I do not like > > allowing normal writes or reads to these attributes, mostly because w/o > > access to the master key nobody can really make sense of actually > > reading out the contents of KrbPrincipalKey or could write a blob that > > can be successfully decrypted. > > > > So I was wondering if we might want to prevent both reading and writing > > via LDAP (except via extended operations) and instead use another method > > to determine access patterns. > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > always falling back to the old one (if a password has been provided) ? > > 0001 > > Needs a rebase. I did my best for testing. Rebased. > In check_service_name() why not just initialize name to NULL rather than > assigning it twice? Or is the value of name undefined if krb5_* fails? No it is set to NULL in case of failure actually. Fixed. > get_realm_backend() should probably have a comment on why returning NULL > is ok (either because there is no sdn or because there is no be). It > appears that things will eventually fail in get_entry_by_principal() Instead of adding complex explanations I immediately return with an error if get_realm_backend() returns NULL. > I think the Access Strategy comment needs to be expanded (or dropped) in > is_allowed_to_access_keys() I assume you mean is_allowed_to_access_attr(), and I am going to drop it from that place, I carried in on when moving code around. > In the fatal error in is_allowed_to_access_keys() should the error > include the bound user and the resource they attempted to modify? Uhm it does make sense to log what entry the user was trying to poke at, but not in is_allowed_to_access_attr(), I will add a log in the calling function. > 0002 > > ACK > > 0003 > > Nit: typo in commit, extedned Fixed > I'd prefer unique error messages for each ber decode failure. Added unique error messages in the key encoding section where they were missing. > Why is write access always required in ipapwd_getkeytab()? Would there > be a case where a principal can only re-fetch existing keys? I do not see where write access is always required, I test first with read access (SLAPI_ACL_READ) and then with write (SLAPI_ACL_WRITE) > Since getnew is defined as a boolean in the ASN.1, is the conditional > > if (getnew == 0) > > preferred over just > > if (getnew)? Future proof if we want to change it to a non-boolean value for whatever reason in the future ? :) > Some errors read "Out of Memory" and others "allocation failed". I think > with a fatal error the line number is included in the error. If I'm > wrong then perhaps something specific to the allocation should be included. Sorry I do not see where this occurs in patch 0003 > The error message to the call ber_decode_krb5_key_data() doesn't seem to > match. I am not sure what you mean, the error clearly state it can't decode the keys > 0004 > > More duplicated error messages, e.g. Missing reply control Well in either case it is missing, I did not think we need to be that detailed as something is clearly screwed up here, but ok, will make them unique here too. > 0005 > > More duplicated error messages, Failed to parse key data Can't find this. > Typo, Incopatible Can't find this > Functionality-wise. > > Retrieving a keytab from a service without one fails in a strange way: > > # ipa-getkeytab -r -s `hostname` -p test1/`hostname` -k /tmp/test.kt > Operation failed! Insufficient access rights Did you have access to retrieve the keytab ? > Failed to get keytab > > I suppose a new permission is needed to add the ability to re-fetch > keytabs. Yes. > Should the admins group be able to do this out-of-the box? No they shouldn't. > Maybe this is ok, I don't know, but it looks wierd. I fetched with -r > the same keytab a number of times and this is what it contains: > > # klist -kt /tmp/test.kt > Keytab name: FILE:/tmp/test.kt > KVNO Timestamp Principal > ---- ------------------- > ------------------------------------------------------ > 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:50 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:35:53 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:00 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:45 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM > 1 06/09/2014 13:36:51 test1/grindle.example.com at EXAMPLE.COM > > The krbPrincipalKey value remained constant. Why should it change ? You are asking to get the exact same key back, and that's what it is giving to you. New patches attached. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 16951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 23879 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11261 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15927 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From npmccallum at redhat.com Mon Jun 9 21:53:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 09 Jun 2014 17:53:59 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402340549.9430.58.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> Message-ID: <1402350839.9938.33.camel@ipa.example.com> On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > This patch set is an initial implementation of ticket #3859 > > > > > > It seem to be working fine in my initial testing but I have not yet > > > tested all cases. > > > > > > However I wonted to throw it on the list to get some initial feedback > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > default behavior. > > > > > > In particular, the current patch set would require us to make > > > host/service keytabs readable by the requesting party (whoever that is, > > > admin or host itself) in order to allow it to get back the actual > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > still all is needed to allow someone to change it. > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > particular I think we should allow either permission indipendently, and > > > it should be something an admin can change. However I do not like > > > allowing normal writes or reads to these attributes, mostly because w/o > > > access to the master key nobody can really make sense of actually > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > can be successfully decrypted. > > > > > > So I was wondering if we might want to prevent both reading and writing > > > via LDAP (except via extended operations) and instead use another method > > > to determine access patterns. > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > always falling back to the old one (if a password has been provided) ? > > > > 0001 > > get_realm_backend() should probably have a comment on why returning NULL > > is ok (either because there is no sdn or because there is no be). It > > appears that things will eventually fail in get_entry_by_principal() > > Instead of adding complex explanations I immediately return with an > error if get_realm_backend() returns NULL. The logic here is correct, it just reads awkwardly. It is probably fine as is. There appear to be indiscriminate tab indents throughout the patch. Please changes these to spaces. I'm a bit confused by the memory management in get_realm_backend() and its callers. Who owns 'be'? > > 0002 > > > > ACK One small nitpick, then I too say ACK. In the commit message, the second sentence doesn't need a line break. > > 0003 Same as patch 002: unnecessary line breaks in the commit message. I think ipapwd_getkeytab() is unnecessarily long. Several sections of it could be broken out into functions and would make it much more readable. Nearly forty lines of variable declarations is a bit much. :) You could break apart BER encoding/decoding, key writing, etc. The ipapwd_getkeytab() function variable declarations contain a mix of camel case and underscore styles. The comment containing the ASN.1 code contains invalid syntax. I find code like this very hard to read: if (rtag == (ctag | 2)) { Some named constants would be helpful here, or maybe a descriptively named macro function. We have C99 now, so I'd prefer local scope iterators in for loops: for (int i = 0; ...) -- rather than -- for (i = 0; ...) This has inconsistent indents: + svals = ipapwd_encrypt_encode_key(krbcfg, &data, + kenctypes ? num_kenctypes : + krbcfg->num_pref_encsalts, + kenctypes ? kenctypes : + krbcfg->pref_encsalts, + &errMesg); Has the new OID been registered? > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > if (getnew == 0) > > > > preferred over just > > > > if (getnew)? > > Future proof if we want to change it to a non-boolean value for whatever > reason in the future ? :) I agree with rcrit. Fix this. :) > > 0004 More occasional indentation issues (tab vs space). Local loop iterators preferred (for example: get_control_data()). I'm not a fan of the output variable name for ipa_ldap_bind(). Other than that, pretty close to ACK on this one. > > 0005 Unnecessary line breaks in git commit message. ASN.1 syntax errors. Also, this comment has some rogue tab indents. In ldap_get_keytab(), can't the big while loop be a for loop with a local scope iterator? Same with the for loop in ipa_string_to_enctypes(). Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to match the tab indents of the surrounding code. 0006 ACK Nathaniel From dpal at redhat.com Mon Jun 9 22:00:48 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Jun 2014 18:00:48 -0400 Subject: [Freeipa-devel] Fwd: [Bug 1060237] Allow to configure PAM service name in ssh configurarion In-Reply-To: References: Message-ID: <53962E90.8010508@redhat.com> This would have impact on the HBAC. We would be able to use different PAM services. -------- Original Message -------- Subject: [Bug 1060237] Allow to configure PAM service name in ssh configurarion Date: Mon, 09 Jun 2014 20:10:45 +0000 From: bugzilla at redhat.com To: dpal at redhat.com https://bugzilla.redhat.com/show_bug.cgi?id=1060237 --- Comment #3 from Petr Lautrbach --- There's a patch for support PAMServiceName in the referenced upstream bugzilla - https://bugzilla.mindrot.org/show_bug.cgi?id=2102 I've prepared a testing build with this patch applied and run a build based on Rawhide source. You can try it using my copr repository openssh_testing https://copr.fedoraproject.org/coprs/plautrba/openssh_testing/ -- You are receiving this mail because: You reported the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Mon Jun 9 23:52:17 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 09 Jun 2014 18:52:17 -0500 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <5395BAAE.6080507@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> <5391C5FD.5060908@redhat.com> <5391E19A.5080806@redhat.com> <53920A09.5030001@redhat.com> <5395BAAE.6080507@redhat.com> Message-ID: <539648B1.40203@redhat.com> On 6/9/2014 8:46 AM, Petr Vobornik wrote: > I've fixed issues #4, #2, #20 and #18. Commits in the branch, no rebase. > > With these 4 changes we are ready for the push. I'll squash them, if > necessary. You mean #11 instead of #2? The fixes are confirmed. >> 2. If there's a login error, the logo and the message shifts up. I >> think it would be nicer to display the error without changing the >> layout of the original page. Snapshots for #2, just in case: http://edewata.fedorapeople.org/ipa/images/snapshot5.png http://edewata.fedorapeople.org/ipa/images/snapshot6.png -- Endi S. Dewata From simo at redhat.com Tue Jun 10 00:58:29 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Jun 2014 20:58:29 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402350839.9938.33.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> Message-ID: <1402361909.9430.64.camel@willson.usersys.redhat.com> On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > Simo Sorce wrote: > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > tested all cases. > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > default behavior. > > > > > > > > In particular, the current patch set would require us to make > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > admin or host itself) in order to allow it to get back the actual > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > still all is needed to allow someone to change it. > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > particular I think we should allow either permission indipendently, and > > > > it should be something an admin can change. However I do not like > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > access to the master key nobody can really make sense of actually > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > can be successfully decrypted. > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > via LDAP (except via extended operations) and instead use another method > > > > to determine access patterns. > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > always falling back to the old one (if a password has been provided) ? > > > > > > 0001 > > > get_realm_backend() should probably have a comment on why returning NULL > > > is ok (either because there is no sdn or because there is no be). It > > > appears that things will eventually fail in get_entry_by_principal() > > > > Instead of adding complex explanations I immediately return with an > > error if get_realm_backend() returns NULL. > > The logic here is correct, it just reads awkwardly. It is probably fine > as is. > > There appear to be indiscriminate tab indents throughout the patch. > Please changes these to spaces. There are because the coed is old, I do not change the style of a piece of code if we are just changing a few lines. You need to read the patch in the context of the code to seen it. > I'm a bit confused by the memory management in get_realm_backend() and > its callers. Who owns 'be'? The main DS code afaik. > > > 0002 > > > > > > ACK > > One small nitpick, then I too say ACK. In the commit message, the second > sentence doesn't need a line break. I try to keep comments within 72 chars (though sometimes I forget and go past till 80), which is why there is a line break there. > > > 0003 > > Same as patch 002: unnecessary line breaks in the commit message. See above. > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > could be broken out into functions and would make it much more readable. That has already been done :-) You should see the original ipa_setkeytab() ... > Nearly forty lines of variable declarations is a bit much. :) You could > break apart BER encoding/decoding, key writing, etc. Perhaps, but wouldn't change the amount of code, unless you say it is necessary in order to do a better review I will skip doing that for now. > The ipapwd_getkeytab() function variable declarations contain a mix of > camel case and underscore styles. Inherited from old code, see ipa_setkeytab() > The comment containing the ASN.1 code contains invalid syntax. Please be more specific ? That pseudo code is not meant to be compiled, so it is a bit liberal. > I find code like this very hard to read: > if (rtag == (ctag | 2)) { > Some named constants would be helpful here, or maybe a descriptively > named macro function. > > We have C99 now, so I'd prefer local scope iterators in for loops: > for (int i = 0; ...) -- rather than -- for (i = 0; ...) We still declare everything upfront in freeipa code, not going to change style with these patches. > This has inconsistent indents: > + svals = ipapwd_encrypt_encode_key(krbcfg, &data, > + kenctypes ? num_kenctypes : > + krbcfg->num_pref_encsalts, > + kenctypes ? kenctypes : > + krbcfg->pref_encsalts, > + &errMesg); Yes these indents are not the best but allow to keep the code within 80 chars. > Has the new OID been registered? Yup. > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > if (getnew == 0) > > > > > > preferred over just > > > > > > if (getnew)? > > > > Future proof if we want to change it to a non-boolean value for whatever > > reason in the future ? :) > > I agree with rcrit. Fix this. :) Fixing how ? There is nothing wrong with this code, note that if (getnew) would require to change the order of the 2 blocks and I wanted the short one first intentionally, so I would have to use if (!getnew), is this ok ? > > > 0004 > > More occasional indentation issues (tab vs space). > > Local loop iterators preferred (for example: get_control_data()). be more specific please. > I'm not a fan of the output variable name for ipa_ldap_bind(). That's a convention we use both in freeipa and sssd code. > Other than that, pretty close to ACK on this one. > > > > 0005 > > Unnecessary line breaks in git commit message. As above > ASN.1 syntax errors. Also, this comment has some rogue tab indents. I'l fix the ::= issues, anything else ? > In ldap_get_keytab(), can't the big while loop be a for loop with a > local scope iterator? Same with the for loop in > ipa_string_to_enctypes(). No, we never use local scope iterators in freeipa code, I do not see why we should introduce that now. > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > match the tab indents of the surrounding code. ah nice catch > 0006 > > ACK I'll fix the minor issue after I get replies to my questions. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Jun 10 01:49:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 09 Jun 2014 21:49:45 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402361909.9430.64.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> Message-ID: <1402364985.9938.45.camel@ipa.example.com> On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > Simo Sorce wrote: > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > tested all cases. > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > default behavior. > > > > > > > > > > In particular, the current patch set would require us to make > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > admin or host itself) in order to allow it to get back the actual > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > still all is needed to allow someone to change it. > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > particular I think we should allow either permission indipendently, and > > > > > it should be something an admin can change. However I do not like > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > access to the master key nobody can really make sense of actually > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > can be successfully decrypted. > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > via LDAP (except via extended operations) and instead use another method > > > > > to determine access patterns. > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > 0001 > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > is ok (either because there is no sdn or because there is no be). It > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > Instead of adding complex explanations I immediately return with an > > > error if get_realm_backend() returns NULL. > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > as is. > > > > There appear to be indiscriminate tab indents throughout the patch. > > Please changes these to spaces. > > There are because the coed is old, I do not change the style of a piece > of code if we are just changing a few lines. > You need to read the patch in the context of the code to seen it. If it were just the problem you alluded to, I wouldn't have called it out. I'm referring to tabs in the middle of new code that uses spaces. This is most likely the result of copy/paste. Either write all the new code to use tabs or match the copy/pasted lines to the surrounding new code (my preference). > > > > 0002 > > > > > > > > ACK > > > > One small nitpick, then I too say ACK. In the commit message, the second > > sentence doesn't need a line break. > > I try to keep comments within 72 chars (though sometimes I forget and go > past till 80), which is why there is a line break there. Yeah, it just looks bad when sent over email, which is why I noticed it. > > > > 0003 > > > > Same as patch 002: unnecessary line breaks in the commit message. > > See above. > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > could be broken out into functions and would make it much more readable. > > That has already been done :-) > You should see the original ipa_setkeytab() ... I'm not talking about ipapwd_setkeytab(). I'm talking about ipapwd_getkeytab(). This is entirely new code. There are very clear spots where it could be broken up. I consider this the biggest issue in this set of patches for two important reasons: 1. It makes the function really hard to review. 2. It is one of the most security/policy sensitive part of the code. These two are a bad combo. > > Nearly forty lines of variable declarations is a bit much. :) You could > > break apart BER encoding/decoding, key writing, etc. > > Perhaps, but wouldn't change the amount of code, unless you say it is > necessary in order to do a better review I will skip doing that for now. See above. > > The ipapwd_getkeytab() function variable declarations contain a mix of > > camel case and underscore styles. > > Inherited from old code, see ipa_setkeytab() Sure, but it is also a brand new section. Doesn't your editor have a variable renamer? Mine does. ;) > > The comment containing the ASN.1 code contains invalid syntax. > > Please be more specific ? > That pseudo code is not meant to be compiled, so it is a bit liberal. ::= is, I think, the only issue. > > I find code like this very hard to read: > > if (rtag == (ctag | 2)) { > > Some named constants would be helpful here, or maybe a descriptively > > named macro function. > > We have C99 now, so I'd prefer local scope iterators in for loops: > > for (int i = 0; ...) -- rather than -- for (i = 0; ...) > > We still declare everything upfront in freeipa code, not going to change > style with these patches. All of the OTP code *in this same exact plugin* uses the new style. I consider us to have migrated at least in this portion of the code. > > This has inconsistent indents: > > + svals = ipapwd_encrypt_encode_key(krbcfg, &data, > > + kenctypes ? num_kenctypes : > > + krbcfg->num_pref_encsalts, > > + kenctypes ? kenctypes : > > + krbcfg->pref_encsalts, > > + &errMesg); > > Yes these indents are not the best but allow to keep the code within 80 > chars. I'm not worried about the problem with keeping them under 80 lines. No problem there. The problem is that the lines are inconsistently indented. They should be the same (compare the two lines that start with "krbcfg->"). > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > if (getnew == 0) > > > > > > > > preferred over just > > > > > > > > if (getnew)? > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > reason in the future ? :) > > > > I agree with rcrit. Fix this. :) > > Fixing how ? There is nothing wrong with this code, note that if > (getnew) would require to change the order of the 2 blocks and I wanted > the short one first intentionally, so I would have to use if (!getnew), > is this ok ? That is how I would write it. > > > > 0004 > > > > More occasional indentation issues (tab vs space). > > > > Local loop iterators preferred (for example: get_control_data()). > > be more specific please. for (int i = 0; ...) > > I'm not a fan of the output variable name for ipa_ldap_bind(). > > That's a convention we use both in freeipa and sssd code. I haven't seen that before. But I'll take your word on it. > > Other than that, pretty close to ACK on this one. > > > > > > 0005 > > > > Unnecessary line breaks in git commit message. > > As above > > > ASN.1 syntax errors. Also, this comment has some rogue tab indents. > > I'l fix the ::= issues, anything else ? I think that is it. > > In ldap_get_keytab(), can't the big while loop be a for loop with a > > local scope iterator? Same with the for loop in > > ipa_string_to_enctypes(). > > No, we never use local scope iterators in freeipa code, I do not see why > we should introduce that now. Again, we have started using them in this plugin. > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > match the tab indents of the surrounding code. > > ah nice catch Nathaniel From mkosek at redhat.com Tue Jun 10 06:56:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 08:56:49 +0200 Subject: [Freeipa-devel] Expired passwords cannot be changed via LDAP In-Reply-To: <5395D8CF.1070608@redhat.com> References: <1401499643.3590.39.camel@willson.li.ssimo.org> <1402069631.4323.35.camel@ipa.example.com> <53955269.8060301@redhat.com> <5395775D.8080609@redhat.com> <53958845.6010003@redhat.com> <1487182411.9801339.1402308934165.JavaMail.zimbra@redhat.com> <53958C05.8060905@redhat.com> <593476348.20107188.1402318277395.JavaMail.zimbra@redhat.com> <1885190508.20112041.1402318887320.JavaMail.zimbra@redhat.com> <1402322591.2883.4.camel@ipa.example.com> <5395D8CF.1070608@redhat.com> Message-ID: <5396AC31.7000600@redhat.com> On 06/09/2014 05:54 PM, Dmitri Pal wrote: > On 06/09/2014 10:03 AM, Nathaniel McCallum wrote: >> On Mon, 2014-06-09 at 09:01 -0400, Simo Sorce wrote: >>>>>>> From: "Martin Kosek" >>>>>>> Given all sort of issues we get, I am thinking we should just revert it >>>>>>> unless >>>>>>> there is a quick fix available. >>> Instead of reverting I am thinking we may want to make this optional by >>> adding a configuration parameter that defaults to False for now. Once we can >>> manage better the password change we can turn it on by deault, in the >>> meanwhile admins can choose by themselves the lesser evil. >>> >>> Thoughts? >> I'm not a fan of introducing a new configuration parameter for a >> temporary workaround. >> >> My preference is to revert it and have a small project for the next >> release which handles all the "non-authenticated" corner cases. This >> would include: >> * Expired passwords >> * Password changes >> * Token syncing >> * Unauthenticated RPCs (rpcserver.py rework) >> * others? >> >> I think there is some value to be gained by thinking about these >> problems as a whole and devising a set of consistent mechanisms for >> them. >> >> Nathaniel >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > +1 > This is my preference as well, as written in other part of this thread. I reverted the patch, added an appropriate description (attached) and pushed to master. I updated the ticket, added Nathaniel's suggestions and moved it to needs triage. Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Revert-Check-for-password-expiration-in-pre-bind.patch Type: text/x-patch Size: 3866 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 10 07:55:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 09:55:17 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53919D09.20302@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> Message-ID: <5396B9E5.4050605@redhat.com> On 06/06/2014 12:50 PM, Jan Cholasta wrote: > On 23.1.2014 14:34, Jan Cholasta wrote: >> On 22.1.2014 16:43, Simo Sorce wrote: >>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>> Later in the patch you seem to be changing from needing >>>>>>> managedby_host >>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>> why that >>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>> original >>>>>>> check is not right anymore ? >>>>>> >>>>>> The original check is wrong, see >>>>>> . >>>>>> >>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>> right, but even if it is not, I think we should still check for write >>>>>> access to the SAN services, so that access control can be (partially) >>>>>> handled by ACIs. >>>>> >>>>> Right, I remembered that comment, but it just says to check the right >>>>> object's managed-by, here instead you changed it to check if you can >>>>> write the usercertificate. >>>>> >>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>> >>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>> Certificates and kerberos keys". >>>> >>>> I think the check can be extended to users as well, so that requesting >>>> certificate with SAN is allowed only to users which have write access to >>>> the SAN services. >> >> I have done the modification, see attached patches. >> >>> >>> Sounds good to me then, thanks for explaining. >>> >>> The patches also look good, but I would like someone to give them a try >>> for a formal ack. >> >> OK, thanks. >> > > Bump. > > I have added stricter validation of subject alt names as well as certificate > extensions in general to the second patch. Thanks! > Updated patches attached. > > Note that you will need python-nss 0.15 in order to test, you can get a RPM for > Fedora here: . John, do you think we could build python-nss 0.15 also for Fedora 20? The fix incorporated in it is pretty important to warrant bugfix update in bodhi. It would also allow FreeIPA 4.0 to be installed on Fedora 20. > Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work, > because . This worked for me, I suspect this is a DS bug. More info in the ticket. Now back to review of the patch: 210.4: looks ok 234.4: 1) Virtual operation "request certificate with subjectaltname" should be a member of Certificate Administrators privilege 2) I would write "Request Certificate With SubjectAltName" with "with" instead of "With". I.e.: Request Certificate with SubjectAltName 3) Why is the extension check only enforced for non-hosts? + if not bind_principal.startswith('host/'): + for ext in extensions: + operation = self._allowed_extensions.get(ext) + if operation: + self.check_access(operation) My tricky certmonger request passed: # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com -E mkosek at redhat.com while when I posted the same CSR as privileged user, it was rejected: $ klist Ticket cache: KEYRING:persistent:962000003:962000003 Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM $ ipa cert-request --principal test/`hostname` certmonger.csr ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden 4) Regular users cannot read Virtual Operations, so even if I assign them a permission, command is refused: $ ipa cert-request --principal test/`hostname` openssl.csr ipa: ERROR: Insufficient access: No such virtual command I think we will need to create new managed permission "Read Virtual Operations" and assign it to "Certificate Administrators" privilege by default as this privilege has the virtual operation permissions assigned. Petr3, what is your take on this? Otherwise the patch worked well for me, the authorization part looked OK. My biggest concern was just the host/user differentiation wrt unknown subjectaltname types. Martin From pviktori at redhat.com Tue Jun 10 08:05:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Jun 2014 10:05:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type In-Reply-To: <5395F81B.80900@redhat.com> References: <5395F81B.80900@redhat.com> Message-ID: <5396BC3F.4040002@redhat.com> On 06/09/2014 08:08 PM, Petr Viktorin wrote: > Having another verification tool should help reviewing the permission > patches. > > > To avoid conflicts, apply on top of my patches 0568-0570 (Write User > permissions). > > > 0572: I tried to make the ACIs generated by the permission plugin as > predictable as possible, but I missed one place it's affected by > dict/set iteration order (which is undefined). Here's a fix. > > 0573: Minor refactoring to make the next patch easier. > > 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs > to do is generate the file; comparing can be done bit-by-bit. > I do run the validation results through difflib, but frankly it's easier > just to use Git. On my way home yesterday I remembered I left out an important piece of information - the DN where the ACI is. Attaching updated patch 0574. > 0575: Make 'permission' the default bind rule type for managed > permissions. Rationale in the commit message. > Run makeaci to verify this doesn't change the result. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0574.2-Add-ACI.txt.patch Type: text/x-patch Size: 31033 bytes Desc: not available URL: From tbabej at redhat.com Tue Jun 10 08:13:16 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 10 Jun 2014 10:13:16 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <5391A03D.1030408@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> Message-ID: <5396BE1C.8000000@redhat.com> Thank you for the detailed review. Responses to all the issues found are inline: On 06/06/2014 01:04 PM, Petr Viktorin wrote: > On 06/05/2014 03:14 PM, Petr Viktorin wrote: >> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>> Hi, >>> >>> the following set of patches implements the ticket: >>> >>> https://fedorahosted.org/freeipa/ticket/4052 >>> >>> The refactoring touches both server and client bits, main features are: >>> >>> * easier inheritance and creation of new platform modules >>> * all filesystem paths are defined as platform constants >>> * platform related functionality is implemented as transparent platform >>> tasks >>> (as opposed to platform dependent implementations) >>> * no need to implement your own authconfig class, since tasks >>> encapsulate >>> the relevant parts of the code >>> >>> More documentation, mainly on the part of the documenting the tasks >>> contracts >>> and the creation of own platform modules should follow later. >>> >> >> Thanks for all the work! >> I didn't test yet; actually I haven't read it all yet, but sharing the >> first thoughts might make the review faster. If you'd rather have the >> whole thing, just wait :) >> >> >> 0202: OK >> >> 0203: >> Can we remove the leading underscores from `__wait_for_open_ports`? I >> don't think there's a good reason for that to be "private", let alone >> super-annoyingly "private". Fixed. >> >> It would be nice to have the Services' __init__s take an optional `api` >> argument, and then use `self.api` everywhere. I'm certain we'd >> appreciate it in the future. >> Added. >> In SystemdService.restart, I think the comment is obsolete by now. But >> If we want to keep it we should add a link to >> https://bugs.freedesktop.org/show_bug.cgi?id=39824 >> Removed. >> Also, it's pointless to just fix whitespace issues and line length. If >> you're cleaning up, please convert the code to actually idiomatic >> Python, otherwise these are just changes for the sake of change. (Or >> maybe for the sake of passing automated style checks, which is pretty >> stupid. The real issues are those the tool doesn't report. There's a >> nice summary on using the `pep8` tool like this in the last paragraph of >> http://bugs.python.org/msg193909.) >> I do not go to such length as to run pep8 tool voluntarily to check all the errors. IDE of my choice (NINJA-IDE - check it out!) highlights a subset of PEP8 errors in the editor, so it makes it super easy to spot these errors and fix them very quickly. But I agree and you have point with the converting the code to idiomatic python code. >> In PlatformService.start, use `with` for open files. Also flush() is >> unnecessary before closing a file. Fixed. Also fixed the same issues in the stop method. >> >> In SystemdService.service_instance, >> len(string) == 0 >> translates to: >> not string >> Fixed. >> In SystemdService.parse_variables, >> map(lambda x: y(x), z) >> translates to: >> [y(x) for x in z] >> (plus you can skip the [ ] since you don't need a list) >> Fixed. >> In SystemdService.stop/start >> if 'context' in api.env and api.env.context in X: >> translates to: >> if getattr(api.env, 'context', None) in X: >> Fixed. >> SystemdService.is_installed, the flag is not needed, just return >> directly. >> Fixed. >> 0204: >> When commenting what a function does, use a docstring. >> Will be documented in a later patch. >> 0205: OK >> 0206: OK >> >> 0207: >> In system_units: again, a generator expression is better than >> map(lambda, ...) >> Fixed. >> In FedoraService.__init__, >> len(string.split(c)) == 1 >> translates to: >> c not in string >> Fixed. >> In FedoraDirectoryService, the comment applies just to restart(), could >> you move it there? >> Done. >> In FedoraDirectoryService.restart, there's `len(instance_name) > 0` >> again >> Fixed. >> In FedoraCAService, can __wait_until_running have just one leading >> underscore? I don't think we need to hide it. >> Fixed. >> In FedoraCAService.__wait_until_running, there are some hardcoded paths. >> Can we pull them from the paths module? It'll be easier to reuse if we >> ever find out the class applies to more than Fedora. >> (You could do it in some later patch of course.) >> Addresed in a later patch. >> 0208: >> Again some hardcoded paths, would be nice to pull them from the paths >> object >> Addresed in a later patch. >> I'm surprised you left the parentheses around `if` expressions, since >> you're so meticulous about whitespace and line length... >> Fixed (in both cases). >> check_selinux_status, in the RuntimeError message, assumes that it's >> called from an installation. This should at least be pointed out in the >> docstring. >> >> There's no newline at the end of the file. >> >> 0209: >> ipa-client-install, --noac help: "Red Hat" has two words. Also it's a >> company; I don't think "Red Hat based distributions" is a correct use of >> the trademark. In comments/class names it doesn't really matter but in >> user-facing text we should try to be professional. >> We can either go with "Fedora-based" here and sort this out in a RHEL >> patch if needed, or better, adjust the help text (or visibility of the >> option) based on if the platform uses authconfig. >> I'm thinking we could go as far as to provide a way in the installers to define platform dependent options. What do you think? >> In configure_sshd_config, why did you remove `authorized_keys_changes = >> candidate`? >> Thanks for spotting that, fixed. >> base.tasks: These need docstrings. Will those included in the >> documentation that you want to provide later? >> >> base.{tasks,fedora}.restore_pre_ipa_client_configuration: line too long. Fixed. >> You fix this in a later patch, why not here? >> >> >> Each of the functions configure_sssd_for_user_info_and_auth, >> configure_ldap_for_user_info, configure_auto_homedir_creation now >> execute authconfig. >> Yes, that was a tradeoff for the portability. >> In the base.authconfig.Authconfig docstring, the example is wrong. >> >> In that docstring and in ipaplatform.fedora.tasks, instead of >> auth_config.enable("sssd").\ >> enable("sssdauth") >> please use >> auth_config.enable("sssd") >> auth_config.enable("sssdauth") >> In addition to PEP8 compliance (this is Python, not JQuery), it's more >> diff-friendly. >> Alternately, be pythonic and add support for: >> auth_config.enable("sssd", "sssdauth") >> auth_config.add_parameters(nisdomain=nisdomain): >> Fixed. >> It seems that for every AuthConfig.execute(), you need to do >> auth_config.add_option("update") >> Why not roll that into execute(), with a (default) argument? >> Fixed. >> AuthConfig.__build_args should lose the leading underscores. Nothing to >> hide here; according to the docstring it's even part of the public >> interface. I'd also move it (and execute()) to the base implementation, >> since it's quite unlikely that authconfig would use different arguments >> in other distros that support it (and they can override anyway). >> Fixed. >> There's another hardcoded path, "/usr/sbin/authconfig". >> Fixed. >> 0210: OK >> It might be good to point to this patch in some docs, there are some >> ideas for porting to System V distros. >> >> 0211: >> I believe ipaplatform.paths.path_namespace doesn't exist yet. Should >> these changes be in a later patch? >> >> I see more hardcodced paths. >> Will be dealth with later. >> For logging, use multiple arguments instead of %, and str() is >> unnecessary, e.g.: >> root_logger.info("Failed to add CA to the systemwide " >> "CA trust database: %s", e) >> >> Fixed. >> In backup_and_replace_hostname, please use the logger for the message, >> so it ends up a logfile. (Do it in addition to the print if the logger >> might be unconfigured.) >> Fixed. >> In backup_and_replace_hostname, the `readlines` in `for line in >> f.readlines():` is unnecessary. >> Fixed. >> 0212: OK >> 0213: OK >> 0214: OK >> 0215: Looks OK >> (pylint should be enough to check this, haven't run it yet) >> >> 0216: >> I see a lot of these lines: >> from ipaplatform.paths import path_namespace as paths >> I don't think it's healthy to have an object that you *always* import as >> another name (actually in a single codebase we shouldn't need renaming >> objects on import at all, but that would be a very minor nitpick). We >> had some discussions about this, maybe I gave you the idea; sorry for >> any miscommunication. (I was mostly scared at wanting to redefine a >> module's __getattr__, which is some seriously arcane magic -- you should >> only try it at home.) >> >> You can do better by just placing the class in a convenient place: >> ipaplatform//paths_module.py: >> class PathsNamespace(object): >> ... >> ipaplatform/paths_module.py ? >> ipaplatform//paths_module.py >> ipaplatform/__init__.py: >> from ipaplatform.paths_module import PathsNamespace >> paths = PathsNamespace() >> any other module: >> from ipaplatform import paths >> mkdir(paths.IMPORTANT_DIR) >> As we discussed, to avoid cyclical imports, separate modules for paths and tasks are needed. Calling the paths_namespace object by its descriptive name is rather cumbersome, so I changed that to: from ipaplatform.paths import paths from ipaplatform.tasks import tasks >> ipalib/__init__.py: I think your regex got too hungry here... >> Thanks for spotting that. >> I'd add a _TEMPLATE suffix to names of "paths" containing %s, to make it >> clear what they are. >> > Fixed. > Continuing with 0216: > ipaserver/install/httpinstance.py: NSS_CONF is already in paths; > SSL_CONF should be added there as well. > selinux_warning should use paths.SETSEBOOL. > Fixed. > Regarding the integration tests, we'll probably want to have each host > have a "paths" attribute and use that in the commands, since each can > potentially be on a different platform. > That can be done later, though. > > ipatests/test_xmlrpc/test_automount_plugin.py: this change is unnecessary > > 0217: OK > 0218: OK > 0219: As I said above, I'd prefer this renamed > 0220: Looks OK > 0221: Looks OK > > 0222: > Similarly to paths, we should do `from ipaplatform import tasks`; the > module can have an inconvenient name. > Fixed. > >> >> When moving code around you remove the Authors: lines from the top of >> the files, and replace them with yourself. I don't think that's a fair >> thing to do. > Not trying to steal the credit here :) I fixed the Authors and copyright years. > > Functionally, I didn't find any regressions. > Updated patchset attached. Please note the new patch 223. I also added new symlinks to platform modules to .gitignore. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0202-2-ipaplatform-Create-separate-module-for-platform-file.patch Type: text/x-patch Size: 6513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0203-2-ipaplatform-Move-service-base-platfrom-related-funct.patch Type: text/x-patch Size: 33013 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0204-2-ipaplatform-Move-default-implementations-of-tasks-fr.patch Type: text/x-patch Size: 3644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0205-2-ipaplatform-Create-default-implementations-for-tasks.patch Type: text/x-patch Size: 870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0206-2-ipaplatform-Add-base-fedora-platform-module.patch Type: text/x-patch Size: 5314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0207-2-ipaplatform-Moved-Fedora-16-service-implementations-.patch Type: text/x-patch Size: 20325 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0208-2-ipaplatform-Move-restore_context-and-check_selinux_s.patch Type: text/x-patch Size: 5549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0209-2-ipaplatform-Do-not-require-custom-Authconfig-impleme.patch Type: text/x-patch Size: 19909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0210-2-ipaplatform-Remove-legacy-redhat-platform-module.patch Type: text/x-patch Size: 12402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0211-2-ipaplatform-Move-Fedora-specific-implementations-of-.patch Type: text/x-patch Size: 11812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0212-2-ipaplatform-Change-platform-dependant-code-in-freeip.patch Type: text/x-patch Size: 18012 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0213-2-ipaplatform-Change-service-code-in-freeipa-to-use-ip.patch Type: text/x-patch Size: 45297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0214-2-ipaplatform-Change-paths-dependant-on-ipaservices-to.patch Type: text/x-patch Size: 3705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0215-2-ipaplatform-Remove-redundant-imports-of-ipaservices.patch Type: text/x-patch Size: 16436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0216-2-ipaplatform-Move-all-filesystem-paths-to-ipaplatform.patch Type: text/x-patch Size: 158632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0217-2-ipaplatform-Remove-remnants-of-the-ipapython-platfor.patch Type: text/x-patch Size: 16172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0218-2-ipaplatform-Change-makefiles-to-accomodate-for-new-p.patch Type: text/x-patch Size: 9068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0219-2-ipaplatform-Let-fedora-path-module-use-PathNamespace.patch Type: text/x-patch Size: 882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0220-2-ipaplatform-Link-to-platform-module-during-build-tim.patch Type: text/x-patch Size: 1972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0221-2-ipaplatform-Pylint-fixes.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0222-2-ipaplatform-Contain-all-the-tasks-in-the-TaskNamespa.patch Type: text/x-patch Size: 21565 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0223-ipaplatform-Move-hardcoded-paths-from-Fedora-platfor.patch Type: text/x-patch Size: 16018 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 10 08:13:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 10:13:33 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed In-Reply-To: <5395A68B.9090502@redhat.com> References: <538F4CA1.4070501@redhat.com> <53918C14.2080204@redhat.com> <5395A68B.9090502@redhat.com> Message-ID: <5396BE2D.2030609@redhat.com> On 06/09/2014 02:20 PM, Petr Viktorin wrote: > On 06/06/2014 11:38 AM, Martin Kosek wrote: >> On 06/04/2014 06:43 PM, Petr Viktorin wrote: >>> Hello, >>> I try to think about any kind of data the user might have in LDAP, but in the >>> spirit of YAGNI, I'll deal with the various corner cases in IPA's historic >>> default permissions as I go along. >>> >>> Patch 0568 adds support for the case where the default permissions changed in >>> something else than attribute lists. Needed for the 'Change User password' >>> permission. >>> >>> Patch 0569 converts user permissions to managed. >>> >>> Patch 0570 fixes https://fedorahosted.org/freeipa/ticket/3697 >> >> >> 1) Add aci has targetfilter part - is that intentional? > > Yes. > From the permission plugin''s point of view, it's part of the definition of > --type user (i.e. "this applies to users"). > > Regardless I think it should be there. > > >> # ipa permission-show 'System: Add Users' --all --raw >> ... >> aci: (targetfilter = "(objectclass=posixaccount)")(version 3.0;acl >> "permission:System: Add Users";allow (add) groupdn = "ldap:///cn=System: Add >> Users,cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test";) >> >> This part IS effective though, so it may not be a bad thing at all, to keep it >> in the ACI: >> >> # ldapadd -Y GSSAPI >> SASL/GSSAPI authentication started >> SASL username: fbar at MKOSEK-FEDORA20.TEST >> SASL SSF: 56 >> SASL data security layer installed. >> dn: cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test >> objectclass: top >> objectclass: nscontainer >> cn: foo >> >> adding new entry "cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test" >> ldap_add: Insufficient access (50) >> additional info: Insufficient 'add' privilege to add the entry >> 'cn=foo,cn=users,cn=accounts,dc=mkosek-fedora20,dc=test'. >> >> # ipa user-add --first=Foo --last Bar fbar2 >> ------------------ >> Added user "fbar2" >> ------------------ >> User login: fbar2 >> First name: Foo >> ... >> >> 2) System: Add User to default group >> >> I was wondering whether we should keep the AluCI in cn=groups container or >> directly with the group, but I think the group itself is a good idea. (Unless >> someone deletes and recreates it). > > Hm, this is a good point. If the ipausers group is deleted, there'll be an > permission with a missing ACI that can't be created. That could be quite annoying. > I put the ACI it in the container. > >> 3) System: Change User password >> >> I hit some nasty DS error which prevented authorized user to update password. >> ACI log attached. Ludwig, does that ring any bell? >> >> The ACI itself looks OK though as after I restarted DS, it started to work. >> Maybe DS did not cache the ACIs properly after upgrade? > > Which DS version are you using? > >> 4) When running user unit tests, I found couple issues: >> >> a) Some attributes we may still miss in the permissions: >> - krbPrincipalExpiration >> - userclass >> - ipaUserAuthType >> - preferredLanguage >> >> I am thinking we could base Modify Users permission on the read one and add >> regular attributes there > > I put in userclass and preferredLanguage. > I'm not sure about the other two; should regular user admins be able to change > these? Good question. I think User Administrators should be able to set krbPrincipalExpiration or ipaUserAuthType, though it is true it may not be part of regular "Modify Users" permission and we may want to create more permissions. > >> b) Read membership ACIs for users and groups miss "member" attribute and thus >> indirect/direct processing goes wrong. > > Added. 1) Hm, I think was not clear enough. memberOf should not be added to users, as no object should be "member of user". Please revert this change. I originally thought it is missing in "Read Group Membership" permissions, but it isn't. We are again hitting the problem of a search operation when we are not allowed to search on all attributes (the CVE fix). This is the search produced by "ipa user-show fbar": [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" scope=2 filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" attrs="" [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 etime=0 It returns zero results, until I also allow memberUser and memberHost: # ipa permission-mod 'System: Read Group Membership' --attrs={member,memberof,memberuid,memberuser,memberhost} Now I get the results: [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" scope=2 filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" attrs="" [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 etime=0 ipa user-show fbar ... Member of groups: ipausers <<<<< Indirect Member of role: test ... User still cannot see if he is direct or indirect member of role, but this may not be a problem. The easiest approach solution may be to update all "Read * Membership" permissions/ACIs to always contain member&memberuser&memberhost unless we want to again produce multiple LDAP searches for checking direct/indirect membership. 2) Installation produces update errors: ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing required attribute "objectclass" ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing required attribute "objectclass" Problem is in install/updates/45-roles.update, permissions you converted still have "member" update here. dn: cn=Change a user password,cn=permissions,cn=pbac,$SUFFIX add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' dn: cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' Speaking if which, this privilege also needs to be added to default privileges of the managed permissions. Martin From mkosek at redhat.com Tue Jun 10 08:21:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 10:21:54 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <5396BE1C.8000000@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> Message-ID: <5396C022.7050905@redhat.com> On 06/10/2014 10:13 AM, Tomas Babej wrote: > Thank you for the detailed review. Responses to all the issues found are > inline: > > On 06/06/2014 01:04 PM, Petr Viktorin wrote: ... >>> 0209: >>> ipa-client-install, --noac help: "Red Hat" has two words. Also it's a >>> company; I don't think "Red Hat based distributions" is a correct use of >>> the trademark. In comments/class names it doesn't really matter but in >>> user-facing text we should try to be professional. >>> We can either go with "Fedora-based" here and sort this out in a RHEL >>> patch if needed, or better, adjust the help text (or visibility of the >>> option) based on if the platform uses authconfig. >>> > I'm thinking we could go as far as to provide a way in the installers to > define > platform dependent options. What do you think? I think it may be needed one day (in a galaxy far far away) when there is sufficient need for it. But I do not think that this use case warrants it. As Petr suggested, I would go just with the original help or something like that: help="do not modify the nsswitch.conf and PAM configuration (does not run authconfig, when available)" Martin From pvoborni at redhat.com Tue Jun 10 08:33:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jun 2014 10:33:37 +0200 Subject: [Freeipa-devel] [PATCH] 592-628 Update to PatternFly In-Reply-To: <539648B1.40203@redhat.com> References: <5367BF29.2070901@redhat.com> <20140512174643.60e13a05@unused-4-246.brq.redhat.com> <537A0011.5050207@redhat.com> <538358FA.6070304@redhat.com> <53874C4A.3020402@redhat.com> <53907DEC.8050106@redhat.com> <5391C5FD.5060908@redhat.com> <5391E19A.5080806@redhat.com> <53920A09.5030001@redhat.com> <5395BAAE.6080507@redhat.com> <539648B1.40203@redhat.com> Message-ID: <5396C2E1.8090608@redhat.com> On 10.6.2014 01:52, Endi Sukma Dewata wrote: > On 6/9/2014 8:46 AM, Petr Vobornik wrote: >> I've fixed issues #4, #2, #20 and #18. Commits in the branch, no rebase. >> >> With these 4 changes we are ready for the push. I'll squash them, if >> necessary. > > You mean #11 instead of #2? The fixes are confirmed. Yes #11, sorry for the confusion. Fixed for issue #20 was squashed into patch #640. Pushed to master: * ff17af16e7ba953a70c434fea1dbe128810f6028 webui: remove logout.html * b577b3d3656f51edf0c33bdb00863c03b11ae512 webui: remove login.html * 6a8eeff22d98c8c32c770869427883198278d077 webui: add PaternFly css * 78f026bc9013347d4bc2b4c02e72b19495a1b8ac webui: apply PatternFly login theme on reset_password.html * 1829fa2c1571428cb4318443387dde1707fc9641 webui: apply PatternFly theme on config pages * 5a2aed99baa059e9ccdfd9f0d2f2b4cb68ba8930 webui: styles for alert icons * f0cf2e10d5ca6ce261c256288e2b6d15b23b1418 webui: apply PatternFly theme on migration pages * b5ebdb604bd2c6edbbd99bbd7f21306cbf367412 webui: remove remnants of jquery-ui * 6b5b9a118522a53bca40532aa2df326d0f7bfe38 webui: remove unused icons * 563dcdc3ebbc11cd979454e75e664767f9ea43f8 webui: remove unused collapsible feature from section * 7e94ee11eb377c8d4ec72e04f618c76f0a30e7a4 webui: remove unused images * 4333161ac36c9487f225d61c79d8ff904f51d629 webui: change absolutely positioned layout to fluid * 0e15a282e85b0e3eb71fd3fce1965646aeb47a27 webui: remove column sizing in tables, use PF styles * 3eaa69a68681a2478a6feeff7fb9e4cf2a27deee webui: change navigation from RCUE to PatternFly * 2e9e5792bc7c5fd1ed65b4d72e3915442db060f5 webui: adjust styles to PatternFly * bcb2ce7f2464281923dd54396fa18d62e48ffebe webui: display undo and multivalued delete buttons in input-group * 216e710188279d15c262da907efbc09be92fb50a webui: allow multiple base section layouts * ad338b9d74fd3aa22bce5680b39fdaae3b90d5ca webui: change breadcrumb to PatternFly * 3dd34d6e55ae5d671158e2fa8f0213072d897036 webui: use h1 in facet title instead of h3 * fc0926ba91f57cb5cd182f2edf50f24d4cfd7432 webui: remove action list widget * c7af2458091ba95eccc26f4468234413e8b016b9 webui: add action dropdown * ec9539d0fde6c368e15c0a07ff75f82adba3f36e webui: add space between action buttons's icon and text * be3aadd06ad2cdc434827e78e5227f34ecf63aa0 webui: remove select action * a98df325b6b0d7bf41509e8c8247a9422f179429 webui: add confirmation to action dropdown actions * 4e1c0ad423b0b78f620b72a07d2c174ec76d4a82 webui: move certificate actions to action dropdown * 2f3dc7908d1c62b729ab38b6d684dc0e942c4528 webui: move user reset password action to action dropdown * faf4fea30fd01ad5f5c372877d0e8fe20963dc91 webui: patternFly dialog * dff5f6319fd76d6b67b30be4eadbcdb414784802 webui: adjust association adder dialog to PatternFly * f631b07507d12d2ab5c1b535a987f09cb07a5565 webui: activity indicators * 21651d9d3f463f5c07355d0f4e52a8d3867d88cc webui: improve pagination * 9c1da611ea94046090dd88d320253d2cded5c76e webui: do not show empty table footer * 54990227824957fb1be4a45ee0f0879812d71d94 webui: restyle automember default group * 4f45e3ea924cd64f4c1f698dfd762d561226199e webui: preload automember default group select list * ea93590ef1051c17fa55115edc14d646581188e4 webui: adjust login page to PatternFly * 74fc85d003af9376462b0610593f6ab8e8a34bf1 webui: use BS alerts in validation_summary_widget * bf9eeb823b5df3e581061b23ee89f3b94b0c87b3 webui-ci: select search table item - chrome issue * 99ed015c0a3ad5f4c1d16190cfa513299ed1cf6c webui: remove old css for standalone pages * 5c3fd4bb832859172fa6e7c739724f6562ccfb7f webui: adjust header controls alignment * 40a25ecf371ebfcbb0801e1f99e3a2853439f44b webui: add search box placeholder text * 408457ce53c553c27f25a682f3f5118ae2e1ab30 webui: change control buttons to normal buttons * 05a917eb17d7c99338dcb972470f15d9d83b37b4 webui: certificate search - select search attribute only when defined * 29f60931e2bee750e5acdf7bead5ed3b21d7e4d5 webui: association adder dialog - change find label to filter * 2df5e0b132be032dc5d12ec65314a44af87b6deb webui: use dark color for facet titles without pkey * 841e0cd3ae904cb8021c4387472b4e66487a5c6a webui-ci: assert_action_list_action * 2af21743df2e09cabcf4d2209cd35786ed3cfdd6 webui: move host action panel actions to action dropdown * 254b41e485e065b870205bb1bc50701451800bff webui: move service action panel actions to action dropdown * dd69557f4e51aa0ab35d82a5c1f67cea20303e70 webui: use normal buttons instead of link buttons in multivalued widget * 0fadb14ec7fe84596058e106a5e8068afed81f51 webui: move radius proxy action panel commands to header actions * bedd128de07f502cdc68d8c7a9f6b8ef48d1727b webui: proper alerts in dialogs * bc6105b270ad10349d12d144b5f67660e7f734e3 webui: use propert alerts in header notification area * dea2da4455b3a4bd189828e2d22f19ab90bf75bd webui: fix search box overlap in mobile mode * 31df435e4194927649fbdacaa3a62fc28b8f5029 webui: fix layout of QR code on wide screens * b0a61ab9530d96a56ff0b10e66a742c18ca90c4a webui: break long text in a code element in a modal > >>> 2. If there's a login error, the logo and the message shifts up. I >>> think it would be nicer to display the error without changing the >>> layout of the original page. > > Snapshots for #2, just in case: > http://edewata.fedorapeople.org/ipa/images/snapshot5.png > http://edewata.fedorapeople.org/ipa/images/snapshot6.png > I'm afraid that it's not easy to solve. We don't know how many and how larger errors or if any there will be. Therefore we can't prepare the right amount of space. Also it would probably look bad. There is bigger related issue. If there are many errors and the height of the screen is small, the logo or some errors can be shifted out of the visible area. Can be reproduced in reset-password form which shows up when password is expired. -- Petr Vobornik From pviktori at redhat.com Tue Jun 10 11:16:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Jun 2014 13:16:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed In-Reply-To: <5396BE2D.2030609@redhat.com> References: <538F4CA1.4070501@redhat.com> <53918C14.2080204@redhat.com> <5395A68B.9090502@redhat.com> <5396BE2D.2030609@redhat.com> Message-ID: <5396E8FD.1020102@redhat.com> On 06/10/2014 10:13 AM, Martin Kosek wrote: > On 06/09/2014 02:20 PM, Petr Viktorin wrote: >> On 06/06/2014 11:38 AM, Martin Kosek wrote: [...] >>> 4) When running user unit tests, I found couple issues: >>> >>> a) Some attributes we may still miss in the permissions: >>> - krbPrincipalExpiration >>> - userclass >>> - ipaUserAuthType >>> - preferredLanguage >>> >>> I am thinking we could base Modify Users permission on the read one and add >>> regular attributes there >> >> I put in userclass and preferredLanguage. >> I'm not sure about the other two; should regular user admins be able to change >> these? > > Good question. I think User Administrators should be able to set > krbPrincipalExpiration or ipaUserAuthType, though it is true it may not be part > of regular "Modify Users" permission and we may want to create more permissions. Simo, does that sound OK? I can't think of a good name. "Manage User authentication"? Note that this can go in a later patch. >>> b) Read membership ACIs for users and groups miss "member" attribute and thus >>> indirect/direct processing goes wrong. >> >> Added. > > 1) Hm, I think was not clear enough. memberOf should not be added to users, as > no object should be "member of user". Please revert this change. I originally > thought it is missing in "Read Group Membership" permissions, but it isn't. > > We are again hitting the problem of a search operation when we are not allowed > to search on all attributes (the CVE fix). This is the search produced by "ipa > user-show fbar": > > [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" > scope=2 > filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" > attrs="" > [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 etime=0 > > It returns zero results, until I also allow memberUser and memberHost: > > # ipa permission-mod 'System: Read Group Membership' > --attrs={member,memberof,memberuid,memberuser,memberhost} > > Now I get the results: > > [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" > scope=2 > filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" > attrs="" > [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 etime=0 > > ipa user-show fbar > ... > Member of groups: ipausers <<<<< > Indirect Member of role: test > ... > > User still cannot see if he is direct or indirect member of role, but this may > not be a problem. > > The easiest approach solution may be to update all "Read * Membership" > permissions/ACIs to always contain member&memberuser&memberhost unless we want > to again produce multiple LDAP searches for checking direct/indirect membership. Ah, now I see what you mean. So: a read permission that includes any of these 3 should include all of them. It would make sense for makeaci to enforce this, so I'll include it in the other patchset. > 2) Installation produces update errors: > > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing > required attribute "objectclass" > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing > required attribute "objectclass" > > Problem is in install/updates/45-roles.update, permissions you converted still > have "member" update here. > > dn: cn=Change a user password,cn=permissions,cn=pbac,$SUFFIX > add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' > > dn: cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX > add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' > > Speaking if which, this privilege also needs to be added to default privileges > of the managed permissions. Thanks for the catch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0570.4-managed-perm-updater-Handle-case-where-we-changed-de.patch Type: text/x-patch Size: 3385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0571.4-Convert-User-default-permissions-to-managed.patch Type: text/x-patch Size: 16033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0572.4-Add-missing-attributes-to-User-managed-permissions.patch Type: text/x-patch Size: 2434 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 10 11:19:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 13:19:54 +0200 Subject: [Freeipa-devel] [PATCH] 0576 Split long docstrings that were recently modified In-Reply-To: <5395FB0D.6090107@redhat.com> References: <5395FB0D.6090107@redhat.com> Message-ID: <5396E9DA.5010509@redhat.com> On 06/09/2014 08:21 PM, Petr Viktorin wrote: > Hello, > Some big plugin module docstrings were modified. This means translators will > need to re-translate the whole string. > To avoid the extra work in the future, I've split the strings we changed since > the last time ipa.pot was regenerated. > > See: > http://www.freeipa.org/page/Coding_Best_Practices#Split_long_translatable_strings > > > Once this is accepted, I'll update Transifex to let people contribute > translations for 4.0. Good idea - fine with me, ACK. Pushed to master: e3b20b9d03f08b889474ef94aef11b31723fdf53 Martin From mkosek at redhat.com Tue Jun 10 11:30:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 13:30:25 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type In-Reply-To: <5396BC3F.4040002@redhat.com> References: <5395F81B.80900@redhat.com> <5396BC3F.4040002@redhat.com> Message-ID: <5396EC51.3060000@redhat.com> On 06/10/2014 10:05 AM, Petr Viktorin wrote: > On 06/09/2014 08:08 PM, Petr Viktorin wrote: >> Having another verification tool should help reviewing the permission >> patches. >> >> >> To avoid conflicts, apply on top of my patches 0568-0570 (Write User >> permissions). >> >> >> 0572: I tried to make the ACIs generated by the permission plugin as >> predictable as possible, but I missed one place it's affected by >> dict/set iteration order (which is undefined). Here's a fix. >> >> 0573: Minor refactoring to make the next patch easier. >> >> 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs >> to do is generate the file; comparing can be done bit-by-bit. >> I do run the validation results through difflib, but frankly it's easier >> just to use Git. > > On my way home yesterday I remembered I left out an important piece of > information - the DN where the ACI is. Attaching updated patch 0574. > >> 0575: Make 'permission' the default bind rule type for managed >> permissions. Rationale in the commit message. >> Run makeaci to verify this doesn't change the result. This will create some additional burden for you when converting ACIs, but the idea is good. The script worked for me, can we just create some more friendly error message than an assertion traceback? # ./makeaci --validate ... Traceback (most recent call last): File "./makeaci", line 116, in main(options) File "./makeaci", line 108, in main raise AssertionError('validation failed') AssertionError: validation failed Martin From mkosek at redhat.com Tue Jun 10 12:02:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 14:02:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0568-0570 Convert User default permissions to managed In-Reply-To: <5396E8FD.1020102@redhat.com> References: <538F4CA1.4070501@redhat.com> <53918C14.2080204@redhat.com> <5395A68B.9090502@redhat.com> <5396BE2D.2030609@redhat.com> <5396E8FD.1020102@redhat.com> Message-ID: <5396F3CB.5080909@redhat.com> On 06/10/2014 01:16 PM, Petr Viktorin wrote: > On 06/10/2014 10:13 AM, Martin Kosek wrote: >> On 06/09/2014 02:20 PM, Petr Viktorin wrote: >>> On 06/06/2014 11:38 AM, Martin Kosek wrote: > [...] >>>> 4) When running user unit tests, I found couple issues: >>>> >>>> a) Some attributes we may still miss in the permissions: >>>> - krbPrincipalExpiration >>>> - userclass >>>> - ipaUserAuthType >>>> - preferredLanguage >>>> >>>> I am thinking we could base Modify Users permission on the read one and add >>>> regular attributes there >>> >>> I put in userclass and preferredLanguage. >>> I'm not sure about the other two; should regular user admins be able to change >>> these? >> >> Good question. I think User Administrators should be able to set >> krbPrincipalExpiration or ipaUserAuthType, though it is true it may not be part >> of regular "Modify Users" permission and we may want to create more permissions. > > Simo, does that sound OK? > I can't think of a good name. "Manage User authentication"? > > Note that this can go in a later patch. > >>>> b) Read membership ACIs for users and groups miss "member" attribute and thus >>>> indirect/direct processing goes wrong. >>> >>> Added. >> >> 1) Hm, I think was not clear enough. memberOf should not be added to users, as >> no object should be "member of user". Please revert this change. I originally >> thought it is missing in "Read Group Membership" permissions, but it isn't. >> >> We are again hitting the problem of a search operation when we are not allowed >> to search on all attributes (the CVE fix). This is the search produced by "ipa >> user-show fbar": >> >> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >> >> attrs="" >> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 >> etime=0 >> >> It returns zero results, until I also allow memberUser and memberHost: >> >> # ipa permission-mod 'System: Read Group Membership' >> --attrs={member,memberof,memberuid,memberuser,memberhost} >> >> Now I get the results: >> >> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >> >> attrs="" >> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 >> etime=0 >> >> ipa user-show fbar >> ... >> Member of groups: ipausers <<<<< >> Indirect Member of role: test >> ... >> >> User still cannot see if he is direct or indirect member of role, but this may >> not be a problem. >> >> The easiest approach solution may be to update all "Read * Membership" >> permissions/ACIs to always contain member&memberuser&memberhost unless we want >> to again produce multiple LDAP searches for checking direct/indirect membership. > > Ah, now I see what you mean. > > So: a read permission that includes any of these 3 should include all of them. > It would make sense for makeaci to enforce this, so I'll include it in the > other patchset. Ok. >> 2) Installation produces update errors: >> >> ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing >> required attribute "objectclass" >> ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing >> required attribute "objectclass" >> >> Problem is in install/updates/45-roles.update, permissions you converted still >> have "member" update here. >> >> dn: cn=Change a user password,cn=permissions,cn=pbac,$SUFFIX >> add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' >> >> dn: cn=Modify Users,cn=permissions,cn=pbac,$SUFFIX >> add:member: 'cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,$SUFFIX' >> >> Speaking if which, this privilege also needs to be added to default privileges >> of the managed permissions. > > Thanks for the catch. I could not find anything else, we can deal with additional fixes in other patches. ACK to all 3 patches, pushed to master: 46faed0b4bb2169fd2be79809b9a65b77a72ee14 Martin From pviktori at redhat.com Tue Jun 10 13:22:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Jun 2014 15:22:05 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type In-Reply-To: <5396EC51.3060000@redhat.com> References: <5395F81B.80900@redhat.com> <5396BC3F.4040002@redhat.com> <5396EC51.3060000@redhat.com> Message-ID: <5397067D.3010005@redhat.com> On 06/10/2014 01:30 PM, Martin Kosek wrote: > On 06/10/2014 10:05 AM, Petr Viktorin wrote: >> On 06/09/2014 08:08 PM, Petr Viktorin wrote: >>> Having another verification tool should help reviewing the permission >>> patches. >>> >>> >>> To avoid conflicts, apply on top of my patches 0568-0570 (Write User >>> permissions). >>> >>> >>> 0572: I tried to make the ACIs generated by the permission plugin as >>> predictable as possible, but I missed one place it's affected by >>> dict/set iteration order (which is undefined). Here's a fix. >>> >>> 0573: Minor refactoring to make the next patch easier. >>> >>> 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs >>> to do is generate the file; comparing can be done bit-by-bit. >>> I do run the validation results through difflib, but frankly it's easier >>> just to use Git. >> >> On my way home yesterday I remembered I left out an important piece of >> information - the DN where the ACI is. Attaching updated patch 0574. >> >>> 0575: Make 'permission' the default bind rule type for managed >>> permissions. Rationale in the commit message. >>> Run makeaci to verify this doesn't change the result. > > This will create some additional burden for you when converting ACIs, but the > idea is good. Any ACI.txt conflicts are easily resolved by running makeaci, and I think the additional verification is worth it. > The script worked for me, can we just create some more friendly error message > than an assertion traceback? > > # ./makeaci --validate > ... > Traceback (most recent call last): > File "./makeaci", line 116, in > main(options) > File "./makeaci", line 108, in main > raise AssertionError('validation failed') > AssertionError: validation failed The tool is meant for developers and packagers; tracebacks are designed to be friendly for this target group. But, OK, I've made it exit() instead, and added some instructions. From the thread on user permissions: On 06/10/2014 10:13 AM, Martin Kosek wrote: > 1) Hm, I think was not clear enough. memberOf should not be added to users, as > no object should be "member of user". Please revert this change. I originally > thought it is missing in "Read Group Membership" permissions, but it isn't. > > We are again hitting the problem of a search operation when we are not allowed > to search on all attributes (the CVE fix). This is the search produced by "ipa > user-show fbar": > > [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" > scope=2 > filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" > attrs="" > [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 etime=0 > > It returns zero results, until I also allow memberUser and memberHost: > > # ipa permission-mod 'System: Read Group Membership' > --attrs={member,memberof,memberuid,memberuser,memberhost} > > Now I get the results: > > [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" > scope=2 > filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" > attrs="" > [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 etime=0 > > ipa user-show fbar > ... > Member of groups: ipausers <<<<< > Indirect Member of role: test > ... > > User still cannot see if he is direct or indirect member of role, but this may > not be a problem. > > The easiest approach solution may be to update all "Read * Membership" > permissions/ACIs to always contain member&memberuser&memberhost unless we want > to again produce multiple LDAP searches for checking direct/indirect membership. I've amended the read permissions for containerish objects, and added a check to makeaci to enforce this in the future. I insist on printing a traceback on error here. This check is meant for developers, tracebacks are perfect for them. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0572.3-permission-plugin-Sort-rights-when-writing-the-ACI.patch Type: text/x-patch Size: 973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0573.3-Add-method-to-enumerate-managed-permission-templates.patch Type: text/x-patch Size: 3373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0574.3-Add-ACI.txt.patch Type: text/x-patch Size: 31216 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0575.3-Make-permission-the-default-bind-type-for-managed-pe.patch Type: text/x-patch Size: 12492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0577.3-Make-sure-member-attrs-are-always-granted-together-i.patch Type: text/x-patch Size: 25145 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 10 14:28:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Jun 2014 16:28:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type In-Reply-To: <5397067D.3010005@redhat.com> References: <5395F81B.80900@redhat.com> <5396BC3F.4040002@redhat.com> <5396EC51.3060000@redhat.com> <5397067D.3010005@redhat.com> Message-ID: <5397161E.5050904@redhat.com> On 06/10/2014 03:22 PM, Petr Viktorin wrote: > On 06/10/2014 01:30 PM, Martin Kosek wrote: >> On 06/10/2014 10:05 AM, Petr Viktorin wrote: >>> On 06/09/2014 08:08 PM, Petr Viktorin wrote: >>>> Having another verification tool should help reviewing the permission >>>> patches. >>>> >>>> >>>> To avoid conflicts, apply on top of my patches 0568-0570 (Write User >>>> permissions). >>>> >>>> >>>> 0572: I tried to make the ACIs generated by the permission plugin as >>>> predictable as possible, but I missed one place it's affected by >>>> dict/set iteration order (which is undefined). Here's a fix. >>>> >>>> 0573: Minor refactoring to make the next patch easier. >>>> >>>> 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs >>>> to do is generate the file; comparing can be done bit-by-bit. >>>> I do run the validation results through difflib, but frankly it's easier >>>> just to use Git. >>> >>> On my way home yesterday I remembered I left out an important piece of >>> information - the DN where the ACI is. Attaching updated patch 0574. >>> >>>> 0575: Make 'permission' the default bind rule type for managed >>>> permissions. Rationale in the commit message. >>>> Run makeaci to verify this doesn't change the result. >> >> This will create some additional burden for you when converting ACIs, but the >> idea is good. > > Any ACI.txt conflicts are easily resolved by running makeaci, and I think the > additional verification is worth it. Yup, I am not complaining :-) >> The script worked for me, can we just create some more friendly error message >> than an assertion traceback? >> >> # ./makeaci --validate >> ... >> Traceback (most recent call last): >> File "./makeaci", line 116, in >> main(options) >> File "./makeaci", line 108, in main >> raise AssertionError('validation failed') >> AssertionError: validation failed > > The tool is meant for developers and packagers; tracebacks are designed to be > friendly for this target group. > > But, OK, I've made it exit() instead, and added some instructions. Ok, thanks. > From the thread on user permissions: > On 06/10/2014 10:13 AM, Martin Kosek wrote: >> 1) Hm, I think was not clear enough. memberOf should not be added to users, as >> no object should be "member of user". Please revert this change. I originally >> thought it is missing in "Read Group Membership" permissions, but it isn't. >> >> We are again hitting the problem of a search operation when we are not allowed >> to search on all attributes (the CVE fix). This is the search produced by "ipa >> user-show fbar": >> >> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >> >> attrs="" >> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 >> etime=0 >> >> It returns zero results, until I also allow memberUser and memberHost: >> >> # ipa permission-mod 'System: Read Group Membership' >> --attrs={member,memberof,memberuid,memberuser,memberhost} >> >> Now I get the results: >> >> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" >> scope=2 >> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >> >> attrs="" >> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 >> etime=0 >> >> ipa user-show fbar >> ... >> Member of groups: ipausers <<<<< >> Indirect Member of role: test >> ... >> >> User still cannot see if he is direct or indirect member of role, but this may >> not be a problem. >> >> The easiest approach solution may be to update all "Read * Membership" >> permissions/ACIs to always contain member&memberuser&memberhost unless we want >> to again produce multiple LDAP searches for checking direct/indirect membership. > > I've amended the read permissions for containerish objects, and added a check > to makeaci to enforce this in the future. > > I insist on printing a traceback on error here. This check is meant for > developers, tracebacks are perfect for them. > If you insist, I can live with that. As you said, it is for packagers and developers after all. ACK to the whole patch set. Martin From mbasti at redhat.com Tue Jun 10 14:33:03 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Jun 2014 16:33:03 +0200 Subject: [Freeipa-devel] [PATCH 0065] Regression fix in host.py Message-ID: <1402410783.2273.4.camel@unused-4-145.brq.redhat.com> DNS requires absolute zone name, host must provide it. IDNA patch caused this. Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0065-Make-zonenames-absolute-in-host-plugin.patch Type: text/x-patch Size: 1603 bytes Desc: not available URL: From jcholast at redhat.com Tue Jun 10 14:45:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Jun 2014 16:45:42 +0200 Subject: [Freeipa-devel] [PATCHES] Update plugins to use Registry API In-Reply-To: <1402079627.4323.42.camel@ipa.example.com> References: <1402079627.4323.42.camel@ipa.example.com> Message-ID: <53971A16.9050702@redhat.com> Hi, On 6.6.2014 20:33, Nathaniel McCallum wrote: > I kept seeing the old plugin registration style when writing/reviewing > code and I decided to fix it. Attached are patches to update the > remaining 31 plugins from the old plugin registration style to the new > style. > > This would be a great starting point for someone new to doing reviews. > > Nathaniel I can't imagine a situation in which having these in separate commits would be beneficial, so I don't think this really deserves to be split among multiple patches. Honza -- Jan Cholasta From pviktori at redhat.com Tue Jun 10 15:07:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Jun 2014 17:07:33 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <5396BE1C.8000000@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> Message-ID: <53971F35.5090006@redhat.com> On 06/10/2014 10:13 AM, Tomas Babej wrote: > Thank you for the detailed review. Responses to all the issues found are > inline: I'm calling it a day now, but here are initial comments from reading the patches. > On 06/06/2014 01:04 PM, Petr Viktorin wrote: >> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>> Hi, >>>> >>>> the following set of patches implements the ticket: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4052 >>>> [...] >>> >>> 0202: OK >>> 0203: >>> >>> It would be nice to have the Services' __init__s take an optional `api` >>> argument, and then use `self.api` everywhere. I'm certain we'd >>> appreciate it in the future. >>> > > Added. Nice! Just one more thing. I don't think it's good practice to pass additional *args to superclasses, unless it's really some sequence of items. In this case you should use always name the arguments to prevent surprises, so **kwargs is enough. >>> 0204: >>> When commenting what a function does, use a docstring. >>> > Will be documented in a later patch. You mean an upcoming patchset, right? >>> 0205: OK >>> 0206: OK >>> 0207: OK >>> 0208: >>> check_selinux_status, in the RuntimeError message, assumes that it's >>> called from an installation. This should at least be pointed out in the >>> docstring. >>> 0209: >>> ipa-client-install, --noac help: "Red Hat" has two words. Also it's a >>> company; I don't think "Red Hat based distributions" is a correct use of >>> the trademark. In comments/class names it doesn't really matter but in >>> user-facing text we should try to be professional. >>> We can either go with "Fedora-based" here and sort this out in a RHEL >>> patch if needed, or better, adjust the help text (or visibility of the >>> option) based on if the platform uses authconfig. >>> > I'm thinking we could go as far as to provide a way in the installers to > define > platform dependent options. What do you think? See Martin's mail. This patchset is already too long for a general solution here. You could file a ticket for a better fix so it's not forgotten. >>> base.tasks: These need docstrings. Will those included in the >>> documentation that you want to provide later? 0210: OK 0211: OK 0212: OK 0213: OK 0214: OK 0215: You could rename the commit now 0216: [...] > As we discussed, to avoid cyclical imports, separate modules for paths > and tasks are needed. > Calling the paths_namespace object by its descriptive name is rather > cumbersome, so I changed that to: > > from ipaplatform.paths import paths > from ipaplatform.tasks import tasks OK I looked over the paths again, and saw this: SLAPD_INSTANCE_CONFIG = "/etc/dirsrv/slapd-" ETC_DIRSRV_SLAPD_INSTANCE = "/etc/dirsrv/slapd-%s" SLAPD_INSTANCE_CONFIG should be removed. ETC_PKI_TOMCAT_ALIAS = "/etc/pki/pki-tomcat/alias" PKI_TOMCAT_ALIAS_DIR = "/etc/pki/pki-tomcat/alias/" We only need one of these. >> ipatests/test_xmlrpc/test_automount_plugin.py: this change is unnecessary I was talking about this one: - keyname = u'/home' + keyname = u'/home/' It's not only unnecessary, it also breaks a test. 0217: OK 0218: OK 0219: Ok 0220: OK 0221: OK 0222: OK -- Petr? From npmccallum at redhat.com Tue Jun 10 15:29:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 10 Jun 2014 11:29:11 -0400 Subject: [Freeipa-devel] [PATCHES] Update plugins to use Registry API In-Reply-To: <53971A16.9050702@redhat.com> References: <1402079627.4323.42.camel@ipa.example.com> <53971A16.9050702@redhat.com> Message-ID: <1402414151.14226.0.camel@ipa.example.com> On Tue, 2014-06-10 at 16:45 +0200, Jan Cholasta wrote: > Hi, > > On 6.6.2014 20:33, Nathaniel McCallum wrote: > > I kept seeing the old plugin registration style when writing/reviewing > > code and I decided to fix it. Attached are patches to update the > > remaining 31 plugins from the old plugin registration style to the new > > style. > > > > This would be a great starting point for someone new to doing reviews. > > > > Nathaniel > > I can't imagine a situation in which having these in separate commits > would be beneficial, so I don't think this really deserves to be split > among multiple patches. My thought was to make it easier to review in small chunks for new reviewers. But if we want to do it as a single patch, one is attached. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-all-remaining-plugins-to-the-new-Registry-API.patch Type: text/x-patch Size: 86787 bytes Desc: not available URL: From npmccallum at redhat.com Tue Jun 10 15:38:37 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 10 Jun 2014 11:38:37 -0400 Subject: [Freeipa-devel] [PATCH 0065] Regression fix in host.py In-Reply-To: <1402410783.2273.4.camel@unused-4-145.brq.redhat.com> References: <1402410783.2273.4.camel@unused-4-145.brq.redhat.com> Message-ID: <1402414717.14226.1.camel@ipa.example.com> On Tue, 2014-06-10 at 16:33 +0200, Martin Basti wrote: > DNS requires absolute zone name, host must provide it. > IDNA patch caused this. > > Patch attached. ACK From simo at redhat.com Tue Jun 10 16:02:29 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Jun 2014 12:02:29 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402364985.9938.45.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> Message-ID: <1402416149.9430.70.camel@willson.usersys.redhat.com> On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > > Simo Sorce wrote: > > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > > tested all cases. > > > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > > default behavior. > > > > > > > > > > > > In particular, the current patch set would require us to make > > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > > admin or host itself) in order to allow it to get back the actual > > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > > still all is needed to allow someone to change it. > > > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > > particular I think we should allow either permission indipendently, and > > > > > > it should be something an admin can change. However I do not like > > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > > access to the master key nobody can really make sense of actually > > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > > can be successfully decrypted. > > > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > > via LDAP (except via extended operations) and instead use another method > > > > > > to determine access patterns. > > > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > > > 0001 > > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > > is ok (either because there is no sdn or because there is no be). It > > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > > > Instead of adding complex explanations I immediately return with an > > > > error if get_realm_backend() returns NULL. > > > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > > as is. > > > > > > There appear to be indiscriminate tab indents throughout the patch. > > > Please changes these to spaces. > > > > There are because the coed is old, I do not change the style of a piece > > of code if we are just changing a few lines. > > You need to read the patch in the context of the code to seen it. > > If it were just the problem you alluded to, I wouldn't have called it > out. I'm referring to tabs in the middle of new code that uses spaces. > This is most likely the result of copy/paste. Either write all the new > code to use tabs or match the copy/pasted lines to the surrounding new > code (my preference). > > > > > > 0002 > > > > > > > > > > ACK > > > > > > One small nitpick, then I too say ACK. In the commit message, the second > > > sentence doesn't need a line break. > > > > I try to keep comments within 72 chars (though sometimes I forget and go > > past till 80), which is why there is a line break there. > > Yeah, it just looks bad when sent over email, which is why I noticed it. > > > > > > 0003 > > > > > > Same as patch 002: unnecessary line breaks in the commit message. > > > > See above. > > > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > > could be broken out into functions and would make it much more readable. > > > > That has already been done :-) > > You should see the original ipa_setkeytab() ... > > I'm not talking about ipapwd_setkeytab(). I'm talking about > ipapwd_getkeytab(). This is entirely new code. There are very clear > spots where it could be broken up. I consider this the biggest issue in > this set of patches for two important reasons: > 1. It makes the function really hard to review. > 2. It is one of the most security/policy sensitive part of the code. > > These two are a bad combo. > > > > Nearly forty lines of variable declarations is a bit much. :) You could > > > break apart BER encoding/decoding, key writing, etc. > > > > Perhaps, but wouldn't change the amount of code, unless you say it is > > necessary in order to do a better review I will skip doing that for now. > > See above. > > > > The ipapwd_getkeytab() function variable declarations contain a mix of > > > camel case and underscore styles. > > > > Inherited from old code, see ipa_setkeytab() > > Sure, but it is also a brand new section. Doesn't your editor have a > variable renamer? Mine does. ;) > > > > The comment containing the ASN.1 code contains invalid syntax. > > > > Please be more specific ? > > That pseudo code is not meant to be compiled, so it is a bit liberal. > > ::= is, I think, the only issue. > > > > I find code like this very hard to read: > > > if (rtag == (ctag | 2)) { > > > Some named constants would be helpful here, or maybe a descriptively > > > named macro function. > > > We have C99 now, so I'd prefer local scope iterators in for loops: > > > for (int i = 0; ...) -- rather than -- for (i = 0; ...) > > > > We still declare everything upfront in freeipa code, not going to change > > style with these patches. > > All of the OTP code *in this same exact plugin* uses the new style. I > consider us to have migrated at least in this portion of the code. > > > > This has inconsistent indents: > > > + svals = ipapwd_encrypt_encode_key(krbcfg, &data, > > > + kenctypes ? num_kenctypes : > > > + krbcfg->num_pref_encsalts, > > > + kenctypes ? kenctypes : > > > + krbcfg->pref_encsalts, > > > + &errMesg); > > > > Yes these indents are not the best but allow to keep the code within 80 > > chars. > > I'm not worried about the problem with keeping them under 80 lines. No > problem there. The problem is that the lines are inconsistently > indented. They should be the same (compare the two lines that start with > "krbcfg->"). > > > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > > > if (getnew == 0) > > > > > > > > > > preferred over just > > > > > > > > > > if (getnew)? > > > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > > reason in the future ? :) > > > > > > I agree with rcrit. Fix this. :) > > > > Fixing how ? There is nothing wrong with this code, note that if > > (getnew) would require to change the order of the 2 blocks and I wanted > > the short one first intentionally, so I would have to use if (!getnew), > > is this ok ? > > That is how I would write it. > > > > > > 0004 > > > > > > More occasional indentation issues (tab vs space). > > > > > > Local loop iterators preferred (for example: get_control_data()). > > > > be more specific please. > > for (int i = 0; ...) > > > > I'm not a fan of the output variable name for ipa_ldap_bind(). > > > > That's a convention we use both in freeipa and sssd code. > > I haven't seen that before. But I'll take your word on it. > > > > Other than that, pretty close to ACK on this one. > > > > > > > > 0005 > > > > > > Unnecessary line breaks in git commit message. > > > > As above > > > > > ASN.1 syntax errors. Also, this comment has some rogue tab indents. > > > > I'l fix the ::= issues, anything else ? > > I think that is it. > > > > In ldap_get_keytab(), can't the big while loop be a for loop with a > > > local scope iterator? Same with the for loop in > > > ipa_string_to_enctypes(). > > > > No, we never use local scope iterators in freeipa code, I do not see why > > we should introduce that now. > > Again, we have started using them in this plugin. > > > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > > match the tab indents of the surrounding code. > > > > ah nice catch > > Nathaniel > I should have addressed all concerns, and the patchset compiles, but I haven't tested it yet (should be able to in the aft if my master server survives an upgrade). Let me know if there are any more concerns wrt style (or substance :). Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 17056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 29028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11261 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jun 10 17:11:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 10 Jun 2014 19:11:21 +0200 Subject: [Freeipa-devel] [PATCHES] Update plugins to use Registry API In-Reply-To: <1402414151.14226.0.camel@ipa.example.com> References: <1402079627.4323.42.camel@ipa.example.com> <53971A16.9050702@redhat.com> <1402414151.14226.0.camel@ipa.example.com> Message-ID: <53973C39.6090200@redhat.com> On 10.6.2014 17:29, Nathaniel McCallum wrote: > On Tue, 2014-06-10 at 16:45 +0200, Jan Cholasta wrote: >> Hi, >> >> On 6.6.2014 20:33, Nathaniel McCallum wrote: >>> I kept seeing the old plugin registration style when writing/reviewing >>> code and I decided to fix it. Attached are patches to update the >>> remaining 31 plugins from the old plugin registration style to the new >>> style. >>> >>> This would be a great starting point for someone new to doing reviews. >>> >>> Nathaniel >> >> I can't imagine a situation in which having these in separate commits >> would be beneficial, so I don't think this really deserves to be split >> among multiple patches. > > My thought was to make it easier to review in small chunks for new > reviewers. But if we want to do it as a single patch, one is attached. > > Nathaniel > ACK btw it was easier to review the batch at once. should we also update the tutorial in ipalib/__init__.py and other comments? Note that there is quite a lot of `api.register(cls)` calls outside of ipalib/plugins dir. IMHO it's OK since it's not a subject of this patch. -- Petr Vobornik From npmccallum at redhat.com Tue Jun 10 18:27:43 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 10 Jun 2014 14:27:43 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402416149.9430.70.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> Message-ID: <1402424863.14226.21.camel@ipa.example.com> On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: > On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > > On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > > > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > > > Simo Sorce wrote: > > > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > > > tested all cases. > > > > > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > > > default behavior. > > > > > > > > > > > > > > In particular, the current patch set would require us to make > > > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > > > admin or host itself) in order to allow it to get back the actual > > > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > > > still all is needed to allow someone to change it. > > > > > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > > > particular I think we should allow either permission indipendently, and > > > > > > > it should be something an admin can change. However I do not like > > > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > > > access to the master key nobody can really make sense of actually > > > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > > > can be successfully decrypted. > > > > > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > > > via LDAP (except via extended operations) and instead use another method > > > > > > > to determine access patterns. > > > > > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > > > > > 0001 > > > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > > > is ok (either because there is no sdn or because there is no be). It > > > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > > > > > Instead of adding complex explanations I immediately return with an > > > > > error if get_realm_backend() returns NULL. > > > > > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > > > as is. > > > > > > > > There appear to be indiscriminate tab indents throughout the patch. > > > > Please changes these to spaces. > > > > > > There are because the coed is old, I do not change the style of a piece > > > of code if we are just changing a few lines. > > > You need to read the patch in the context of the code to seen it. > > > > If it were just the problem you alluded to, I wouldn't have called it > > out. I'm referring to tabs in the middle of new code that uses spaces. > > This is most likely the result of copy/paste. Either write all the new > > code to use tabs or match the copy/pasted lines to the surrounding new > > code (my preference). Nearly all the new code in ipapwd_setkeytab() uses space indents where the surrounding code uses tab indents. I'm not sure the block comment in is_allowed_to_access_attr() belongs there. Also, a utility function like is_allowed_to_access_attr() would probably be handy in upstream 389ds. I might use this in an upcoming token sync patch. This is not a requirement of ACK'ing the patch. > > > > > > 0002 > > > > > > > > > > > > ACK > > > > > > > > One small nitpick, then I too say ACK. In the commit message, the second > > > > sentence doesn't need a line break. > > > > > > I try to keep comments within 72 chars (though sometimes I forget and go > > > past till 80), which is why there is a line break there. > > > > Yeah, it just looks bad when sent over email, which is why I noticed it. This didn't get fixed. "Add" should follow "patch." on the same line. > > > > > > 0003 > > > > > > > > Same as patch 002: unnecessary line breaks in the commit message. > > > > > > See above. Also not fixed. "The new set of keys" should follow "existing ones." on the same line. > > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > > > could be broken out into functions and would make it much more readable. > > > > > > That has already been done :-) > > > You should see the original ipa_setkeytab() ... > > > > I'm not talking about ipapwd_setkeytab(). I'm talking about > > ipapwd_getkeytab(). This is entirely new code. There are very clear > > spots where it could be broken up. I consider this the biggest issue in > > this set of patches for two important reasons: > > 1. It makes the function really hard to review. > > 2. It is one of the most security/policy sensitive part of the code. > > > > These two are a bad combo. Much better! I was a bit disappointed that decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a single request/response struct, but I'm not going to hold up the review on that nitpick. > > > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > > > > > if (getnew == 0) > > > > > > > > > > > > preferred over just > > > > > > > > > > > > if (getnew)? > > > > > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > > > reason in the future ? :) > > > > > > > > I agree with rcrit. Fix this. :) > > > > > > Fixing how ? There is nothing wrong with this code, note that if > > > (getnew) would require to change the order of the 2 blocks and I wanted > > > the short one first intentionally, so I would have to use if (!getnew), > > > is this ok ? > > > > That is how I would write it. There is one dangling reference to "(getnew == 0)" on line 172. > > > > > > 0004 > > > > > > > > More occasional indentation issues (tab vs space). These still need to be fixed. See line 289 of the patch and following. All the new additions after this line in ldap_set_keytab() are using spaces, but the surrounding code uses tabs. > > > > > > 0005 > > > > > > > > Unnecessary line breaks in git commit message. > > > > > > As above Still needs to be fixed. "The new method" should follow "fails." on the same line. > > > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > > > match the tab indents of the surrounding code. > > > > > > ah nice catch This still needs to be fixed. Also, there is indentation mismatches below this (starting on line 331 and following. Nathaniel From npmccallum at redhat.com Tue Jun 10 20:24:30 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 10 Jun 2014 16:24:30 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402424863.14226.21.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> Message-ID: <1402431870.3564.0.camel@ipa.example.com> On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote: > On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: > > On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > > > On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > > > > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > > > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > > > > Simo Sorce wrote: > > > > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > > > > tested all cases. > > > > > > > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > > > > default behavior. > > > > > > > > > > > > > > > > In particular, the current patch set would require us to make > > > > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > > > > admin or host itself) in order to allow it to get back the actual > > > > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > > > > still all is needed to allow someone to change it. > > > > > > > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > > > > particular I think we should allow either permission indipendently, and > > > > > > > > it should be something an admin can change. However I do not like > > > > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > > > > access to the master key nobody can really make sense of actually > > > > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > > > > can be successfully decrypted. > > > > > > > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > > > > via LDAP (except via extended operations) and instead use another method > > > > > > > > to determine access patterns. > > > > > > > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > > > > > > > 0001 > > > > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > > > > is ok (either because there is no sdn or because there is no be). It > > > > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > > > > > > > Instead of adding complex explanations I immediately return with an > > > > > > error if get_realm_backend() returns NULL. > > > > > > > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > > > > as is. > > > > > > > > > > There appear to be indiscriminate tab indents throughout the patch. > > > > > Please changes these to spaces. > > > > > > > > There are because the coed is old, I do not change the style of a piece > > > > of code if we are just changing a few lines. > > > > You need to read the patch in the context of the code to seen it. > > > > > > If it were just the problem you alluded to, I wouldn't have called it > > > out. I'm referring to tabs in the middle of new code that uses spaces. > > > This is most likely the result of copy/paste. Either write all the new > > > code to use tabs or match the copy/pasted lines to the surrounding new > > > code (my preference). > > Nearly all the new code in ipapwd_setkeytab() uses space indents where > the surrounding code uses tab indents. > > I'm not sure the block comment in is_allowed_to_access_attr() belongs > there. > > Also, a utility function like is_allowed_to_access_attr() would probably > be handy in upstream 389ds. I might use this in an upcoming token sync > patch. This is not a requirement of ACK'ing the patch. > > > > > > > > 0002 > > > > > > > > > > > > > > ACK > > > > > > > > > > One small nitpick, then I too say ACK. In the commit message, the second > > > > > sentence doesn't need a line break. > > > > > > > > I try to keep comments within 72 chars (though sometimes I forget and go > > > > past till 80), which is why there is a line break there. > > > > > > Yeah, it just looks bad when sent over email, which is why I noticed it. > > This didn't get fixed. "Add" should follow "patch." on the same line. > > > > > > > > 0003 > > > > > > > > > > Same as patch 002: unnecessary line breaks in the commit message. > > > > > > > > See above. > > Also not fixed. "The new set of keys" should follow "existing ones." on > the same line. > > > > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > > > > could be broken out into functions and would make it much more readable. > > > > > > > > That has already been done :-) > > > > You should see the original ipa_setkeytab() ... > > > > > > I'm not talking about ipapwd_setkeytab(). I'm talking about > > > ipapwd_getkeytab(). This is entirely new code. There are very clear > > > spots where it could be broken up. I consider this the biggest issue in > > > this set of patches for two important reasons: > > > 1. It makes the function really hard to review. > > > 2. It is one of the most security/policy sensitive part of the code. > > > > > > These two are a bad combo. > > Much better! I was a bit disappointed that > decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a > single request/response struct, but I'm not going to hold up the review > on that nitpick. > > > > > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > > > > > > > if (getnew == 0) > > > > > > > > > > > > > > preferred over just > > > > > > > > > > > > > > if (getnew)? > > > > > > > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > > > > reason in the future ? :) > > > > > > > > > > I agree with rcrit. Fix this. :) > > > > > > > > Fixing how ? There is nothing wrong with this code, note that if > > > > (getnew) would require to change the order of the 2 blocks and I wanted > > > > the short one first intentionally, so I would have to use if (!getnew), > > > > is this ok ? > > > > > > That is how I would write it. > > There is one dangling reference to "(getnew == 0)" on line 172. > > > > > > > > 0004 > > > > > > > > > > More occasional indentation issues (tab vs space). > > These still need to be fixed. See line 289 of the patch and following. > All the new additions after this line in ldap_set_keytab() are using > spaces, but the surrounding code uses tabs. > > > > > > > > 0005 > > > > > > > > > > Unnecessary line breaks in git commit message. > > > > > > > > As above > > Still needs to be fixed. "The new method" should follow "fails." on the > same line. > > > > > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > > > > match the tab indents of the surrounding code. > > > > > > > > ah nice catch > > This still needs to be fixed. Also, there is indentation mismatches > below this (starting on line 331 and following. Also, this doesn't compile because of: + while (int i = 0; rtag == LBER_SEQUENCE; i++) { Nathaniel From edewata at redhat.com Tue Jun 10 21:10:18 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jun 2014 16:10:18 -0500 Subject: [Freeipa-devel] [PATCH] 591 webui: add idnsSecInlineSigning option to DNS zone details facet In-Reply-To: <5360D05D.6090506@redhat.com> References: <5360D05D.6090506@redhat.com> Message-ID: <5397743A.30006@redhat.com> On 4/30/2014 5:28 AM, Petr Vobornik wrote: > Web UI part of pviktori-543 > > https://fedorahosted.org/freeipa/ticket/3801 ACK. -- Endi S. Dewata From edewata at redhat.com Tue Jun 10 21:10:26 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jun 2014 16:10:26 -0500 Subject: [Freeipa-devel] [PATCH] 631 webui: fix regression: enabled gid field on group add In-Reply-To: <5373809B.707@redhat.com> References: <5373809B.707@redhat.com> Message-ID: <53977442.7000803@redhat.com> On 5/14/2014 9:41 AM, Petr Vobornik wrote: > GID field should be enabled by default since the default group is posix. > > Was caused by option_widget_base not properly reporting value change while > selecting the default value. It has to be notified with delay otherwise the > event is consumed by FieldBinder. > > https://fedorahosted.org/freeipa/ticket/4325 ACK. -- Endi S. Dewata From edewata at redhat.com Tue Jun 10 21:10:55 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jun 2014 16:10:55 -0500 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <5374C821.60004@redhat.com> References: <5374C821.60004@redhat.com> Message-ID: <5397745F.3060100@redhat.com> On 5/15/2014 8:58 AM, Petr Vobornik wrote: > Just an idea: > > there is only one top level item in self service menu -> no point of > having this level. > > This patch replaces top level with second menu level > > original: > * http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png > new: > * http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png ACK. Some unrelated issues: 1. If I recall correctly, a new user is required to change the password upon the initial login. This can be done with kinit, but can this be done via UI too? Right now a new user will get a login error without any message or link to reset the password. 2. When I logged in to the self-service mode, I got the following error: http://edewata.fedorapeople.org/ipa/images/snapshot7.png 3. In the login screen if the page is shorter than a certain height, there will be a blank area appearing at the bottom. The background doesn't extend all the way to the bottom: http://edewata.fedorapeople.org/ipa/images/snapshot8.png -- Endi S. Dewata From edewata at redhat.com Tue Jun 10 21:11:56 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jun 2014 16:11:56 -0500 Subject: [Freeipa-devel] [PATCH] 645 webui: display only dialogs which belong to current facet In-Reply-To: <53874F09.6040307@redhat.com> References: <53846DB7.40403@redhat.com> <53874F09.6040307@redhat.com> Message-ID: <5397749C.40507@redhat.com> On 5/29/2014 10:15 AM, Petr Vobornik wrote: > On 27.5.2014 12:49, Petr Vobornik wrote: >> Dialog instances no longer directly call IPA.opened_dialog methods. It's >> handled through events (decoupled from dialog's POV). IPA.open_dialogs >> with assistance of ApplicationController makes sure that there is only >> one dialog opened at the same time. >> >> It also makes sure to hide all dialogs, which are not global dialogs and >> did not originate from current facet, when switching facets. >> >> https://fedorahosted.org/freeipa/ticket/4348 >> > > Attaching rebased version (on top of latest PatternFly patch set). ACK, but see comments below: 1. Let's say I had a dialog open and I clicked the button to execute the operation but the session expired so I'd get a login screen. Once I relogged in, the operation was executed immediately without a chance to review the operation. I think it's safer to require the user to reclick the button (i.e. the UI ignores the user action that happens while the session expired). 2. Can this expression !facet || (facet && dialog.facet === facet) be simplified into this? !facet || dialog.facet === facet 3. Unrelated. In self-service user page the action menus for Disable, Delete, and Rebuild auto membership are enabled although the user doesn't have the rights to execute those actions. -- Endi S. Dewata From edewata at redhat.com Tue Jun 10 21:12:01 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 10 Jun 2014 16:12:01 -0500 Subject: [Freeipa-devel] [PATCH] 646 webui: handle back button when unauthenticated In-Reply-To: <53846DDF.2070808@redhat.com> References: <53846DDF.2070808@redhat.com> Message-ID: <539774A1.20002@redhat.com> On 5/27/2014 5:50 AM, Petr Vobornik wrote: > using browser history when unauthenticated causes transition to > the original and/or preceding facets. But nothing works since > all commands fail due to expired credentials in session. > > These changes make sure that user stays on login screen if he misses > valid session credentials while he wants to switch to facet which > requires authentication. > > https://fedorahosted.org/freeipa/ticket/4353 ACK. -- Endi S. Dewata From simo at redhat.com Tue Jun 10 21:20:17 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Jun 2014 17:20:17 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402431870.3564.0.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402431870.3564.0.camel@ipa.example.com> Message-ID: <1402435217.29921.4.camel@willson.usersys.redhat.com> On Tue, 2014-06-10 at 16:24 -0400, Nathaniel McCallum wrote: > On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote: > > On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: > > > On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > > > > On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > > > > > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > > > > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > > > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > > > > > Simo Sorce wrote: > > > > > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > > > > > tested all cases. > > > > > > > > > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > > > > > default behavior. > > > > > > > > > > > > > > > > > > In particular, the current patch set would require us to make > > > > > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > > > > > admin or host itself) in order to allow it to get back the actual > > > > > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > > > > > still all is needed to allow someone to change it. > > > > > > > > > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > > > > > particular I think we should allow either permission indipendently, and > > > > > > > > > it should be something an admin can change. However I do not like > > > > > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > > > > > access to the master key nobody can really make sense of actually > > > > > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > > > > > can be successfully decrypted. > > > > > > > > > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > > > > > via LDAP (except via extended operations) and instead use another method > > > > > > > > > to determine access patterns. > > > > > > > > > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > > > > > > > > > 0001 > > > > > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > > > > > is ok (either because there is no sdn or because there is no be). It > > > > > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > > > > > > > > > Instead of adding complex explanations I immediately return with an > > > > > > > error if get_realm_backend() returns NULL. > > > > > > > > > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > > > > > as is. > > > > > > > > > > > > There appear to be indiscriminate tab indents throughout the patch. > > > > > > Please changes these to spaces. > > > > > > > > > > There are because the coed is old, I do not change the style of a piece > > > > > of code if we are just changing a few lines. > > > > > You need to read the patch in the context of the code to seen it. > > > > > > > > If it were just the problem you alluded to, I wouldn't have called it > > > > out. I'm referring to tabs in the middle of new code that uses spaces. > > > > This is most likely the result of copy/paste. Either write all the new > > > > code to use tabs or match the copy/pasted lines to the surrounding new > > > > code (my preference). > > > > Nearly all the new code in ipapwd_setkeytab() uses space indents where > > the surrounding code uses tab indents. > > > > I'm not sure the block comment in is_allowed_to_access_attr() belongs > > there. > > > > Also, a utility function like is_allowed_to_access_attr() would probably > > be handy in upstream 389ds. I might use this in an upcoming token sync > > patch. This is not a requirement of ACK'ing the patch. > > > > > > > > > > 0002 > > > > > > > > > > > > > > > > ACK > > > > > > > > > > > > One small nitpick, then I too say ACK. In the commit message, the second > > > > > > sentence doesn't need a line break. > > > > > > > > > > I try to keep comments within 72 chars (though sometimes I forget and go > > > > > past till 80), which is why there is a line break there. > > > > > > > > Yeah, it just looks bad when sent over email, which is why I noticed it. > > > > This didn't get fixed. "Add" should follow "patch." on the same line. > > > > > > > > > > 0003 > > > > > > > > > > > > Same as patch 002: unnecessary line breaks in the commit message. > > > > > > > > > > See above. > > > > Also not fixed. "The new set of keys" should follow "existing ones." on > > the same line. > > > > > > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > > > > > could be broken out into functions and would make it much more readable. > > > > > > > > > > That has already been done :-) > > > > > You should see the original ipa_setkeytab() ... > > > > > > > > I'm not talking about ipapwd_setkeytab(). I'm talking about > > > > ipapwd_getkeytab(). This is entirely new code. There are very clear > > > > spots where it could be broken up. I consider this the biggest issue in > > > > this set of patches for two important reasons: > > > > 1. It makes the function really hard to review. > > > > 2. It is one of the most security/policy sensitive part of the code. > > > > > > > > These two are a bad combo. > > > > Much better! I was a bit disappointed that > > decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a > > single request/response struct, but I'm not going to hold up the review > > on that nitpick. > > > > > > > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > > > > > > > > > if (getnew == 0) > > > > > > > > > > > > > > > > preferred over just > > > > > > > > > > > > > > > > if (getnew)? > > > > > > > > > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > > > > > reason in the future ? :) > > > > > > > > > > > > I agree with rcrit. Fix this. :) > > > > > > > > > > Fixing how ? There is nothing wrong with this code, note that if > > > > > (getnew) would require to change the order of the 2 blocks and I wanted > > > > > the short one first intentionally, so I would have to use if (!getnew), > > > > > is this ok ? > > > > > > > > That is how I would write it. > > > > There is one dangling reference to "(getnew == 0)" on line 172. > > > > > > > > > > 0004 > > > > > > > > > > > > More occasional indentation issues (tab vs space). > > > > These still need to be fixed. See line 289 of the patch and following. > > All the new additions after this line in ldap_set_keytab() are using > > spaces, but the surrounding code uses tabs. > > > > > > > > > > 0005 > > > > > > > > > > > > Unnecessary line breaks in git commit message. > > > > > > > > > > As above > > > > Still needs to be fixed. "The new method" should follow "fails." on the > > same line. > > > > > > > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > > > > > match the tab indents of the surrounding code. > > > > > > > > > > ah nice catch > > > > This still needs to be fixed. Also, there is indentation mismatches > > below this (starting on line 331 and following. > > Also, this doesn't compile because of: > + while (int i = 0; rtag == LBER_SEQUENCE; i++) { Uhmm this is odd, I wonder why my make step didn't catch this ... I'll make sure the next batch doesn't fail to compile at least, sorry about that. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 00:13:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Jun 2014 20:13:02 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402424863.14226.21.camel@ipa.example.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> Message-ID: <1402445582.29921.7.camel@willson.usersys.redhat.com> On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote: > On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: > > On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > > > On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > > > > On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > > > > > On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > > > > > > On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > > > > > > > Simo Sorce wrote: > > > > > > > > This patch set is an initial implementation of ticket #3859 > > > > > > > > > > > > > > > > It seem to be working fine in my initial testing but I have not yet > > > > > > > > tested all cases. > > > > > > > > > > > > > > > > However I wonted to throw it on the list to get some initial feedback > > > > > > > > about the choices I made wrt access control and ipa-getkeytab flags and > > > > > > > > default behavior. > > > > > > > > > > > > > > > > In particular, the current patch set would require us to make > > > > > > > > host/service keytabs readable by the requesting party (whoever that is, > > > > > > > > admin or host itself) in order to allow it to get back the actual > > > > > > > > keytab. I am not sure this is ideal. Also write access to the keytab is > > > > > > > > still all is needed to allow someone to change it. > > > > > > > > > > > > > > > > Neither is ideal, but it was simpler as a first implementation. In > > > > > > > > particular I think we should allow either permission indipendently, and > > > > > > > > it should be something an admin can change. However I do not like > > > > > > > > allowing normal writes or reads to these attributes, mostly because w/o > > > > > > > > access to the master key nobody can really make sense of actually > > > > > > > > reading out the contents of KrbPrincipalKey or could write a blob that > > > > > > > > can be successfully decrypted. > > > > > > > > > > > > > > > > So I was wondering if we might want to prevent both reading and writing > > > > > > > > via LDAP (except via extended operations) and instead use another method > > > > > > > > to determine access patterns. > > > > > > > > > > > > > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > > > > > > > always falling back to the old one (if a password has been provided) ? > > > > > > > > > > > > > > 0001 > > > > > > > get_realm_backend() should probably have a comment on why returning NULL > > > > > > > is ok (either because there is no sdn or because there is no be). It > > > > > > > appears that things will eventually fail in get_entry_by_principal() > > > > > > > > > > > > Instead of adding complex explanations I immediately return with an > > > > > > error if get_realm_backend() returns NULL. > > > > > > > > > > The logic here is correct, it just reads awkwardly. It is probably fine > > > > > as is. > > > > > > > > > > There appear to be indiscriminate tab indents throughout the patch. > > > > > Please changes these to spaces. > > > > > > > > There are because the coed is old, I do not change the style of a piece > > > > of code if we are just changing a few lines. > > > > You need to read the patch in the context of the code to seen it. > > > > > > If it were just the problem you alluded to, I wouldn't have called it > > > out. I'm referring to tabs in the middle of new code that uses spaces. > > > This is most likely the result of copy/paste. Either write all the new > > > code to use tabs or match the copy/pasted lines to the surrounding new > > > code (my preference). > > Nearly all the new code in ipapwd_setkeytab() uses space indents where > the surrounding code uses tab indents. Yes although it looks a bit ugly a long time ago we decided that we'd move to space indenting for big blocks of code, or keep tab indent only for minor modification. In the hope of eventually converting the remaining tabs. While we are here I decided to split setkeytab along the lines of getkeytab too, HTH. > I'm not sure the block comment in is_allowed_to_access_attr() belongs > there. Uhhmm now that we check an arbitrary attribute I need to change it. > Also, a utility function like is_allowed_to_access_attr() would probably > be handy in upstream 389ds. I might use this in an upcoming token sync > patch. This is not a requirement of ACK'ing the patch. The generic 389ds function is slapi_access_allowed() which is normally sufficient, is_allowed_to_access_attr() is just a wrapper around some additional boilerplate that is not normally needed. Anyway feel free to open a bug in 389ds's trac. > > > > > > > 0002 > > > > > > > > > > > > > > ACK > > > > > > > > > > One small nitpick, then I too say ACK. In the commit message, the second > > > > > sentence doesn't need a line break. > > > > > > > > I try to keep comments within 72 chars (though sometimes I forget and go > > > > past till 80), which is why there is a line break there. > > > > > > Yeah, it just looks bad when sent over email, which is why I noticed it. > > This didn't get fixed. "Add" should follow "patch." on the same line. Well, kind of arbitrary, but ok > > > > > > > 0003 > > > > > > > > > > Same as patch 002: unnecessary line breaks in the commit message. > > > > > > > > See above. > > Also not fixed. "The new set of keys" should follow "existing ones." on > the same line. ok > > > > > I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > > > > > could be broken out into functions and would make it much more readable. > > > > > > > > That has already been done :-) > > > > You should see the original ipa_setkeytab() ... > > > > > > I'm not talking about ipapwd_setkeytab(). I'm talking about > > > ipapwd_getkeytab(). This is entirely new code. There are very clear > > > spots where it could be broken up. I consider this the biggest issue in > > > this set of patches for two important reasons: > > > 1. It makes the function really hard to review. > > > 2. It is one of the most security/policy sensitive part of the code. > > > > > > These two are a bad combo. > > Much better! I was a bit disappointed that > decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a > single request/response struct, but I'm not going to hold up the review > on that nitpick. Good, because I would not use a struct anyway :) > > > > > > > Since getnew is defined as a boolean in the ASN.1, is the conditional > > > > > > > > > > > > > > if (getnew == 0) > > > > > > > > > > > > > > preferred over just > > > > > > > > > > > > > > if (getnew)? > > > > > > > > > > > > Future proof if we want to change it to a non-boolean value for whatever > > > > > > reason in the future ? :) > > > > > > > > > > I agree with rcrit. Fix this. :) > > > > > > > > Fixing how ? There is nothing wrong with this code, note that if > > > > (getnew) would require to change the order of the 2 blocks and I wanted > > > > the short one first intentionally, so I would have to use if (!getnew), > > > > is this ok ? > > > > > > That is how I would write it. > > There is one dangling reference to "(getnew == 0)" on line 172. Nope, there is an intentional reference to it, getnew is an integer type so it gets compared to an integer to get your boolean. > > > > > > > 0004 > > > > > > > > > > More occasional indentation issues (tab vs space). > > These still need to be fixed. See line 289 of the patch and following. > All the new additions after this line in ldap_set_keytab() are using > spaces, but the surrounding code uses tabs. Right, and it is intentional, although ugly to see we want to slowly transition all code to space and 4 chars indent. We just didn't want to arbitrarily mass re-indent and clobber git annotate. So the idea is to slowly convert all isolated blocks when new code is added or a substantial part is changed. > > > > > > > 0005 > > > > > > > > > > Unnecessary line breaks in git commit message. > > > > > > > > As above > > Still needs to be fixed. "The new method" should follow "fails." on the > same line. ok > > > > > Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > > > > > match the tab indents of the surrounding code. > > > > > > > > ah nice catch > > This still needs to be fixed. Also, there is indentation mismatches > below this (starting on line 331 and following. ah forgot about this one, let's see if I got them all this time. Still upgrading my server, so still untested, but again just to catch style issues, I'll post news once I can test the changes do not break functionality. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 36681 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 27330 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From simo at redhat.com Wed Jun 11 00:48:19 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Jun 2014 20:48:19 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master Message-ID: <1402447699.29921.10.camel@willson.usersys.redhat.com> I ma getting a failure to login in the UI The error is somewhere in ldap/schema/subentry.py KeyError: 'ipattokenhotp' A schema update may have failed I guess ? but running ipa-ldap-updater doesn't help ... Ideas ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Wed Jun 11 05:41:46 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Jun 2014 15:41:46 +1000 Subject: [Freeipa-devel] faster ways to build/test dogtag? In-Reply-To: <538466FE.5040500@redhat.com> References: <20140527070045.GA28407@dhcp-40-8.bne.redhat.com> <538466FE.5040500@redhat.com> Message-ID: <20140611054146.GU11349@dhcp-40-8.bne.redhat.com> On Tue, May 27, 2014 at 12:20:46PM +0200, Martin Kosek wrote: > On 05/27/2014 09:00 AM, Fraser Tweedale wrote: > > Hi all, > > > > I've been working on a fix for a profile issue > > (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I > > find the scripts/compose_pki_core_packages -> yum install -> test > > cycle frustratingly slow on idm.lab.bos. Is there a quicker way > > to build and test the software - particularly as part of the larger > > IPA/certmonger/dogtag ecosystem? > > > > Cheers, > > > > Fraser > > I am not sure about dogtag - you would need to ask on pki-devel mailing list. > > As for FreeIPA - I use a home-grown synchronization script that puts modified > python file in my local git directly into my test VM system so I do not need to > compile and install FreeIPA rpms every time. > > Martin I'm compiling an etherpad of all the dev scripts/tools people are using in their workflow (for both IPA and Dogtag). Could you please add link to and summary for your synchronisation script? http://idm.etherpad.corp.redhat.com/dev-tools Cheers, Fraser From mkosek at redhat.com Wed Jun 11 06:44:06 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Jun 2014 08:44:06 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <5396B9E5.4050605@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> Message-ID: <5397FAB6.5040307@redhat.com> On 06/10/2014 09:55 AM, Martin Kosek wrote: > On 06/06/2014 12:50 PM, Jan Cholasta wrote: ... >> Updated patches attached. >> >> Note that you will need python-nss 0.15 in order to test, you can get a RPM for >> Fedora here: . > > John, do you think we could build python-nss 0.15 also for Fedora 20? The fix > incorporated in it is pretty important to warrant bugfix update in bodhi. It > would also allow FreeIPA 4.0 to be installed on Fedora 20. John kindly built python-nss also for Fedora 20: https://admin.fedoraproject.org/updates/python-nss-0.15.0-1.fc20 I did a quick test and parsing SAN still worked fine, so I gave karma. I would like to ask others who test the library to do the same as karma will be required for it to move to stable updates repo. Thanks, Martin From mkosek at redhat.com Wed Jun 11 07:25:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Jun 2014 09:25:20 +0200 Subject: [Freeipa-devel] [PATCHES] Update plugins to use Registry API In-Reply-To: <53973C39.6090200@redhat.com> References: <1402079627.4323.42.camel@ipa.example.com> <53971A16.9050702@redhat.com> <1402414151.14226.0.camel@ipa.example.com> <53973C39.6090200@redhat.com> Message-ID: <53980460.6060409@redhat.com> On 06/10/2014 07:11 PM, Petr Vobornik wrote: > On 10.6.2014 17:29, Nathaniel McCallum wrote: >> On Tue, 2014-06-10 at 16:45 +0200, Jan Cholasta wrote: >>> Hi, >>> >>> On 6.6.2014 20:33, Nathaniel McCallum wrote: >>>> I kept seeing the old plugin registration style when writing/reviewing >>>> code and I decided to fix it. Attached are patches to update the >>>> remaining 31 plugins from the old plugin registration style to the new >>>> style. >>>> >>>> This would be a great starting point for someone new to doing reviews. >>>> >>>> Nathaniel >>> >>> I can't imagine a situation in which having these in separate commits >>> would be beneficial, so I don't think this really deserves to be split >>> among multiple patches. >> >> My thought was to make it easier to review in small chunks for new >> reviewers. But if we want to do it as a single patch, one is attached. >> >> Nathaniel >> > > ACK > > btw it was easier to review the batch at once. > > should we also update the tutorial in ipalib/__init__.py and other comments? > > Note that there is quite a lot of `api.register(cls)` calls outside of > ipalib/plugins dir. IMHO it's OK since it's not a subject of this patch. Pushed to master: 255cbb49763ff579feed935a5a725fc2b272749c Martin From ftweedal at redhat.com Wed Jun 11 08:02:17 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Jun 2014 18:02:17 +1000 Subject: [Freeipa-devel] user certificates Message-ID: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> Hi all, Use cases are emerging for user certificates in FreeIPA. Some include: - VPN certificates. A user logs into an IPA domain. They are not connected to a wired network so a background service (SSSD or other) acquires a short-lived client certificate for connecting to the company VPN (and connects it, thus saving the user some time and hassle). - A DNP3 Smart-Grid user's roles are updated. A new IEC 62351-8 certificate must be signed by the CA and provided to the DNP3 to be sent to outstations on the network. There are other use cases for user certificates, e.g. client authentication for HTTP or other network services. Perhaps you know of others - in which case let us know. Are there any current plans/design documents for implementing user certificates in FreeIPA? Or if I'm way off track in my thinking here, please help me understand how these use cases do or do not apply to FreeIPA :) As a side-note: support for different Dogtag profiles in FreeIPA is prerequisite for this - in fact it is likely that even a single user may need to acquire certificates with different profiles, for the different use cases. Cheers, Fraser From pvoborni at redhat.com Wed Jun 11 08:49:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 10:49:04 +0200 Subject: [Freeipa-devel] [PATCH] 631 webui: fix regression: enabled gid field on group add In-Reply-To: <53977442.7000803@redhat.com> References: <5373809B.707@redhat.com> <53977442.7000803@redhat.com> Message-ID: <53981800.3010400@redhat.com> On 10.6.2014 23:10, Endi Sukma Dewata wrote: > On 5/14/2014 9:41 AM, Petr Vobornik wrote: >> GID field should be enabled by default since the default group is posix. >> >> Was caused by option_widget_base not properly reporting value change >> while >> selecting the default value. It has to be notified with delay >> otherwise the >> event is consumed by FieldBinder. >> >> https://fedorahosted.org/freeipa/ticket/4325 > > ACK. > Pushed to master: e3840eef09f4a6b1ac3c0a92f5929353a6c9e6b6 -- Petr Vobornik From pvoborni at redhat.com Wed Jun 11 08:52:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 10:52:28 +0200 Subject: [Freeipa-devel] [PATCH] 591 webui: add idnsSecInlineSigning option to DNS zone details facet In-Reply-To: <5397743A.30006@redhat.com> References: <5360D05D.6090506@redhat.com> <5397743A.30006@redhat.com> Message-ID: <539818CC.3090009@redhat.com> On 10.6.2014 23:10, Endi Sukma Dewata wrote: > On 4/30/2014 5:28 AM, Petr Vobornik wrote: >> Web UI part of pviktori-543 >> >> https://fedorahosted.org/freeipa/ticket/3801 > > ACK. > Pushed to master: 9c97bbd347b89634a844726c5d1f0ef39df4d139 -- Petr Vobornik From jcholast at redhat.com Wed Jun 11 08:58:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Jun 2014 10:58:45 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <5396B9E5.4050605@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> Message-ID: <53981A45.9090108@redhat.com> On 10.6.2014 09:55, Martin Kosek wrote: > On 06/06/2014 12:50 PM, Jan Cholasta wrote: >> On 23.1.2014 14:34, Jan Cholasta wrote: >>> On 22.1.2014 16:43, Simo Sorce wrote: >>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>> managedby_host >>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>> why that >>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>> original >>>>>>>> check is not right anymore ? >>>>>>> >>>>>>> The original check is wrong, see >>>>>>> . >>>>>>> >>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>> right, but even if it is not, I think we should still check for write >>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>> handled by ACIs. >>>>>> >>>>>> Right, I remembered that comment, but it just says to check the right >>>>>> object's managed-by, here instead you changed it to check if you can >>>>>> write the usercertificate. >>>>>> >>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>> >>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>> Certificates and kerberos keys". >>>>> >>>>> I think the check can be extended to users as well, so that requesting >>>>> certificate with SAN is allowed only to users which have write access to >>>>> the SAN services. >>> >>> I have done the modification, see attached patches. >>> >>>> >>>> Sounds good to me then, thanks for explaining. >>>> >>>> The patches also look good, but I would like someone to give them a try >>>> for a formal ack. >>> >>> OK, thanks. >>> >> >> Bump. >> >> I have added stricter validation of subject alt names as well as certificate >> extensions in general to the second patch. > > Thanks! > >> Updated patches attached. >> >> Note that you will need python-nss 0.15 in order to test, you can get a RPM for >> Fedora here: . > > John, do you think we could build python-nss 0.15 also for Fedora 20? The fix > incorporated in it is pretty important to warrant bugfix update in bodhi. It > would also allow FreeIPA 4.0 to be installed on Fedora 20. > >> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work, >> because . > > This worked for me, I suspect this is a DS bug. More info in the ticket. > > Now back to review of the patch: > > 210.4: looks ok > 234.4: > > 1) Virtual operation "request certificate with subjectaltname" should be a > member of Certificate Administrators privilege OK. > > > 2) I would write "Request Certificate With SubjectAltName" with "with" instead > of "With". I.e.: > Request Certificate with SubjectAltName OK. > > > 3) Why is the extension check only enforced for non-hosts? > > + if not bind_principal.startswith('host/'): > + for ext in extensions: > + operation = self._allowed_extensions.get(ext) > + if operation: > + self.check_access(operation) > > My tricky certmonger request passed: > > # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r > -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com > -E mkosek at redhat.com > > while when I posted the same CSR as privileged user, it was rejected: > > $ klist > Ticket cache: KEYRING:persistent:962000003:962000003 > Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM > > $ ipa cert-request --principal test/`hostname` certmonger.csr > ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden Right, I meant to NACK myself, but you were faster. Fixed. > > > 4) Regular users cannot read Virtual Operations, so even if I assign them a > permission, command is refused: > > $ ipa cert-request --principal test/`hostname` openssl.csr > ipa: ERROR: Insufficient access: No such virtual command > > I think we will need to create new managed permission "Read Virtual Operations" > and assign it to "Certificate Administrators" privilege by default as this > privilege has the virtual operation permissions assigned. Petr3, what is your > take on this? > > Otherwise the patch worked well for me, the authorization part looked OK. My > biggest concern was just the host/user differentiation wrt unknown > subjectaltname types. > > Martin > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.5-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.5-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 14117 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 11 09:08:30 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 11 Jun 2014 11:08:30 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop Message-ID: <53981C8E.6000600@redhat.com> Hi, As due to possible race conditions, the preop.pin might not be written in the CS.cfg at the time installer tries to read it. In case no value for preop.pin was found, retry until timeout was reached. https://fedorahosted.org/freeipa/ticket/3382 (applies on ipa-3-0 branch) -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0224-cainstance-Read-CS.cfg-for-preop.pin-in-a-loop.patch Type: text/x-patch Size: 2892 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 11 09:09:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 11:09:56 +0200 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402447699.29921.10.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> Message-ID: <53981CE4.3050901@redhat.com> On 06/11/2014 02:48 AM, Simo Sorce wrote: > I ma getting a failure to login in the UI > > The error is somewhere in ldap/schema/subentry.py > > KeyError: 'ipattokenhotp' > > A schema update may have failed I guess ? > but running ipa-ldap-updater doesn't help ... > > Ideas ? Do you have the full traceback? -- Petr? From jcholast at redhat.com Wed Jun 11 09:32:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Jun 2014 11:32:25 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1402074277.4323.37.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> <1401309865.4631.5.camel@ipa.example.com> <5390121C.5070402@redhat.com> <1402074277.4323.37.camel@ipa.example.com> Message-ID: <53982229.3010502@redhat.com> On 6.6.2014 19:04, Nathaniel McCallum wrote: > On Thu, 2014-06-05 at 08:45 +0200, Jan Cholasta wrote: >> On 28.5.2014 22:44, Nathaniel McCallum wrote: >>> On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: >>>> On 13.5.2014 19:12, Nathaniel McCallum wrote: >>>>> On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: >>>>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: >>>>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>>>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the >>>>>>>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Admins, as before, have full access to all token permissions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Normal users have read/search/compare access to all of the non-secret >>>>>>>>>>>>>>>> data for tokens assigned to them, whether protected or non-protected. >>>>>>>>>>>>>>>> Users can add or delete non-protected tokens and modify most of their >>>>>>>>>>>>>>>> metadata. However they cannot create, delete or modify protected tokens. >>>>>>>>>>>>>>>> Regardless of whether the token is protected or not, users cannot change >>>>>>>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In contrast, admins can create protected tokens. This protects the token >>>>>>>>>>>>>>>> from deletion or modification when assigned to users. Additionally, when >>>>>>>>>>>>>>>> a user account is deleted, the assigned non-protected tokens are deleted >>>>>>>>>>>>>>>> but the protected tokens are merely orphaned. This permits the token to >>>>>>>>>>>>>>>> be reassigned without having to recreate it. This last point is >>>>>>>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>>>>>>> This new version makes ipatokenDisabled visible for token owners. It is >>>>>>>>>>>>>>> also writable if the token is non-protected. This additionally fixes: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>>>>>>> This new version changes the way the default value of protected is setup >>>>>>>>>>>>>> in accordance with the changes made for the review of my patch 0048.2. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Nathaniel >>>>>>>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>>>>>>> No. Alternate designs are welcome. The code is easy enough to modify. >>>>>>>>>>>> >>>>>>>>>>>>> I did not dig too deep into this, but I think it might be better to >>>>>>>>>>>>> instead use the managedby attribute on a token to limit who can delete >>>>>>>>>>>>> (or administer in other way) the token. On otptoken-add, managedby would >>>>>>>>>>>>> be set to the "whoami" user DN, unless run with --protected, in which >>>>>>>>>>>>> case managedby would be left empty. Then, when deleting a user, the >>>>>>>>>>>>> token would be deleted only if the user manages the token. >>>>>>>>>>>> It seems to me that the mechanics of this are roughly the same as >>>>>>>>>>>> protected, just with a different syntax. The cost of this is more >>>>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses (is >>>>>>>>>>>> this possible?) instead of a simple filter. If there is a clear benefit, >>>>>>>>>>>> we can justify the more obtuse syntax. >>>>>>>>>>> >>>>>>>>>>> We usually try not to create new attributes until it is fully justified. >>>>>>>>>>> I would like Simo to chime in on this. >>>>>>>>>> >>>>>>>>>> I would also prefer to reuse existing attributes and mechanism if >>>>>>>>>> possible and if it will not preclude future work. >>>>>>>>>> >>>>>>>>>> In this case, it "sounds" like managed-by has the appropriate meaning: >>>>>>>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>>>>>>> >>>>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>>>>>>> using managed-by vs a new attribute ? >>>>>>>>> >>>>>>>>> These are the ACIs using the protected mechanism: >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>>> "ipatokenOwner#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = >>>>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>>>> >>>>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version 3.0; >>>>>>>>> acl "Users can create and delete tokens"; allow (add, delete) userattr = >>>>>>>>> "ipatokenOwner#SELFDN";) >>>>>>>>> >>>>>>>>> This is what they look like using managedBy (I have not tested this): >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>>>> userattr = "managedBy#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl "Users can >>>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>>>> "managedBy#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token info"; >>>>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>>>> >>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>>>> "managedBy#USERDN";) >>>>>>>>> >>>>>>>>> aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and >>>>>>>>> userattr = "managedBy#SELFDN";) >>>>>>>>> >>>>>>>>> In short: >>>>>>>>> 1. Owner and manager get read, search and compare. >>>>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>>>> >>>>>>>>> The otptoken-add command should gain the following defaults: >>>>>>>>> 1. The owner defaults to the user adding the token. >>>>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>>>> >>>>>>>>> This means that if neither owner nor managedBy are specified, the >>>>>>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>>>>>> owner is specified, no manager is assumed. >>>>>>>>> >>>>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the above >>>>>>>>> syntax. This will become clear during testing if we want this approach. >>>>>>>>> >>>>>>>>> Does this look sane? >>>>>>>> >>>>>>>> I am not entirely sure your ACI syntax is always right for the second >>>>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for owner >>>>>>>> once for manager). >>>>>>>> >>>>>>>> I think the read ACIs do not need to list managedby ? Do we plan to have >>>>>>>> a manager that is another regular user but not the owner nor an admin ? >>>>>>>> >>>>>>>> In any case I prefer the sytnax that uses managedby, as it has more >>>>>>>> potential. >>>>>>> >>>>>>> Attached is a new version of the patch which implements the feature >>>>>>> using managedBy instead of ipatokenProtected. One important thing needs >>>>>>> to be said about this patch. I am not exposing managedBy in either the >>>>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>>>> expose this similar to owner or as a relationship? >>>>>> >>>>>> I would expose it, as a relationship. (Note that ipatokenowner should >>>>>> ideally be represented as a relationship too, but the framework does not >>>>>> support 1-to-many relationships ATM.) >>>>> >>>>> So since this is a 1-to-many relationship we shouldn't expose it? >>>>> >>>>> Or should I do it like owner is currently done? >>>> >>>> Do it like managedby is done in the host plugin (see >>>> "attribute_members", "relationships", etc.) >>>> >>>>> >>>>>> >>>>>> Just curious, why are the ACIs divided like this: >>>>>> >>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers >>>>>> can read basic token info"; allow (read, search, compare) userattr = >>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >>>>>> details"; allow (read, search, compare) userattr = >>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>> "Users/managers can see HOTP details"; allow (read, search, compare) >>>>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>> >>>>>> IMHO you could make them less complex by dividing them like this: >>>>>> >>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Owner can >>>>>> read token details"; allow (read, search, compare) userattr = >>>>>> "ipatokenOwner#USERDN";) >>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel >>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl "Managers >>>>>> can read token details"; allow (read, search, compare) userattr = >>>>>> "managedBy#USERDN";) >>>>> >>>>> The first set is organized by objectClass. The second by userattr. I >>>>> have no strong opinion on this matter, though performance is probably a >>>>> consideration. Do any DS guys want to chime in? >>>> >>>> I would still like to know someone else's opinion on this, but if >>>> there's none, let's keep it your way. >>>> >>>>> >>>>>> Would it make sense to keep --protected as a flag in otptoken-add as a >>>>>> shortcut for "entry_attrs['managedby'] = None"? >>>>> >>>>> I can't think of a use case for this. The only use case I *can* think of >>>>> is an admin creating a non-protected token for a user. >>>> >>>> OK. >>>> >>>>> >>>>>> Would it make sense to default managedby to the current bind DN in >>>>>> otptoken-add, even if it's not a user DN? (Do we want to allow running >>>>>> otptoken-add by hosts/services/other non-users?) >>>>> >>>>> No idea. Dmitri? >>>> >>>> We can add this later if necessary. >>>> >>>>> >>>>>> Is orphaning a token when a user is deleted only if it is not managed by >>>>>> any other users the intended behavior? It just seems sort of strange to >>>>>> me, since it changes the token from unprotected to protected. >>>>> >>>>> I don't think that is the behavior. We orphan the token if the owner is >>>>> not listed as a manager. If the owner is listed as a manager, we delete >>>>> the token. >>>>> >>>>> Put another way, protected tokens are orphaned and unprotected tokens >>>>> are deleted. >>>>> >>>>> If I didn't implement that, please point out my bug. >>>> >>>> Sorry, my bad, your code is right. You can make it simpler, though: >>>> >>>> orphan = [x for x in token.get('managedby', []) if x == dn] >>>> >>>> (The "len() == 0" check is not necessary and using list comprehensions >>>> makes the code more readable than using filter.) >>> >>> The attached version fixes all the above issues. Two issues that may >>> remain: >>> 1. There is no option to set managedBy during otptoken-add or >>> otptoken-mod. This is probably okay. >> >> Yes. I guess this bit is not needed anymore: >> >> # If owner was not specified, default to the person adding >> this token. >> - if 'ipatokenowner' not in entry_attrs: >> + # If managedby was not specified, attempt a sensible default. >> + if 'ipatokenowner' not in entry_attrs or 'managedby' not in >> entry_attrs: >> result = self.api.Command.user_find(whoami=True)['result'] >> if result: >> cur_uid = result[0]['uid'][0] >> - entry_attrs.setdefault('ipatokenowner', cur_uid) >> + prev_uid = entry_attrs.setdefault('ipatokenowner', cur_uid) >> + if cur_uid == prev_uid: >> + entry_attrs.setdefault('managedby', result[0]['dn']) > > This code is still needed. Read the patch description. And, FYI, > 'managedby' is correct in this case, not 'managedby_user'. I tested. Right. I don't even know why I thought otherwise. > >>> 2. I can't figure out how to get the framework to actually show >>> managedBy in command output (like otptoken-show). This means you can >>> add/remove relationships using otptoken-add-managedby and >>> otptoken-remove-managedby, but you can't actually see the list of >>> managers. What am I missing? >> >> In the hbacrule or selinuxusermap plugins it is done by adding an >> "invisible" param to the object plugin, like this: >> >> Str('managedby_user?', >> label=_('Manager'), >> flags=['no_create', 'no_update', 'no_search'], >> ), > > Done. > >>> >>> Also, it would be helpful if someone with DS expertise could answer the >>> question about the performance of the ACI structure options as listed >>> above. > > We still need this. Ludwig? +1 > >> You should update the code in user_del to use managedby_user instead of >> managedby, otherwise it won't really work. > > Done. > Thanks, ACK after the ACI issue is dealt with. -- Jan Cholasta From lkrispen at redhat.com Wed Jun 11 09:55:05 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 11 Jun 2014 11:55:05 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <53982229.3010502@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <1400001168.2512.20.camel@ipa.example.com> <53835641.7040001@redhat.com> <1401309865.4631.5.camel@ipa.example.com> <5390121C.5070402@redhat.com> <1402074277.4323.37.camel@ipa.example.com> <53982229.3010502@redhat.com> Message-ID: <53982779.8020600@redhat.com> On 06/11/2014 11:32 AM, Jan Cholasta wrote: > On 6.6.2014 19:04, Nathaniel McCallum wrote: >> On Thu, 2014-06-05 at 08:45 +0200, Jan Cholasta wrote: >>> On 28.5.2014 22:44, Nathaniel McCallum wrote: >>>> On Mon, 2014-05-26 at 16:57 +0200, Jan Cholasta wrote: >>>>> On 13.5.2014 19:12, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-05-13 at 16:33 +0200, Jan Cholasta wrote: >>>>>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>>>>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs >>>>>>>>>>>>>>>>> after the >>>>>>>>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Admins, as before, have full access to all token >>>>>>>>>>>>>>>>> permissions. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Normal users have read/search/compare access to all of >>>>>>>>>>>>>>>>> the non-secret >>>>>>>>>>>>>>>>> data for tokens assigned to them, whether protected or >>>>>>>>>>>>>>>>> non-protected. >>>>>>>>>>>>>>>>> Users can add or delete non-protected tokens and >>>>>>>>>>>>>>>>> modify most of their >>>>>>>>>>>>>>>>> metadata. However they cannot create, delete or modify >>>>>>>>>>>>>>>>> protected tokens. >>>>>>>>>>>>>>>>> Regardless of whether the token is protected or not, >>>>>>>>>>>>>>>>> users cannot change >>>>>>>>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In contrast, admins can create protected tokens. This >>>>>>>>>>>>>>>>> protects the token >>>>>>>>>>>>>>>>> from deletion or modification when assigned to users. >>>>>>>>>>>>>>>>> Additionally, when >>>>>>>>>>>>>>>>> a user account is deleted, the assigned non-protected >>>>>>>>>>>>>>>>> tokens are deleted >>>>>>>>>>>>>>>>> but the protected tokens are merely orphaned. This >>>>>>>>>>>>>>>>> permits the token to >>>>>>>>>>>>>>>>> be reassigned without having to recreate it. This last >>>>>>>>>>>>>>>>> point is >>>>>>>>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>>>>>>>> This new version makes ipatokenDisabled visible for >>>>>>>>>>>>>>>> token owners. It is >>>>>>>>>>>>>>>> also writable if the token is non-protected. This >>>>>>>>>>>>>>>> additionally fixes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>>>>>>>> This new version changes the way the default value of >>>>>>>>>>>>>>> protected is setup >>>>>>>>>>>>>>> in accordance with the changes made for the review of my >>>>>>>>>>>>>>> patch 0048.2. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nathaniel >>>>>>>>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>>>>>>>> No. Alternate designs are welcome. The code is easy enough >>>>>>>>>>>>> to modify. >>>>>>>>>>>>> >>>>>>>>>>>>>> I did not dig too deep into this, but I think it might be >>>>>>>>>>>>>> better to >>>>>>>>>>>>>> instead use the managedby attribute on a token to limit >>>>>>>>>>>>>> who can delete >>>>>>>>>>>>>> (or administer in other way) the token. On otptoken-add, >>>>>>>>>>>>>> managedby would >>>>>>>>>>>>>> be set to the "whoami" user DN, unless run with >>>>>>>>>>>>>> --protected, in which >>>>>>>>>>>>>> case managedby would be left empty. Then, when deleting a >>>>>>>>>>>>>> user, the >>>>>>>>>>>>>> token would be deleted only if the user manages the token. >>>>>>>>>>>>> It seems to me that the mechanics of this are roughly the >>>>>>>>>>>>> same as >>>>>>>>>>>>> protected, just with a different syntax. The cost of this >>>>>>>>>>>>> is more >>>>>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn >>>>>>>>>>>>> clauses (is >>>>>>>>>>>>> this possible?) instead of a simple filter. If there is a >>>>>>>>>>>>> clear benefit, >>>>>>>>>>>>> we can justify the more obtuse syntax. >>>>>>>>>>>> >>>>>>>>>>>> We usually try not to create new attributes until it is >>>>>>>>>>>> fully justified. >>>>>>>>>>>> I would like Simo to chime in on this. >>>>>>>>>>> >>>>>>>>>>> I would also prefer to reuse existing attributes and >>>>>>>>>>> mechanism if >>>>>>>>>>> possible and if it will not preclude future work. >>>>>>>>>>> >>>>>>>>>>> In this case, it "sounds" like managed-by has the >>>>>>>>>>> appropriate meaning: >>>>>>>>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>>>>>>>> >>>>>>>>>>> Nathaniel can you send 2 lines showing the difference in >>>>>>>>>>> ACIs between >>>>>>>>>>> using managed-by vs a new attribute ? >>>>>>>>>> >>>>>>>>>> These are the ACIs using the protected mechanism: >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>>> "objectclass || description || ipatokenUniqueID || >>>>>>>>>> ipatokenDisabled || >>>>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>>>>> ipatokenModel >>>>>>>>>> || ipatokenSerial || ipatokenOwner || >>>>>>>>>> ipatokenProtected")(version 3.0; >>>>>>>>>> acl "Users can read basic token info"; allow (read, search, >>>>>>>>>> compare) >>>>>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP >>>>>>>>>> details"; >>>>>>>>>> allow (read, search, compare) userattr = >>>>>>>>>> "ipatokenOwner#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>>>>> "Users can >>>>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>>>> "ipatokenOwner#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = >>>>>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs >>>>>>>>>> = >>>>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic >>>>>>>>>> token info"; >>>>>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (target = >>>>>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>>>> = >>>>>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version >>>>>>>>>> 3.0; >>>>>>>>>> acl "Users can create and delete tokens"; allow (add, delete) >>>>>>>>>> userattr = >>>>>>>>>> "ipatokenOwner#SELFDN";) >>>>>>>>>> >>>>>>>>>> This is what they look like using managedBy (I have not >>>>>>>>>> tested this): >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>>> "objectclass || description || ipatokenUniqueID || >>>>>>>>>> ipatokenDisabled || >>>>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>>>>> ipatokenModel >>>>>>>>>> || ipatokenSerial || ipatokenOwner || >>>>>>>>>> ipatokenProtected")(version 3.0; >>>>>>>>>> acl "Users can read basic token info"; allow (read, search, >>>>>>>>>> compare) >>>>>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>>>>> userattr = "managedBy#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP >>>>>>>>>> details"; >>>>>>>>>> allow (read, search, compare) userattr = >>>>>>>>>> "ipatokenOwner#USERDN"; allow >>>>>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>>>>> "Users can >>>>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>>>>> "managedBy#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic >>>>>>>>>> token info"; >>>>>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>>>>> "managedBy#USERDN";) >>>>>>>>>> >>>>>>>>>> aci: (target = >>>>>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>>>>> self-managed tokens"; allow (add) userattr = >>>>>>>>>> "ipatokenOwner#SELFDN" and >>>>>>>>>> userattr = "managedBy#SELFDN";) >>>>>>>>>> >>>>>>>>>> In short: >>>>>>>>>> 1. Owner and manager get read, search and compare. >>>>>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>>>>> >>>>>>>>>> The otptoken-add command should gain the following defaults: >>>>>>>>>> 1. The owner defaults to the user adding the token. >>>>>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>>>>> >>>>>>>>>> This means that if neither owner nor managedBy are specified, >>>>>>>>>> the >>>>>>>>>> default is a self-owned, self-managed token. Likewise, if a >>>>>>>>>> different >>>>>>>>>> owner is specified, no manager is assumed. >>>>>>>>>> >>>>>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle >>>>>>>>>> the above >>>>>>>>>> syntax. This will become clear during testing if we want this >>>>>>>>>> approach. >>>>>>>>>> >>>>>>>>>> Does this look sane? >>>>>>>>> >>>>>>>>> I am not entirely sure your ACI syntax is always right for the >>>>>>>>> second >>>>>>>>> set. and perhaps we want to duplicate ACIs in some cases (once >>>>>>>>> for owner >>>>>>>>> once for manager). >>>>>>>>> >>>>>>>>> I think the read ACIs do not need to list managedby ? Do we >>>>>>>>> plan to have >>>>>>>>> a manager that is another regular user but not the owner nor >>>>>>>>> an admin ? >>>>>>>>> >>>>>>>>> In any case I prefer the sytnax that uses managedby, as it has >>>>>>>>> more >>>>>>>>> potential. >>>>>>>> >>>>>>>> Attached is a new version of the patch which implements the >>>>>>>> feature >>>>>>>> using managedBy instead of ipatokenProtected. One important >>>>>>>> thing needs >>>>>>>> to be said about this patch. I am not exposing managedBy in >>>>>>>> either the >>>>>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>>>>> expose this similar to owner or as a relationship? >>>>>>> >>>>>>> I would expose it, as a relationship. (Note that ipatokenowner >>>>>>> should >>>>>>> ideally be represented as a relationship too, but the framework >>>>>>> does not >>>>>>> support 1-to-many relationships ATM.) >>>>>> >>>>>> So since this is a 1-to-many relationship we shouldn't expose it? >>>>>> >>>>>> Or should I do it like owner is currently done? >>>>> >>>>> Do it like managedby is done in the host plugin (see >>>>> "attribute_members", "relationships", etc.) >>>>> >>>>>> >>>>>>> >>>>>>> Just curious, why are the ACIs divided like this: >>>>>>> >>>>>>> aci: (targetfilter = >>>>>>> "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || >>>>>>> ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>> ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner")(version 3.0; acl >>>>>>> "Users/managers >>>>>>> can read basic token info"; allow (read, search, compare) >>>>>>> userattr = >>>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>>> aci: (targetfilter = >>>>>>> "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see >>>>>>> TOTP >>>>>>> details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>>>> aci: (targetfilter = >>>>>>> "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>> "Users/managers can see HOTP details"; allow (read, search, >>>>>>> compare) >>>>>>> userattr = "ipatokenOwner#USERDN" or userattr = >>>>>>> "managedBy#USERDN";) >>>>>>> >>>>>>> IMHO you could make them less complex by dividing them like this: >>>>>>> >>>>>>> aci: (targetfilter = >>>>>>> "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || >>>>>>> ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>> ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl >>>>>>> "Owner can >>>>>>> read token details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN";) >>>>>>> aci: (targetfilter = >>>>>>> "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || >>>>>>> ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>> ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenOTPalgorithm || >>>>>>> ipatokenOTPdigits || ipatokenTOTPtimeStep")(version 3.0; acl >>>>>>> "Managers >>>>>>> can read token details"; allow (read, search, compare) userattr = >>>>>>> "managedBy#USERDN";) >>>>>> >>>>>> The first set is organized by objectClass. The second by userattr. I >>>>>> have no strong opinion on this matter, though performance is >>>>>> probably a >>>>>> consideration. Do any DS guys want to chime in? >>>>> >>>>> I would still like to know someone else's opinion on this, but if >>>>> there's none, let's keep it your way. >>>>> >>>>>> >>>>>>> Would it make sense to keep --protected as a flag in >>>>>>> otptoken-add as a >>>>>>> shortcut for "entry_attrs['managedby'] = None"? >>>>>> >>>>>> I can't think of a use case for this. The only use case I *can* >>>>>> think of >>>>>> is an admin creating a non-protected token for a user. >>>>> >>>>> OK. >>>>> >>>>>> >>>>>>> Would it make sense to default managedby to the current bind DN in >>>>>>> otptoken-add, even if it's not a user DN? (Do we want to allow >>>>>>> running >>>>>>> otptoken-add by hosts/services/other non-users?) >>>>>> >>>>>> No idea. Dmitri? >>>>> >>>>> We can add this later if necessary. >>>>> >>>>>> >>>>>>> Is orphaning a token when a user is deleted only if it is not >>>>>>> managed by >>>>>>> any other users the intended behavior? It just seems sort of >>>>>>> strange to >>>>>>> me, since it changes the token from unprotected to protected. >>>>>> >>>>>> I don't think that is the behavior. We orphan the token if the >>>>>> owner is >>>>>> not listed as a manager. If the owner is listed as a manager, we >>>>>> delete >>>>>> the token. >>>>>> >>>>>> Put another way, protected tokens are orphaned and unprotected >>>>>> tokens >>>>>> are deleted. >>>>>> >>>>>> If I didn't implement that, please point out my bug. >>>>> >>>>> Sorry, my bad, your code is right. You can make it simpler, though: >>>>> >>>>> orphan = [x for x in token.get('managedby', []) if x == dn] >>>>> >>>>> (The "len() == 0" check is not necessary and using list >>>>> comprehensions >>>>> makes the code more readable than using filter.) >>>> >>>> The attached version fixes all the above issues. Two issues that may >>>> remain: >>>> 1. There is no option to set managedBy during otptoken-add or >>>> otptoken-mod. This is probably okay. >>> >>> Yes. I guess this bit is not needed anymore: >>> >>> # If owner was not specified, default to the person adding >>> this token. >>> - if 'ipatokenowner' not in entry_attrs: >>> + # If managedby was not specified, attempt a sensible default. >>> + if 'ipatokenowner' not in entry_attrs or 'managedby' not in >>> entry_attrs: >>> result = >>> self.api.Command.user_find(whoami=True)['result'] >>> if result: >>> cur_uid = result[0]['uid'][0] >>> - entry_attrs.setdefault('ipatokenowner', cur_uid) >>> + prev_uid = entry_attrs.setdefault('ipatokenowner', >>> cur_uid) >>> + if cur_uid == prev_uid: >>> + entry_attrs.setdefault('managedby', >>> result[0]['dn']) >> >> This code is still needed. Read the patch description. And, FYI, >> 'managedby' is correct in this case, not 'managedby_user'. I tested. > > Right. I don't even know why I thought otherwise. > >> >>>> 2. I can't figure out how to get the framework to actually show >>>> managedBy in command output (like otptoken-show). This means you can >>>> add/remove relationships using otptoken-add-managedby and >>>> otptoken-remove-managedby, but you can't actually see the list of >>>> managers. What am I missing? >>> >>> In the hbacrule or selinuxusermap plugins it is done by adding an >>> "invisible" param to the object plugin, like this: >>> >>> Str('managedby_user?', >>> label=_('Manager'), >>> flags=['no_create', 'no_update', 'no_search'], >>> ), >> >> Done. >> >>>> >>>> Also, it would be helpful if someone with DS expertise could answer >>>> the >>>> question about the performance of the ACI structure options as listed >>>> above. >> >> We still need this. Ludwig? > > +1 sorry, I had missed this, look into it now > >> >>> You should update the code in user_del to use managedby_user instead of >>> managedby, otherwise it won't really work. >> >> Done. >> > > Thanks, ACK after the ACI issue is dealt with. > From lkrispen at redhat.com Wed Jun 11 10:12:28 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 11 Jun 2014 12:12:28 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <53722D35.1060901@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> Message-ID: <53982B8C.1060206@redhat.com> On 05/13/2014 04:33 PM, Jan Cholasta wrote: > On 12.5.2014 21:02, Nathaniel McCallum wrote: >> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: >>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: >>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the >>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>> >>>>>>>>>>> Admins, as before, have full access to all token permissions. >>>>>>>>>>> >>>>>>>>>>> Normal users have read/search/compare access to all of the >>>>>>>>>>> non-secret >>>>>>>>>>> data for tokens assigned to them, whether protected or >>>>>>>>>>> non-protected. >>>>>>>>>>> Users can add or delete non-protected tokens and modify most >>>>>>>>>>> of their >>>>>>>>>>> metadata. However they cannot create, delete or modify >>>>>>>>>>> protected tokens. >>>>>>>>>>> Regardless of whether the token is protected or not, users >>>>>>>>>>> cannot change >>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>> >>>>>>>>>>> In contrast, admins can create protected tokens. This >>>>>>>>>>> protects the token >>>>>>>>>>> from deletion or modification when assigned to users. >>>>>>>>>>> Additionally, when >>>>>>>>>>> a user account is deleted, the assigned non-protected tokens >>>>>>>>>>> are deleted >>>>>>>>>>> but the protected tokens are merely orphaned. This permits >>>>>>>>>>> the token to >>>>>>>>>>> be reassigned without having to recreate it. This last point is >>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>> >>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>> This new version makes ipatokenDisabled visible for token >>>>>>>>>> owners. It is >>>>>>>>>> also writable if the token is non-protected. This >>>>>>>>>> additionally fixes: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>> This new version changes the way the default value of >>>>>>>>> protected is setup >>>>>>>>> in accordance with the changes made for the review of my patch >>>>>>>>> 0048.2. >>>>>>>>> >>>>>>>>> Nathaniel >>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>> No. Alternate designs are welcome. The code is easy enough to >>>>>>> modify. >>>>>>> >>>>>>>> I did not dig too deep into this, but I think it might be >>>>>>>> better to >>>>>>>> instead use the managedby attribute on a token to limit who can >>>>>>>> delete >>>>>>>> (or administer in other way) the token. On otptoken-add, >>>>>>>> managedby would >>>>>>>> be set to the "whoami" user DN, unless run with --protected, in >>>>>>>> which >>>>>>>> case managedby would be left empty. Then, when deleting a user, >>>>>>>> the >>>>>>>> token would be deleted only if the user manages the token. >>>>>>> It seems to me that the mechanics of this are roughly the same as >>>>>>> protected, just with a different syntax. The cost of this is more >>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses >>>>>>> (is >>>>>>> this possible?) instead of a simple filter. If there is a clear >>>>>>> benefit, >>>>>>> we can justify the more obtuse syntax. >>>>>> >>>>>> We usually try not to create new attributes until it is fully >>>>>> justified. >>>>>> I would like Simo to chime in on this. >>>>> >>>>> I would also prefer to reuse existing attributes and mechanism if >>>>> possible and if it will not preclude future work. >>>>> >>>>> In this case, it "sounds" like managed-by has the appropriate >>>>> meaning: >>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>> >>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>> using managed-by vs a new attribute ? >>>> >>>> These are the ACIs using the protected mechanism: >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>> acl "Users can read basic token info"; allow (read, search, compare) >>>> userattr = "ipatokenOwner#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>> "Users can >>>> see HOTP details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN";) >>>> >>>> aci: (targetfilter = >>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>> >>>> aci: (target = >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version >>>> 3.0; >>>> acl "Users can create and delete tokens"; allow (add, delete) >>>> userattr = >>>> "ipatokenOwner#SELFDN";) >>>> >>>> This is what they look like using managedBy (I have not tested this): >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>> acl "Users can read basic token info"; allow (read, search, compare) >>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>> userattr = "managedBy#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>> "Users can >>>> see HOTP details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>> "managedBy#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token >>>> info"; >>>> allow (write) userattr = "managedBy#USERDN";) >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>> "Managers can delete tokens"; allow (delete) userattr = >>>> "managedBy#USERDN";) >>>> >>>> aci: (target = >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >>>> and >>>> userattr = "managedBy#SELFDN";) >>>> >>>> In short: >>>> 1. Owner and manager get read, search and compare. >>>> 2. Manager gets write (to select attributes) and delete. >>>> 3. Users can create self-managed tokens for themselves only. >>>> >>>> The otptoken-add command should gain the following defaults: >>>> 1. The owner defaults to the user adding the token. >>>> 2. If owner == user adding token, managedBy defaults to owner. >>>> 3. Otherwise, managedBy defaults to None. >>>> >>>> This means that if neither owner nor managedBy are specified, the >>>> default is a self-owned, self-managed token. Likewise, if a different >>>> owner is specified, no manager is assumed. >>>> >>>> rcrit expresses worry that ipalib's ACI parser may not handle the >>>> above >>>> syntax. This will become clear during testing if we want this >>>> approach. >>>> >>>> Does this look sane? >>> >>> I am not entirely sure your ACI syntax is always right for the second >>> set. and perhaps we want to duplicate ACIs in some cases (once for >>> owner >>> once for manager). >>> >>> I think the read ACIs do not need to list managedby ? Do we plan to >>> have >>> a manager that is another regular user but not the owner nor an admin ? >>> >>> In any case I prefer the sytnax that uses managedby, as it has more >>> potential. >> >> Attached is a new version of the patch which implements the feature >> using managedBy instead of ipatokenProtected. One important thing needs >> to be said about this patch. I am not exposing managedBy in either the >> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >> expose this similar to owner or as a relationship? > > I would expose it, as a relationship. (Note that ipatokenowner should > ideally be represented as a relationship too, but the framework does > not support 1-to-many relationships ATM.) > > > Just curious, why are the ACIs divided like this: > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl > "Users/managers can read basic token info"; allow (read, search, > compare) userattr = "ipatokenOwner#USERDN" or userattr = > "managedBy#USERDN";) > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > "ipatokenOTPalgorithm || ipatokenOTPdigits || > ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > details"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > "Users/managers can see HOTP details"; allow (read, search, compare) > userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > IMHO you could make them less complex by dividing them like this: > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > ipatokenModel || ipatokenSerial || ipatokenOwner || > ipatokenOTPalgorithm || ipatokenOTPdigits || > ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token > details"; allow (read, search, compare) userattr = > "ipatokenOwner#USERDN";) > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > ipatokenModel || ipatokenSerial || ipatokenOwner || > ipatokenOTPalgorithm || ipatokenOTPdigits || > ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token > details"; allow (read, search, compare) userattr = "managedBy#USERDN";) do you mean aci: (targetfilter = "(|(objectClass=ipaToken)(objectClass=ipatokenTOTP)(objectClass=ipatokenHOTP))") or are the attrs like ipatokenOTPdigits also in the ipatoken objectclass ? > > > Would it make sense to keep --protected as a flag in otptoken-add as a > shortcut for "entry_attrs['managedby'] = None"? > > > Would it make sense to default managedby to the current bind DN in > otptoken-add, even if it's not a user DN? (Do we want to allow running > otptoken-add by hosts/services/other non-users?) > > > Is orphaning a token when a user is deleted only if it is not managed > by any other users the intended behavior? It just seems sort of > strange to me, since it changes the token from unprotected to protected. > From pvoborni at redhat.com Wed Jun 11 11:06:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 13:06:08 +0200 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <5397745F.3060100@redhat.com> References: <5374C821.60004@redhat.com> <5397745F.3060100@redhat.com> Message-ID: <53983820.2040606@redhat.com> On 10.6.2014 23:10, Endi Sukma Dewata wrote: > On 5/15/2014 8:58 AM, Petr Vobornik wrote: >> Just an idea: >> >> there is only one top level item in self service menu -> no point of >> having this level. >> >> This patch replaces top level with second menu level >> >> original: >> * http://pvoborni.fedorapeople.org/images/self-service-menu-2levels.png >> new: >> * http://pvoborni.fedorapeople.org/images/self-service-menu-1level.png > > ACK. Pushed to master: 36c5ba9d27c53e97d1185f38d4b17faac050e19f > > Some unrelated issues: > > 1. If I recall correctly, a new user is required to change the password > upon the initial login. This can be done with kinit, but can this be > done via UI too? Right now a new user will get a login error without any > message or link to reset the password. It works for me. There was a ticket https://fedorahosted.org/freeipa/ticket/4339 which corresponds to the description. Or it could be related to: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=c41b782bc59cd0cb70cbd62d543f9c538109d410 (if you use an IPA version before the revert) > > 2. When I logged in to the self-service mode, I got the following error: > http://edewata.fedorapeople.org/ipa/images/snapshot7.png Caused by https://fedorahosted.org/freeipa/ticket/4355 patches are ready, will send them today. http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=aci-fix-and-sudo > > 3. In the login screen if the page is shorter than a certain height, > there will be a blank area appearing at the bottom. The background > doesn't extend all the way to the bottom: > http://edewata.fedorapeople.org/ipa/images/snapshot8.png > Apparently this could be fixed by adding .login-pf-body class to facet's div. I'll create a patch. -- Petr Vobornik From pviktori at redhat.com Wed Jun 11 11:23:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 13:23:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0572-0575 Add ACI.txt + default bind rule type In-Reply-To: <5397161E.5050904@redhat.com> References: <5395F81B.80900@redhat.com> <5396BC3F.4040002@redhat.com> <5396EC51.3060000@redhat.com> <5397067D.3010005@redhat.com> <5397161E.5050904@redhat.com> Message-ID: <53983C3F.5070704@redhat.com> On 06/10/2014 04:28 PM, Martin Kosek wrote: > On 06/10/2014 03:22 PM, Petr Viktorin wrote: >> On 06/10/2014 01:30 PM, Martin Kosek wrote: >>> On 06/10/2014 10:05 AM, Petr Viktorin wrote: >>>> On 06/09/2014 08:08 PM, Petr Viktorin wrote: >>>>> Having another verification tool should help reviewing the permission >>>>> patches. >>>>> >>>>> >>>>> To avoid conflicts, apply on top of my patches 0568-0570 (Write User >>>>> permissions). >>>>> >>>>> >>>>> 0572: I tried to make the ACIs generated by the permission plugin as >>>>> predictable as possible, but I missed one place it's affected by >>>>> dict/set iteration order (which is undefined). Here's a fix. >>>>> >>>>> 0573: Minor refactoring to make the next patch easier. >>>>> >>>>> 0574: Add ACI.txt & makeaci. Due to the predictable ACIs, all this needs >>>>> to do is generate the file; comparing can be done bit-by-bit. >>>>> I do run the validation results through difflib, but frankly it's easier >>>>> just to use Git. >>>> >>>> On my way home yesterday I remembered I left out an important piece of >>>> information - the DN where the ACI is. Attaching updated patch 0574. >>>> >>>>> 0575: Make 'permission' the default bind rule type for managed >>>>> permissions. Rationale in the commit message. >>>>> Run makeaci to verify this doesn't change the result. >>> >>> This will create some additional burden for you when converting ACIs, but the >>> idea is good. >> >> Any ACI.txt conflicts are easily resolved by running makeaci, and I think the >> additional verification is worth it. > > Yup, I am not complaining :-) > >>> The script worked for me, can we just create some more friendly error message >>> than an assertion traceback? >>> >>> # ./makeaci --validate >>> ... >>> Traceback (most recent call last): >>> File "./makeaci", line 116, in >>> main(options) >>> File "./makeaci", line 108, in main >>> raise AssertionError('validation failed') >>> AssertionError: validation failed >> >> The tool is meant for developers and packagers; tracebacks are designed to be >> friendly for this target group. >> >> But, OK, I've made it exit() instead, and added some instructions. > > Ok, thanks. > >> From the thread on user permissions: >> On 06/10/2014 10:13 AM, Martin Kosek wrote: >>> 1) Hm, I think was not clear enough. memberOf should not be added to users, as >>> no object should be "member of user". Please revert this change. I originally >>> thought it is missing in "Read Group Membership" permissions, but it isn't. >>> >>> We are again hitting the problem of a search operation when we are not allowed >>> to search on all attributes (the CVE fix). This is the search produced by "ipa >>> user-show fbar": >>> >>> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 SRCH base="dc=example,dc=com" >>> scope=2 >>> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >>> >>> attrs="" >>> [10/Jun/2014:09:59:28 +0200] conn=155 op=5 RESULT err=0 tag=101 nentries=0 >>> etime=0 >>> >>> It returns zero results, until I also allow memberUser and memberHost: >>> >>> # ipa permission-mod 'System: Read Group Membership' >>> --attrs={member,memberof,memberuid,memberuser,memberhost} >>> >>> Now I get the results: >>> >>> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 SRCH base="dc=example,dc=com" >>> scope=2 >>> filter="(|(member=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberUser=uid=fbar,cn=users,cn=accounts,dc=example,dc=com)(memberHost=uid=fbar,cn=users,cn=accounts,dc=example,dc=com))" >>> >>> attrs="" >>> [10/Jun/2014:10:04:25 +0200] conn=160 op=5 RESULT err=0 tag=101 nentries=1 >>> etime=0 >>> >>> ipa user-show fbar >>> ... >>> Member of groups: ipausers <<<<< >>> Indirect Member of role: test >>> ... >>> >>> User still cannot see if he is direct or indirect member of role, but this may >>> not be a problem. >>> >>> The easiest approach solution may be to update all "Read * Membership" >>> permissions/ACIs to always contain member&memberuser&memberhost unless we want >>> to again produce multiple LDAP searches for checking direct/indirect membership. >> >> I've amended the read permissions for containerish objects, and added a check >> to makeaci to enforce this in the future. >> >> I insist on printing a traceback on error here. This check is meant for >> developers, tracebacks are perfect for them. >> > > If you insist, I can live with that. As you said, it is for packagers and > developers after all. > > ACK to the whole patch set. Thanks! Pushed to master: b6258d08d6c5605b32151654c6259f7c77f1a32b -- Petr? From pspacek at redhat.com Wed Jun 11 11:26:47 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 11 Jun 2014 13:26:47 +0200 Subject: [Freeipa-devel] [PATCH 0018] Fix --ttl description for DNS zones Message-ID: <53983CF7.9040905@redhat.com> Hello, Fix --ttl description for DNS zones TTL specified in idnsZone object class affects all records at zone apex, not only SOA record. I have realized that current description is incorrect when I was doing doc review. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0018-Fix-ttl-description-for-DNS-zones.patch Type: text/x-patch Size: 5091 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 11 11:29:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Jun 2014 13:29:26 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53981A45.9090108@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> Message-ID: <53983D96.5080604@redhat.com> On 06/11/2014 10:58 AM, Jan Cholasta wrote: > On 10.6.2014 09:55, Martin Kosek wrote: >> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>> managedby_host >>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>> why that >>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>> original >>>>>>>>> check is not right anymore ? >>>>>>>> >>>>>>>> The original check is wrong, see >>>>>>>> . >>>>>>>> >>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>> handled by ACIs. >>>>>>> >>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>> write the usercertificate. >>>>>>> >>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>> >>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>> Certificates and kerberos keys". >>>>>> >>>>>> I think the check can be extended to users as well, so that requesting >>>>>> certificate with SAN is allowed only to users which have write access to >>>>>> the SAN services. >>>> >>>> I have done the modification, see attached patches. >>>> >>>>> >>>>> Sounds good to me then, thanks for explaining. >>>>> >>>>> The patches also look good, but I would like someone to give them a try >>>>> for a formal ack. >>>> >>>> OK, thanks. >>>> >>> >>> Bump. >>> >>> I have added stricter validation of subject alt names as well as certificate >>> extensions in general to the second patch. >> >> Thanks! >> >>> Updated patches attached. >>> >>> Note that you will need python-nss 0.15 in order to test, you can get a RPM for >>> Fedora here: . >> >> John, do you think we could build python-nss 0.15 also for Fedora 20? The fix >> incorporated in it is pretty important to warrant bugfix update in bodhi. It >> would also allow FreeIPA 4.0 to be installed on Fedora 20. >> >>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work, >>> because . >> >> This worked for me, I suspect this is a DS bug. More info in the ticket. >> >> Now back to review of the patch: >> >> 210.4: looks ok >> 234.4: >> >> 1) Virtual operation "request certificate with subjectaltname" should be a >> member of Certificate Administrators privilege > > OK. > >> >> >> 2) I would write "Request Certificate With SubjectAltName" with "with" instead >> of "With". I.e.: >> Request Certificate with SubjectAltName > > OK. > >> >> >> 3) Why is the extension check only enforced for non-hosts? >> >> + if not bind_principal.startswith('host/'): >> + for ext in extensions: >> + operation = self._allowed_extensions.get(ext) >> + if operation: >> + self.check_access(operation) >> >> My tricky certmonger request passed: >> >> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com >> -E mkosek at redhat.com >> >> while when I posted the same CSR as privileged user, it was rejected: >> >> $ klist >> Ticket cache: KEYRING:persistent:962000003:962000003 >> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >> >> $ ipa cert-request --principal test/`hostname` certmonger.csr >> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden > > Right, I meant to NACK myself, but you were faster. Fixed. > >> >> >> 4) Regular users cannot read Virtual Operations, so even if I assign them a >> permission, command is refused: >> >> $ ipa cert-request --principal test/`hostname` openssl.csr >> ipa: ERROR: Insufficient access: No such virtual command >> >> I think we will need to create new managed permission "Read Virtual Operations" >> and assign it to "Certificate Administrators" privilege by default as this >> privilege has the virtual operation permissions assigned. Petr3, what is your >> take on this? >> >> Otherwise the patch worked well for me, the authorization part looked OK. My >> biggest concern was just the host/user differentiation wrt unknown >> subjectaltname types. >> >> Martin >> > > Updated patches attached. > 1) I could not compile the patch set: $ make rpms ... if [ "" != "yes" ]; then \ ./makeapi --validate; \ ./makeaci --validate; \ fi Traceback (most recent call last): File "./makeapi", line 457, in sys.exit(main()) File "./makeapi", line 428, in main api.finalize() File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize self.__do_if_not_done('load_plugins') File "/root/freeipa-master/ipalib/plugable.py", line 482, in __do_if_not_done getattr(self, name)() File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins self.import_plugins('ipalib') File "/root/freeipa-master/ipalib/plugable.py", line 689, in import_plugins __import__(fullname) File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in from ipalib import pkcs10 File "/root/freeipa-master/ipalib/pkcs10.py", line 77 .replace('@', '\\@') ... The rest of the notes are thus only from reading. 2) There are lines like + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': or + if name_type not in ('DNS name', + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', + 'Other Name (OID.1.3.6.1.5.2.2)'): or + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', + 'Other Name (OID.1.3.6.1.5.2.2)'): Can we do something better? Getting the extension type based on it's description seems extremely unstable to me. Can we for example modify get_subjectaltname to get the type based on CertificateExtension object's oid or oid_tag attributes? I would rather see get_subjectaltname return solid type like CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing descriptions. It would be more readable, too. Martin From pvoborni at redhat.com Wed Jun 11 11:52:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 13:52:12 +0200 Subject: [Freeipa-devel] [PATCH] 645 webui: display only dialogs which belong to current facet In-Reply-To: <5397749C.40507@redhat.com> References: <53846DB7.40403@redhat.com> <53874F09.6040307@redhat.com> <5397749C.40507@redhat.com> Message-ID: <539842EC.4040309@redhat.com> On 10.6.2014 23:11, Endi Sukma Dewata wrote: > On 5/29/2014 10:15 AM, Petr Vobornik wrote: >> On 27.5.2014 12:49, Petr Vobornik wrote: >>> Dialog instances no longer directly call IPA.opened_dialog methods. It's >>> handled through events (decoupled from dialog's POV). IPA.open_dialogs >>> with assistance of ApplicationController makes sure that there is only >>> one dialog opened at the same time. >>> >>> It also makes sure to hide all dialogs, which are not global dialogs and >>> did not originate from current facet, when switching facets. >>> >>> https://fedorahosted.org/freeipa/ticket/4348 >>> >> >> Attaching rebased version (on top of latest PatternFly patch set). > > ACK, but see comments below: pushed to master with issue #2 fixed:4b2d20a1f95edd2982fbb1901287f2bb2194c9db > > 1. Let's say I had a dialog open and I clicked the button to execute the > operation but the session expired so I'd get a login screen. Once I > relogged in, the operation was executed immediately without a chance to > review the operation. I think it's safer to require the user to reclick > the button (i.e. the UI ignores the user action that happens while the > session expired). +1 This behavior is there for at least 3 years. IMO it worked well with just krb auth and login screen in form of a dialog. The behavior is especially bad if there are multiple pending actions. New ticket: https://fedorahosted.org/freeipa/ticket/4374 > > 2. Can this expression > > !facet || (facet && dialog.facet === facet) > > be simplified into this? > > !facet || dialog.facet === facet yes, fixed > > 3. Unrelated. In self-service user page the action menus for Disable, > Delete, and Rebuild auto membership are enabled although the user > doesn't have the rights to execute those actions. > I'll look at the 'Disable' action but for 'Delete' and 'Rebuild...' we don't have enough information. Though, delete could be fixed if we had object level rights. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0645-2-webui-display-only-dialogs-which-belong-to-current-f.patch Type: text/x-patch Size: 8732 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 11:56:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 13:56:13 +0200 Subject: [Freeipa-devel] [PATCH] 646 webui: handle back button when unauthenticated In-Reply-To: <539774A1.20002@redhat.com> References: <53846DDF.2070808@redhat.com> <539774A1.20002@redhat.com> Message-ID: <539843DD.8010407@redhat.com> On 10.6.2014 23:12, Endi Sukma Dewata wrote: > On 5/27/2014 5:50 AM, Petr Vobornik wrote: >> using browser history when unauthenticated causes transition to >> the original and/or preceding facets. But nothing works since >> all commands fail due to expired credentials in session. >> >> These changes make sure that user stays on login screen if he misses >> valid session credentials while he wants to switch to facet which >> requires authentication. >> >> https://fedorahosted.org/freeipa/ticket/4353 > > ACK. > Pushed to master: 905d58a2a4bb88ed77552e37782eb274d5398ba0 -- Petr Vobornik From jcholast at redhat.com Wed Jun 11 12:24:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Jun 2014 14:24:45 +0200 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1399999226.2512.10.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> Message-ID: <53984A8D.9070508@redhat.com> Hi, On 13.5.2014 18:40, Nathaniel McCallum wrote: > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: >> This patch adds support for importing tokens using RFC 6030 key >> container files. This includes decryption support. For sysadmin sanity, >> any tokens which fail to add will be written to the output file for >> examination. The main use case here is where a small subset of a large >> set of tokens fails to validate or add. Using the output file, the >> sysadmin can attempt to recover these specific tokens. >> >> This code is implemented as a server-side script. However, it doesn't >> actually need to run on the server. This was done because importing is >> an odd fit for the IPA command framework: >> 1. We need to write an output file. >> 2. The operation may be long-running (thousands of tokens). >> 3. Only admins need to perform this task and it only happens >> infrequently. > > I forgot to put the link to the ticket in the commit message. Fixed. 1) I think you should initialize NSS in ipa_otptoken_import.py, not in the ipa-otptoken-import script. 2) The pep8 tool reports a lot of errors in ipa_otptoken_import.py. 3) Other error messages are in the form "message: %s", I think this one should use that form as well: + if encoding != 'DECIMAL': + raise ValidationError('Unsupported encoding (%s)!' % encoding) 4) This is not right: + except: + self.log.warn("Error adding token: " + str(sys.exc_info()[1])) I think it should be something like this instead: except ValidationError, e: self.log.warn("Error adding token: %s", e) 5) There is no man page for ipa-otptoken-import. 6) Output file is created even when ipa-otptoken-import fails with "Unable to connect to LDAP! Did you kinit?" and other initialization errors, which makes subsequent ipa-otptoken-import fail with "Output file already exists!". 7) When a key is specified by reference in Key/KeyReference instead of directly in Key/Data/Secret like in , import fails with "Key not found in token!". I would expect a different error message. 8) Importing produces this output: /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead. if data.get('pinpolicy', None): Error adding token: 'NoneType' object has no attribute 'strip' 9) Using an arbitrary file in -k produces this output: (SEC_ERROR_INVALID_KEY) The key does not support the requested operation. Traceback (most recent call last): File "/usr/sbin/ipa-otptoken-import", line 29, in nss.nss_shutdown() nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. 10) Importing and produces this output: Error adding token: object of type 'NoneType' has no len() 11) Importing or produces this output: /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:304: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead. if data.get('maxtransact', None): /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: FutureWarning: The behavior of this method will change in future versions. Use specific 'len(elem)' or 'elem is not None' test instead. if data.get('pinpolicy', None): 12) Importing succeeds, but it should fail. 13) Importing fails, but it should succeed, I think. Honza -- Jan Cholasta From simo at redhat.com Wed Jun 11 12:47:40 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 08:47:40 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <53981CE4.3050901@redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> Message-ID: <1402490860.29921.11.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote: > On 06/11/2014 02:48 AM, Simo Sorce wrote: > > I ma getting a failure to login in the UI > > > > The error is somewhere in ldap/schema/subentry.py > > > > KeyError: 'ipattokenhotp' > > > > A schema update may have failed I guess ? > > but running ipa-ldap-updater doesn't help ... > > > > Ideas ? > > Do you have the full traceback? This is in my tail output: [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: i18n_messages(): SUCCESS [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: config_show(): SUCCESS [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: user_find(None, whoami=True, all=True): SUCCESS [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: env(None): SUCCESS [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: dns_is_enabled(): SUCCESS [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: trustconfig_show(): NotFound [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: batch(({u'params': ((), {}), u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): SUCCESS [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: KeyError: 'ipatokenhotp' [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent call last): [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = self.Command[name](*args, **options) [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, **options) [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = self.execute(*args, **options) [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 57, in json_serialize [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return json_serialize(obj.__json__()) [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 649, in __json__ [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = self.sed[ObjectClass][object_class_oid] [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp' [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, object=u'all'): KeyError [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, command=u'all'): SUCCESS -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Wed Jun 11 12:55:20 2014 From: jdennis at redhat.com (John Dennis) Date: Wed, 11 Jun 2014 08:55:20 -0400 Subject: [Freeipa-devel] user certificates In-Reply-To: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> Message-ID: <539851B8.1060102@redhat.com> On 06/11/2014 04:02 AM, Fraser Tweedale wrote: > There are other use cases for user certificates, e.g. client > authentication for HTTP or other network services. Perhaps you know > of others - in which case let us know. 802.11 wireless authentication using EAP-TLS A common discussion on the RADIUS mailing lists is the desire to deploy using EAP-TLS but the difficulty of provisioning user certs is always the stumbling block. -- John From jcholast at redhat.com Wed Jun 11 12:59:14 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 11 Jun 2014 14:59:14 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53983D96.5080604@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> Message-ID: <539852A2.6040109@redhat.com> On 11.6.2014 13:29, Martin Kosek wrote: > On 06/11/2014 10:58 AM, Jan Cholasta wrote: >> On 10.6.2014 09:55, Martin Kosek wrote: >>> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>>> managedby_host >>>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>>> why that >>>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>>> original >>>>>>>>>> check is not right anymore ? >>>>>>>>> >>>>>>>>> The original check is wrong, see >>>>>>>>> . >>>>>>>>> >>>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>>> handled by ACIs. >>>>>>>> >>>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>>> write the usercertificate. >>>>>>>> >>>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>>> >>>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>>> Certificates and kerberos keys". >>>>>>> >>>>>>> I think the check can be extended to users as well, so that requesting >>>>>>> certificate with SAN is allowed only to users which have write access to >>>>>>> the SAN services. >>>>> >>>>> I have done the modification, see attached patches. >>>>> >>>>>> >>>>>> Sounds good to me then, thanks for explaining. >>>>>> >>>>>> The patches also look good, but I would like someone to give them a try >>>>>> for a formal ack. >>>>> >>>>> OK, thanks. >>>>> >>>> >>>> Bump. >>>> >>>> I have added stricter validation of subject alt names as well as certificate >>>> extensions in general to the second patch. >>> >>> Thanks! >>> >>>> Updated patches attached. >>>> >>>> Note that you will need python-nss 0.15 in order to test, you can get a RPM for >>>> Fedora here: . >>> >>> John, do you think we could build python-nss 0.15 also for Fedora 20? The fix >>> incorporated in it is pretty important to warrant bugfix update in bodhi. It >>> would also allow FreeIPA 4.0 to be installed on Fedora 20. >>> >>>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not work, >>>> because . >>> >>> This worked for me, I suspect this is a DS bug. More info in the ticket. >>> >>> Now back to review of the patch: >>> >>> 210.4: looks ok >>> 234.4: >>> >>> 1) Virtual operation "request certificate with subjectaltname" should be a >>> member of Certificate Administrators privilege >> >> OK. >> >>> >>> >>> 2) I would write "Request Certificate With SubjectAltName" with "with" instead >>> of "With". I.e.: >>> Request Certificate with SubjectAltName >> >> OK. >> >>> >>> >>> 3) Why is the extension check only enforced for non-hosts? >>> >>> + if not bind_principal.startswith('host/'): >>> + for ext in extensions: >>> + operation = self._allowed_extensions.get(ext) >>> + if operation: >>> + self.check_access(operation) >>> >>> My tricky certmonger request passed: >>> >>> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com >>> -E mkosek at redhat.com >>> >>> while when I posted the same CSR as privileged user, it was rejected: >>> >>> $ klist >>> Ticket cache: KEYRING:persistent:962000003:962000003 >>> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >>> >>> $ ipa cert-request --principal test/`hostname` certmonger.csr >>> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden >> >> Right, I meant to NACK myself, but you were faster. Fixed. >> >>> >>> >>> 4) Regular users cannot read Virtual Operations, so even if I assign them a >>> permission, command is refused: >>> >>> $ ipa cert-request --principal test/`hostname` openssl.csr >>> ipa: ERROR: Insufficient access: No such virtual command >>> >>> I think we will need to create new managed permission "Read Virtual Operations" >>> and assign it to "Certificate Administrators" privilege by default as this >>> privilege has the virtual operation permissions assigned. Petr3, what is your >>> take on this? >>> >>> Otherwise the patch worked well for me, the authorization part looked OK. My >>> biggest concern was just the host/user differentiation wrt unknown >>> subjectaltname types. >>> >>> Martin >>> >> >> Updated patches attached. >> > > 1) I could not compile the patch set: > > $ make rpms > ... > if [ "" != "yes" ]; then \ > ./makeapi --validate; \ > ./makeaci --validate; \ > fi > Traceback (most recent call last): > File "./makeapi", line 457, in > sys.exit(main()) > File "./makeapi", line 428, in main > api.finalize() > File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize > self.__do_if_not_done('load_plugins') > File "/root/freeipa-master/ipalib/plugable.py", line 482, in __do_if_not_done > getattr(self, name)() > File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins > self.import_plugins('ipalib') > File "/root/freeipa-master/ipalib/plugable.py", line 689, in import_plugins > __import__(fullname) > File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in > from ipalib import pkcs10 > File "/root/freeipa-master/ipalib/pkcs10.py", line 77 > .replace('@', '\\@') > ... > > The rest of the notes are thus only from reading. Sorry, last minute change gone wrong. > > 2) There are lines like > > + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': > > > or > > + if name_type not in ('DNS name', > + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', > + 'Other Name (OID.1.3.6.1.5.2.2)'): > > or > > + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', > + 'Other Name (OID.1.3.6.1.5.2.2)'): > > Can we do something better? Getting the extension type based on it's > description seems extremely unstable to me. These are SAN types, not extension types. Unfortunately the textual descriptions are the only SAN type representation available in python-nss which includes OIDs of other names. > > Can we for example modify get_subjectaltname to get the type based on > CertificateExtension object's oid or oid_tag attributes? No, see above. > > I would rather see get_subjectaltname return solid type like > CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing > descriptions. It would be more readable, too. Done. > > Martin > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.6-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.6-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 14427 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:04:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:04:26 +0200 Subject: [Freeipa-devel] [PATCH] 654 webui: fix SSH Key widget update Message-ID: <539853DA.1090504@redhat.com> Update widget status text on update. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0654-webui-fix-SSH-Key-widget-update.patch Type: text/x-patch Size: 1156 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:05:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:05:28 +0200 Subject: [Freeipa-devel] [PATCH] 655 webui: move RPC result extraction logic to Adapter Message-ID: <53985418.9050700@redhat.com> It enables declarative extraction of values from partial results of a batch commands and also further extensibility in custom adapters. The default adapter has detection logic for this extraction so it can use bare record or extract data from normal or batch RPC command. Minor change of user plugin fixed: https://fedorahosted.org/freeipa/ticket/4355 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0655-webui-move-RPC-result-extraction-logic-to-Adapter.patch Type: text/x-patch Size: 20451 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:07:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:07:09 +0200 Subject: [Freeipa-devel] [PATCH] 656 webui: handle "unknown" result of automember-default-group-show Message-ID: <5398547D.3090704@redhat.com> Interface for setting default group is hidden when user doesn't have necessary rights or if there is some error while loading the state. https://fedorahosted.org/freeipa/ticket/4356 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0656-webui-handle-unknown-result-of-automember-default-gr.patch Type: text/x-patch Size: 1954 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:08:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:08:15 +0200 Subject: [Freeipa-devel] [PATCH] 657 webui: control sudo rule deny command tables by category switch Message-ID: <539854BF.9020800@redhat.com> `memberdenycmd_sudocmd` and `memberdenycmd_sudocmdgroup` tables are now enabled/disabled based on `cmdcategory` as well. https://fedorahosted.org/freeipa/ticket/4361 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0657-webui-control-sudo-rule-deny-command-tables-by-categ.patch Type: text/x-patch Size: 9499 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:09:00 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:09:00 +0200 Subject: [Freeipa-devel] [PATCH] 658 webui: add sudoorder field to sudo rule page Message-ID: <539854EC.8020201@redhat.com> part of https://fedorahosted.org/freeipa/ticket/2348 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0658-webui-add-sudoorder-field-to-sudo-rule-page.patch Type: text/x-patch Size: 1227 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 11 13:19:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:19:56 +0200 Subject: [Freeipa-devel] [PATCH] 659-666 Support of password reset with OTP Message-ID: <5398577C.8090605@redhat.com> Patch set contains both API/server and Web UI parts. [PATCH] 659 ldap2: add otp support to modify_password [PATCH] 660 rpcserver: add otp support to change_password handler [PATCH] 661 ipa-passwd: add OTP support [PATCH] 662 webui: support password change with OTP in login screen [PATCH] 663 webui: placeholder attribute support in textbox and textarea [PATCH] 664 webui: add placeholders to login screen [PATCH] 665 webui: rebase user password dialog on password dialog and add otp support [PATCH] 666 webui: support otp in reset_password.html https://fedorahosted.org/freeipa/ticket/4262 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0666-webui-support-otp-in-reset_password.html.patch Type: text/x-patch Size: 3033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0665-webui-rebase-user-password-dialog-on-password-dialog.patch Type: text/x-patch Size: 12482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0664-webui-add-placeholders-to-login-screen.patch Type: text/x-patch Size: 4753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0663-webui-placeholder-attribute-support-in-textbox-and-t.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0662-webui-support-password-change-with-OTP-in-login-scre.patch Type: text/x-patch Size: 6041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0661-ipa-passwd-add-OTP-support.patch Type: text/x-patch Size: 2705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0660-rpcserver-add-otp-support-to-change_password-handler.patch Type: text/x-patch Size: 2608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0659-ldap2-add-otp-support-to-modify_password.patch Type: text/x-patch Size: 1496 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 11 13:47:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Jun 2014 15:47:42 +0200 Subject: [Freeipa-devel] [PATCH 0065] Regression fix in host.py In-Reply-To: <1402414717.14226.1.camel@ipa.example.com> References: <1402410783.2273.4.camel@unused-4-145.brq.redhat.com> <1402414717.14226.1.camel@ipa.example.com> Message-ID: <53985DFE.6050409@redhat.com> On 06/10/2014 05:38 PM, Nathaniel McCallum wrote: > On Tue, 2014-06-10 at 16:33 +0200, Martin Basti wrote: >> DNS requires absolute zone name, host must provide it. >> IDNA patch caused this. >> >> Patch attached. > > ACK Pushed to master. Martin From pvoborni at redhat.com Wed Jun 11 13:52:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Jun 2014 15:52:47 +0200 Subject: [Freeipa-devel] [PATCH 0064] python-kerberos update in freeipa.spec.in In-Reply-To: <1402322910.2883.5.camel@ipa.example.com> References: <1402322396.2279.8.camel@unused-4-145.brq.redhat.com> <1402322910.2883.5.camel@ipa.example.com> Message-ID: <53985F2F.1000006@redhat.com> On 9.6.2014 16:08, Nathaniel McCallum wrote: > On Mon, 2014-06-09 at 15:59 +0200, Martin Basti wrote: >> Patch attached. >> View the patch for more details. > > ACK > Pushed to master: d2d0da01526af41739e0eeef4273fcb71e40abc9 -- Petr Vobornik From edewata at redhat.com Wed Jun 11 15:17:30 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 11 Jun 2014 10:17:30 -0500 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <53983820.2040606@redhat.com> References: <5374C821.60004@redhat.com> <5397745F.3060100@redhat.com> <53983820.2040606@redhat.com> Message-ID: <5398730A.1010907@redhat.com> On 6/11/2014 6:06 AM, Petr Vobornik wrote: >> 1. If I recall correctly, a new user is required to change the password >> upon the initial login. This can be done with kinit, but can this be >> done via UI too? Right now a new user will get a login error without any >> message or link to reset the password. > > It works for me. There was a ticket > https://fedorahosted.org/freeipa/ticket/4339 which corresponds to the > description. > > Or it could be related to: > https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=c41b782bc59cd0cb70cbd62d543f9c538109d410 > (if you use an IPA version before the revert) I just built the master yesterday. Let me see if I can reproduce it with a newer build. -- Endi S. Dewata From mbasti at redhat.com Wed Jun 11 15:41:47 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 11 Jun 2014 17:41:47 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> Message-ID: <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-02 at 13:57 +0200, Martin Basti wrote: > Rebased patches attached > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0052-3-Separate-master-and-forward-DNS-zones.patch Type: text/x-patch Size: 21325 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0053-3-Prevent-commands-to-modify-different-type-of-a-zone.patch Type: text/x-patch Size: 11522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-3-Create-BASE-zone-class.patch Type: text/x-patch Size: 38687 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0055-3-Tests-DNS-forward-zones.patch Type: text/x-patch Size: 29038 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 11 16:01:39 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:01:39 -0400 Subject: [Freeipa-devel] [PATCH] 658 webui: add sudoorder field to sudo rule page In-Reply-To: <539854EC.8020201@redhat.com> References: <539854EC.8020201@redhat.com> Message-ID: <1402502499.2955.6.camel@ipa.example.com> On Wed, 2014-06-11 at 15:09 +0200, Petr Vobornik wrote: > part of > https://fedorahosted.org/freeipa/ticket/2348 ACK From npmccallum at redhat.com Wed Jun 11 16:02:53 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:02:53 -0400 Subject: [Freeipa-devel] [PATCH] 656 webui: handle "unknown" result of automember-default-group-show In-Reply-To: <5398547D.3090704@redhat.com> References: <5398547D.3090704@redhat.com> Message-ID: <1402502573.2955.7.camel@ipa.example.com> On Wed, 2014-06-11 at 15:07 +0200, Petr Vobornik wrote: > Interface for setting default group is hidden when user doesn't have > necessary rights or if there is some error while loading the state. > > https://fedorahosted.org/freeipa/ticket/4356 ACK From npmccallum at redhat.com Wed Jun 11 16:03:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:03:29 -0400 Subject: [Freeipa-devel] [PATCH] 654 webui: fix SSH Key widget update In-Reply-To: <539853DA.1090504@redhat.com> References: <539853DA.1090504@redhat.com> Message-ID: <1402502609.2955.8.camel@ipa.example.com> On Wed, 2014-06-11 at 15:04 +0200, Petr Vobornik wrote: > Update widget status text on update. ACK From npmccallum at redhat.com Wed Jun 11 16:12:30 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:12:30 -0400 Subject: [Freeipa-devel] user certificates In-Reply-To: <539851B8.1060102@redhat.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> <539851B8.1060102@redhat.com> Message-ID: <1402503150.2955.10.camel@ipa.example.com> On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote: > On 06/11/2014 04:02 AM, Fraser Tweedale wrote: > > There are other use cases for user certificates, e.g. client > > authentication for HTTP or other network services. Perhaps you know > > of others - in which case let us know. > > 802.11 wireless authentication using EAP-TLS > > A common discussion on the RADIUS mailing lists is the desire to deploy > using EAP-TLS but the difficulty of provisioning user certs is always > the stumbling block. Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of mechanisms to support older OSes (mainly Windows). Nathaniel From tbordaz at redhat.com Wed Jun 11 16:16:45 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 11 Jun 2014 18:16:45 +0200 Subject: [Freeipa-devel] [PATCH] 0001 - User Life Cycle (stageuser workflow) Message-ID: <539880ED.4060906@redhat.com> Hello, This patch (RFE 3813) is related to the stageuser plugin that handle the workflow from/to Stage users. ipa stageuser-add [--from-delete] [] ipa stageuser-mod ipa stageuser-del ipa stageuser-find ipa stageuser-show ipa stageuser-activate What it contains is: * Creation of Stage,Active, Delete containers * configuration of attribute uniqueness (krbPrincipalName, krbCanonicalName and ipaUniqueId) on Active container * the stageuser CLIs What is missing: * Configuration of attribute uniqueness (uid) to scope Active/Delete containers * Configuration of IPA uniqueID generator to scope Active container * Configuration of DNA plugin to scope Active container thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbordaz-0001-RFE-3813-User-Life-Cycle-stageuser.patch Type: text/x-patch Size: 38971 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 11 16:30:03 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:30:03 -0400 Subject: [Freeipa-devel] [PATCH] 657 webui: control sudo rule deny command tables by category switch In-Reply-To: <539854BF.9020800@redhat.com> References: <539854BF.9020800@redhat.com> Message-ID: <1402504203.2955.12.camel@ipa.example.com> On Wed, 2014-06-11 at 15:08 +0200, Petr Vobornik wrote: > `memberdenycmd_sudocmd` and `memberdenycmd_sudocmdgroup` tables are now > enabled/disabled based on `cmdcategory` as well. > > https://fedorahosted.org/freeipa/ticket/4361 ACK I'm curious about the lack of space around the '+' operator in: + container.append(title+': '); Is that the right style? Nathaniel From npmccallum at redhat.com Wed Jun 11 16:36:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:36:28 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402490860.29921.11.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> Message-ID: <1402504588.2955.13.camel@ipa.example.com> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote: > > On 06/11/2014 02:48 AM, Simo Sorce wrote: > > > I ma getting a failure to login in the UI > > > > > > The error is somewhere in ldap/schema/subentry.py > > > > > > KeyError: 'ipattokenhotp' > > > > > > A schema update may have failed I guess ? > > > but running ipa-ldap-updater doesn't help ... > > > > > > Ideas ? > > > > Do you have the full traceback? > > This is in my tail output: > > [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: i18n_messages(): SUCCESS > [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: config_show(): SUCCESS > [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: user_find(None, whoami=True, all=True): SUCCESS > [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: env(None): SUCCESS > [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: dns_is_enabled(): SUCCESS > [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: trustconfig_show(): NotFound > [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: batch(({u'params': ((), {}), u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): SUCCESS > [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: KeyError: 'ipatokenhotp' > [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent call last): > [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute > [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = self.Command[name](*args, **options) > [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ > [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, **options) > [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = self.execute(*args, **options) > [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute > [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in > [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 57, in json_serialize > [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return json_serialize(obj.__json__()) > [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 649, in __json__ > [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) > [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types > [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = self.sed[ObjectClass][object_class_oid] > [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp' > [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, object=u'all'): KeyError > [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, command=u'all'): SUCCESS Do the installed schema files have ipatokenHOTP? Did you dump the schema from 389DS to see if this object class is present? Nathaniel From npmccallum at redhat.com Wed Jun 11 16:37:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:37:21 -0400 Subject: [Freeipa-devel] [PATCH 0018] Fix --ttl description for DNS zones In-Reply-To: <53983CF7.9040905@redhat.com> References: <53983CF7.9040905@redhat.com> Message-ID: <1402504641.2955.14.camel@ipa.example.com> On Wed, 2014-06-11 at 13:26 +0200, Petr Spacek wrote: > Hello, > > Fix --ttl description for DNS zones > > TTL specified in idnsZone object class affects all records at zone apex, > not only SOA record. > > I have realized that current description is incorrect when I was doing doc review. ACK From pviktori at redhat.com Wed Jun 11 16:39:40 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 18:39:40 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed Message-ID: <5398864C.9020708@redhat.com> Patch 0578 does the conversion Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and provides permissions needed for automatic enrollment (from http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0578-Convert-Host-default-permissions-to-managed.patch Type: text/x-patch Size: 20700 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0579-host-permissions-Allow-writing-attributes-needed-for.patch Type: text/x-patch Size: 4946 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 11 16:43:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:43:00 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <53982B8C.1060206@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <53982B8C.1060206@redhat.com> Message-ID: <1402504980.2955.16.camel@ipa.example.com> On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote: > On 05/13/2014 04:33 PM, Jan Cholasta wrote: > > On 12.5.2014 21:02, Nathaniel McCallum wrote: > >> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: > >>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: > >>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: > >>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: > >>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: > >>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: > >>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: > >>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: > >>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the > >>>>>>>>>>> introduction of SELFDN support. > >>>>>>>>>>> > >>>>>>>>>>> Admins, as before, have full access to all token permissions. > >>>>>>>>>>> > >>>>>>>>>>> Normal users have read/search/compare access to all of the > >>>>>>>>>>> non-secret > >>>>>>>>>>> data for tokens assigned to them, whether protected or > >>>>>>>>>>> non-protected. > >>>>>>>>>>> Users can add or delete non-protected tokens and modify most > >>>>>>>>>>> of their > >>>>>>>>>>> metadata. However they cannot create, delete or modify > >>>>>>>>>>> protected tokens. > >>>>>>>>>>> Regardless of whether the token is protected or not, users > >>>>>>>>>>> cannot change > >>>>>>>>>>> a token's ownership or unique identity. > >>>>>>>>>>> > >>>>>>>>>>> In contrast, admins can create protected tokens. This > >>>>>>>>>>> protects the token > >>>>>>>>>>> from deletion or modification when assigned to users. > >>>>>>>>>>> Additionally, when > >>>>>>>>>>> a user account is deleted, the assigned non-protected tokens > >>>>>>>>>>> are deleted > >>>>>>>>>>> but the protected tokens are merely orphaned. This permits > >>>>>>>>>>> the token to > >>>>>>>>>>> be reassigned without having to recreate it. This last point is > >>>>>>>>>>> particularly useful in the case of hardware tokens. > >>>>>>>>>>> > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 > >>>>>>>>>>> > >>>>>>>>>>> NOTE: This patch depends on my patch 0048. > >>>>>>>>>> This new version makes ipatokenDisabled visible for token > >>>>>>>>>> owners. It is > >>>>>>>>>> also writable if the token is non-protected. This > >>>>>>>>>> additionally fixes: > >>>>>>>>>> > >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 > >>>>>>>>> This new version changes the way the default value of > >>>>>>>>> protected is setup > >>>>>>>>> in accordance with the changes made for the review of my patch > >>>>>>>>> 0048.2. > >>>>>>>>> > >>>>>>>>> Nathaniel > >>>>>>>> Is using the ipatokenprotected attribute the final design? > >>>>>>> No. Alternate designs are welcome. The code is easy enough to > >>>>>>> modify. > >>>>>>> > >>>>>>>> I did not dig too deep into this, but I think it might be > >>>>>>>> better to > >>>>>>>> instead use the managedby attribute on a token to limit who can > >>>>>>>> delete > >>>>>>>> (or administer in other way) the token. On otptoken-add, > >>>>>>>> managedby would > >>>>>>>> be set to the "whoami" user DN, unless run with --protected, in > >>>>>>>> which > >>>>>>>> case managedby would be left empty. Then, when deleting a user, > >>>>>>>> the > >>>>>>>> token would be deleted only if the user manages the token. > >>>>>>> It seems to me that the mechanics of this are roughly the same as > >>>>>>> protected, just with a different syntax. The cost of this is more > >>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses > >>>>>>> (is > >>>>>>> this possible?) instead of a simple filter. If there is a clear > >>>>>>> benefit, > >>>>>>> we can justify the more obtuse syntax. > >>>>>> > >>>>>> We usually try not to create new attributes until it is fully > >>>>>> justified. > >>>>>> I would like Simo to chime in on this. > >>>>> > >>>>> I would also prefer to reuse existing attributes and mechanism if > >>>>> possible and if it will not preclude future work. > >>>>> > >>>>> In this case, it "sounds" like managed-by has the appropriate > >>>>> meaning: > >>>>> "who manages the token ?" -> myself, admin, other, none ? > >>>>> > >>>>> Nathaniel can you send 2 lines showing the difference in ACIs between > >>>>> using managed-by vs a new attribute ? > >>>> > >>>> These are the ACIs using the protected mechanism: > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > >>>> ipatokenModel > >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > >>>> acl "Users can read basic token info"; allow (read, search, compare) > >>>> userattr = "ipatokenOwner#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > >>>> "Users can > >>>> see HOTP details"; allow (read, search, compare) userattr = > >>>> "ipatokenOwner#USERDN";) > >>>> > >>>> aci: (targetfilter = > >>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = > >>>> "description || ipatokenDisabled || ipatokenNotBefore || > >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; > >>>> allow (write) userattr = "ipatokenOwner#USERDN";) > >>>> > >>>> aci: (target = > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version > >>>> 3.0; > >>>> acl "Users can create and delete tokens"; allow (add, delete) > >>>> userattr = > >>>> "ipatokenOwner#SELFDN";) > >>>> > >>>> This is what they look like using managedBy (I have not tested this): > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > >>>> ipatokenModel > >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > >>>> acl "Users can read basic token info"; allow (read, search, compare) > >>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) > >>>> userattr = "managedBy#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow > >>>> (read, search, compare) userattr = "managedBy#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > >>>> "Users can > >>>> see HOTP details"; allow (read, search, compare) userattr = > >>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > >>>> "managedBy#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > >>>> "description || ipatokenDisabled || ipatokenNotBefore || > >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > >>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token > >>>> info"; > >>>> allow (write) userattr = "managedBy#USERDN";) > >>>> > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > >>>> "Managers can delete tokens"; allow (delete) userattr = > >>>> "managedBy#USERDN";) > >>>> > >>>> aci: (target = > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > >>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > >>>> and > >>>> userattr = "managedBy#SELFDN";) > >>>> > >>>> In short: > >>>> 1. Owner and manager get read, search and compare. > >>>> 2. Manager gets write (to select attributes) and delete. > >>>> 3. Users can create self-managed tokens for themselves only. > >>>> > >>>> The otptoken-add command should gain the following defaults: > >>>> 1. The owner defaults to the user adding the token. > >>>> 2. If owner == user adding token, managedBy defaults to owner. > >>>> 3. Otherwise, managedBy defaults to None. > >>>> > >>>> This means that if neither owner nor managedBy are specified, the > >>>> default is a self-owned, self-managed token. Likewise, if a different > >>>> owner is specified, no manager is assumed. > >>>> > >>>> rcrit expresses worry that ipalib's ACI parser may not handle the > >>>> above > >>>> syntax. This will become clear during testing if we want this > >>>> approach. > >>>> > >>>> Does this look sane? > >>> > >>> I am not entirely sure your ACI syntax is always right for the second > >>> set. and perhaps we want to duplicate ACIs in some cases (once for > >>> owner > >>> once for manager). > >>> > >>> I think the read ACIs do not need to list managedby ? Do we plan to > >>> have > >>> a manager that is another regular user but not the owner nor an admin ? > >>> > >>> In any case I prefer the sytnax that uses managedby, as it has more > >>> potential. > >> > >> Attached is a new version of the patch which implements the feature > >> using managedBy instead of ipatokenProtected. One important thing needs > >> to be said about this patch. I am not exposing managedBy in either the > >> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > >> expose this similar to owner or as a relationship? > > > > I would expose it, as a relationship. (Note that ipatokenowner should > > ideally be represented as a relationship too, but the framework does > > not support 1-to-many relationships ATM.) > > > > > > Just curious, why are the ACIs divided like this: > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl > > "Users/managers can read basic token info"; allow (read, search, > > compare) userattr = "ipatokenOwner#USERDN" or userattr = > > "managedBy#USERDN";) > > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > > "ipatokenOTPalgorithm || ipatokenOTPdigits || > > ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > > details"; allow (read, search, compare) userattr = > > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > > "Users/managers can see HOTP details"; allow (read, search, compare) > > userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > > > IMHO you could make them less complex by dividing them like this: > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > ipatokenModel || ipatokenSerial || ipatokenOwner || > > ipatokenOTPalgorithm || ipatokenOTPdigits || > > ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token > > details"; allow (read, search, compare) userattr = > > "ipatokenOwner#USERDN";) > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > ipatokenModel || ipatokenSerial || ipatokenOwner || > > ipatokenOTPalgorithm || ipatokenOTPdigits || > > ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token > > details"; allow (read, search, compare) userattr = "managedBy#USERDN";) > do you mean aci: (targetfilter = > "(|(objectClass=ipaToken)(objectClass=ipatokenTOTP)(objectClass=ipatokenHOTP))") > or are the attrs like ipatokenOTPdigits also in the ipatoken objectclass ? > > Ludwig, objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) X-ORIGIN 'IPA OTP') objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP') objectClasses: (2.16.840.1.113730.3.8.16.2.5 NAME 'ipatokenHOTP' SUP ipaToken STRUCTURAL DESC 'HOTP Token Type' MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenHOTPcounter) X-ORIGIN 'IPA OTP') Nathaniel From simo at redhat.com Wed Jun 11 16:45:15 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 12:45:15 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402504588.2955.13.camel@ipa.example.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> Message-ID: <1402505115.13617.4.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote: > > > On 06/11/2014 02:48 AM, Simo Sorce wrote: > > > > I ma getting a failure to login in the UI > > > > > > > > The error is somewhere in ldap/schema/subentry.py > > > > > > > > KeyError: 'ipattokenhotp' > > > > > > > > A schema update may have failed I guess ? > > > > but running ipa-ldap-updater doesn't help ... > > > > > > > > Ideas ? > > > > > > Do you have the full traceback? > > > > This is in my tail output: > > > > [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: i18n_messages(): SUCCESS > > [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: config_show(): SUCCESS > > [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: user_find(None, whoami=True, all=True): SUCCESS > > [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: env(None): SUCCESS > > [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: dns_is_enabled(): SUCCESS > > [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: trustconfig_show(): NotFound > > [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: batch(({u'params': ((), {}), u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): SUCCESS > > [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: KeyError: 'ipatokenhotp' > > [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent call last): > > [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute > > [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = self.Command[name](*args, **options) > > [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ > > [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, **options) > > [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > > [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = self.execute(*args, **options) > > [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute > > [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in > > [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 57, in json_serialize > > [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return json_serialize(obj.__json__()) > > [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 649, in __json__ > > [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) > > [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types > > [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = self.sed[ObjectClass][object_class_oid] > > [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp' > > [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, object=u'all'): KeyError > > [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, command=u'all'): SUCCESS > > Do the installed schema files have ipatokenHOTP? Did you dump the schema > from 389DS to see if this object class is present? They are not. The schema files in /usr/share/ipa do have the objectclasses, but the server schema has not been updated (or the update failed). Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Jun 11 16:47:37 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:47:37 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402505115.13617.4.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> Message-ID: <1402505257.2955.17.camel@ipa.example.com> On Wed, 2014-06-11 at 12:45 -0400, Simo Sorce wrote: > On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > > On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > > On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote: > > > > On 06/11/2014 02:48 AM, Simo Sorce wrote: > > > > > I ma getting a failure to login in the UI > > > > > > > > > > The error is somewhere in ldap/schema/subentry.py > > > > > > > > > > KeyError: 'ipattokenhotp' > > > > > > > > > > A schema update may have failed I guess ? > > > > > but running ipa-ldap-updater doesn't help ... > > > > > > > > > > Ideas ? > > > > > > > > Do you have the full traceback? > > > > > > This is in my tail output: > > > > > > [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: i18n_messages(): SUCCESS > > > [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: config_show(): SUCCESS > > > [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: user_find(None, whoami=True, all=True): SUCCESS > > > [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: env(None): SUCCESS > > > [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: dns_is_enabled(): SUCCESS > > > [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: trustconfig_show(): NotFound > > > [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: batch(({u'params': ((), {}), u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): SUCCESS > > > [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: KeyError: 'ipatokenhotp' > > > [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent call last): > > > [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute > > > [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = self.Command[name](*args, **options) > > > [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ > > > [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, **options) > > > [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > > > [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = self.execute(*args, **options) > > > [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute > > > [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > > [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in > > > [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > > [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 57, in json_serialize > > > [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return json_serialize(obj.__json__()) > > > [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 649, in __json__ > > > [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) > > > [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types > > > [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = self.sed[ObjectClass][object_class_oid] > > > [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp' > > > [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, object=u'all'): KeyError > > > [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, command=u'all'): SUCCESS > > > > Do the installed schema files have ipatokenHOTP? Did you dump the schema > > from 389DS to see if this object class is present? > > They are not. The schema files in /usr/share/ipa do have the > objectclasses, but the server schema has not been updated (or the update > failed). Hrm. Does it have ipatokenTOTP? From pviktori at redhat.com Wed Jun 11 16:48:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 18:48:45 +0200 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402505115.13617.4.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> Message-ID: <5398886D.9020506@redhat.com> On 06/11/2014 06:45 PM, Simo Sorce wrote: > On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: >> >> Do the installed schema files have ipatokenHOTP? Did you dump the schema >> from 389DS to see if this object class is present? > > They are not. The schema files in /usr/share/ipa do have the > objectclasses, but the server schema has not been updated (or the update > failed). Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or send it and I can check. -- Petr? From npmccallum at redhat.com Wed Jun 11 16:49:06 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 12:49:06 -0400 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <53981C8E.6000600@redhat.com> References: <53981C8E.6000600@redhat.com> Message-ID: <1402505346.2955.19.camel@ipa.example.com> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: > Hi, > > As due to possible race conditions, the preop.pin might not be > written in the CS.cfg at the time installer tries to read it. > > In case no value for preop.pin was found, retry until timeout > was reached. > > https://fedorahosted.org/freeipa/ticket/3382 > > (applies on ipa-3-0 branch) There is inconsistent spacing around '='. For instance: + f=open(filename, 'r') + data = f.read() Also, I'm fairly certain this is incorrect: + total_timeout =+ 1 Nathaniel From simo at redhat.com Wed Jun 11 16:54:16 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 12:54:16 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402505257.2955.17.camel@ipa.example.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <1402505257.2955.17.camel@ipa.example.com> Message-ID: <1402505656.13617.6.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 12:47 -0400, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 12:45 -0400, Simo Sorce wrote: > > On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > > > On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > > > On Wed, 2014-06-11 at 11:09 +0200, Petr Viktorin wrote: > > > > > On 06/11/2014 02:48 AM, Simo Sorce wrote: > > > > > > I ma getting a failure to login in the UI > > > > > > > > > > > > The error is somewhere in ldap/schema/subentry.py > > > > > > > > > > > > KeyError: 'ipattokenhotp' > > > > > > > > > > > > A schema update may have failed I guess ? > > > > > > but running ipa-ldap-updater doesn't help ... > > > > > > > > > > > > Ideas ? > > > > > > > > > > Do you have the full traceback? > > > > > > > > This is in my tail output: > > > > > > > > [Tue Jun 10 20:45:06.136312 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: i18n_messages(): SUCCESS > > > > [Tue Jun 10 20:45:06.163805 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: config_show(): SUCCESS > > > > [Tue Jun 10 20:45:06.197784 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: user_find(None, whoami=True, all=True): SUCCESS > > > > [Tue Jun 10 20:45:06.198365 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: env(None): SUCCESS > > > > [Tue Jun 10 20:45:06.201735 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: dns_is_enabled(): SUCCESS > > > > [Tue Jun 10 20:45:06.203439 2014] [:error] [pid 1219] ipa: INFO: admin at IPA.DEV.LAN: batch: trustconfig_show(): NotFound > > > > [Tue Jun 10 20:45:06.204018 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: batch(({u'params': ((), {}), u'method': u'i18n_messages'}, {u'params': ((), {}), u'method': u'config_show'}, {u'params': ((), {u'all': True, u'whoami': True}), u'method': u'user_find'}, {u'params': ((), {}), u'method': u'env'}, {u'params': ((), {}), u'method': u'dns_is_enabled'}, {u'params': ((), {}), u'method': u'trustconfig_show'})): SUCCESS > > > > [Tue Jun 10 20:45:07.552739 2014] [:error] [pid 1220] ipa: ERROR: non-public: KeyError: 'ipatokenhotp' > > > > [Tue Jun 10 20:45:07.552807 2014] [:error] [pid 1220] Traceback (most recent call last): > > > > [Tue Jun 10 20:45:07.552815 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute > > > > [Tue Jun 10 20:45:07.552821 2014] [:error] [pid 1220] result = self.Command[name](*args, **options) > > > > [Tue Jun 10 20:45:07.552826 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ > > > > [Tue Jun 10 20:45:07.552831 2014] [:error] [pid 1220] ret = self.run(*args, **options) > > > > [Tue Jun 10 20:45:07.552834 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run > > > > [Tue Jun 10 20:45:07.552839 2014] [:error] [pid 1220] result = self.execute(*args, **options) > > > > [Tue Jun 10 20:45:07.552843 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute > > > > [Tue Jun 10 20:45:07.552848 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > > > [Tue Jun 10 20:45:07.552852 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in > > > > [Tue Jun 10 20:45:07.552856 2014] [:error] [pid 1220] (o.name, json_serialize(o)) for o in self.api.Object() > > > > [Tue Jun 10 20:45:07.552861 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 57, in json_serialize > > > > [Tue Jun 10 20:45:07.552865 2014] [:error] [pid 1220] return json_serialize(obj.__json__()) > > > > [Tue Jun 10 20:45:07.552870 2014] [:error] [pid 1220] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 649, in __json__ > > > > [Tue Jun 10 20:45:07.552875 2014] [:error] [pid 1220] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) > > > > [Tue Jun 10 20:45:07.552879 2014] [:error] [pid 1220] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types > > > > [Tue Jun 10 20:45:07.552884 2014] [:error] [pid 1220] object_class = self.sed[ObjectClass][object_class_oid] > > > > [Tue Jun 10 20:45:07.552903 2014] [:error] [pid 1220] KeyError: 'ipatokenhotp' > > > > [Tue Jun 10 20:45:07.553226 2014] [:error] [pid 1220] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, object=u'all'): KeyError > > > > [Tue Jun 10 20:45:07.936063 2014] [:error] [pid 1219] ipa: INFO: [jsonserver_session] admin at IPA.DEV.LAN: json_metadata(None, None, command=u'all'): SUCCESS > > > > > > Do the installed schema files have ipatokenHOTP? Did you dump the schema > > > from 389DS to see if this object class is present? > > > > They are not. The schema files in /usr/share/ipa do have the > > objectclasses, but the server schema has not been updated (or the update > > failed). > > Hrm. Does it have ipatokenTOTP? Yes, searching and grepping (-i "ipatok") cn=schema I get the following objectclasses: ipaToken, ipatokenTOTP, ipatokenRadiusProxyUser, ipatokenRadiusProxyConfiguration but ipatokenHOTP is missing ... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 16:58:45 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 12:58:45 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <5398886D.9020506@redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> Message-ID: <1402505925.13617.8.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote: > On 06/11/2014 06:45 PM, Simo Sorce wrote: > > On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > >> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > >> > >> Do the installed schema files have ipatokenHOTP? Did you dump the schema > >> from 389DS to see if this object class is present? > > > > They are not. The schema files in /usr/share/ipa do have the > > objectclasses, but the server schema has not been updated (or the update > > failed). > > Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or > send it and I can check. Uhmm it failed because I previously had one of the getkeytab attributes in the server but we later changed its OID when the feature was deferred... sigh ... I now have removed the offending attributes by turning off dirsrv and manually removing them from 99user.ldif, but running ipa-ldap-updater does not seem to do try to add the missing schema ... Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Wed Jun 11 17:07:22 2014 From: jdennis at redhat.com (John Dennis) Date: Wed, 11 Jun 2014 13:07:22 -0400 Subject: [Freeipa-devel] user certificates In-Reply-To: <1402503150.2955.10.camel@ipa.example.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> <539851B8.1060102@redhat.com> <1402503150.2955.10.camel@ipa.example.com> Message-ID: <53988CCA.4000006@redhat.com> On 06/11/2014 12:12 PM, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote: >> On 06/11/2014 04:02 AM, Fraser Tweedale wrote: >>> There are other use cases for user certificates, e.g. client >>> authentication for HTTP or other network services. Perhaps you know >>> of others - in which case let us know. >> >> 802.11 wireless authentication using EAP-TLS >> >> A common discussion on the RADIUS mailing lists is the desire to deploy >> using EAP-TLS but the difficulty of provisioning user certs is always >> the stumbling block. > > Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of > mechanisms to support older OSes (mainly Windows). Because EAP-TLS is what is used for mutual client/server authentication using PKI. EAP-TLS is supported on more legacy OS's (e.g. older Windows). Microsoft only started supporting EAP-TTLS in Windows 8. EAP-TLS is considered very secure and my (unconfirmed) understanding is it's somewhat common with enterprise Windows deployments because Microsoft makes it easy to provision client certs. EAP-TTLS is primarily to set up a tunnel for other (less secure) methods so that sensitive information is not in the clear. Note the leading T in TTLS refers to "tunnel". Client authentication is optional with EAP-TTLS. You could establish a TLS tunnel with EAP-TTLS and then run EAP-TLS inside the tunnel but the two TLS sessions make it much less efficient, the advantage is the username can be anonymous with EAP-TTLS/EAP-TLS if that's actually a concern. If you're not concerned about user anonymity (outer identity) then there is no value in establishing a tunnel to run other authentication protocols in, with EAP-TLS simply being able to complete the SSL handshake (with the required client cert) is sufficient to establish authentication. -- John From pviktori at redhat.com Wed Jun 11 17:08:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 19:08:33 +0200 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402505925.13617.8.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> Message-ID: <53988D11.9080903@redhat.com> On 06/11/2014 06:58 PM, Simo Sorce wrote: > On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote: >> On 06/11/2014 06:45 PM, Simo Sorce wrote: >>> On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: >>>> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: >> >>>> >>>> Do the installed schema files have ipatokenHOTP? Did you dump the schema >>>> from 389DS to see if this object class is present? >>> >>> They are not. The schema files in /usr/share/ipa do have the >>> objectclasses, but the server schema has not been updated (or the update >>> failed). >> >> Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or >> send it and I can check. > > Uhmm it failed because I previously had one of the getkeytab attributes > in the server but we later changed its OID when the feature was > deferred... sigh ... Yeah, that would be a problem. > I now have removed the offending attributes by turning off dirsrv and > manually removing them from 99user.ldif, but running ipa-ldap-updater > does not seem to do try to add the missing schema ... Are you saying there's nothing about schema in the log? -- Petr? From npmccallum at redhat.com Wed Jun 11 17:14:00 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 13:14:00 -0400 Subject: [Freeipa-devel] user certificates In-Reply-To: <53988CCA.4000006@redhat.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> <539851B8.1060102@redhat.com> <1402503150.2955.10.camel@ipa.example.com> <53988CCA.4000006@redhat.com> Message-ID: <1402506840.2955.21.camel@ipa.example.com> On Wed, 2014-06-11 at 13:07 -0400, John Dennis wrote: > On 06/11/2014 12:12 PM, Nathaniel McCallum wrote: > > On Wed, 2014-06-11 at 08:55 -0400, John Dennis wrote: > >> On 06/11/2014 04:02 AM, Fraser Tweedale wrote: > >>> There are other use cases for user certificates, e.g. client > >>> authentication for HTTP or other network services. Perhaps you know > >>> of others - in which case let us know. > >> > >> 802.11 wireless authentication using EAP-TLS > >> > >> A common discussion on the RADIUS mailing lists is the desire to deploy > >> using EAP-TLS but the difficulty of provisioning user certs is always > >> the stumbling block. > > > > Why EAP-TLS over EAP-TTLS? Legacy support? You can use a combo of > > mechanisms to support older OSes (mainly Windows). > > Because EAP-TLS is what is used for mutual client/server authentication > using PKI. EAP-TLS is supported on more legacy OS's (e.g. older > Windows). Microsoft only started supporting EAP-TTLS in Windows 8. > EAP-TLS is considered very secure and my (unconfirmed) understanding is *cough*heartbleed*cough* ;) > it's somewhat common with enterprise Windows deployments because > Microsoft makes it easy to provision client certs. > > EAP-TTLS is primarily to set up a tunnel for other (less secure) methods > so that sensitive information is not in the clear. Note the leading T in > TTLS refers to "tunnel". Client authentication is optional with > EAP-TTLS. You could establish a TLS tunnel with EAP-TTLS and then run > EAP-TLS inside the tunnel but the two TLS sessions make it much less > efficient, the advantage is the username can be anonymous with > EAP-TTLS/EAP-TLS if that's actually a concern. If you're not concerned > about user anonymity (outer identity) then there is no value in > establishing a tunnel to run other authentication protocols in, with > EAP-TLS simply being able to complete the SSL handshake (with the > required client cert) is sufficient to establish authentication. Yes, this I understand. But in my experience, TTLS is being widely deployed in combination with an inner client authentication precisely because TLS was so hard to maintain. MS fought TTLS for a long time and eventually gave in in Windows 8 precisely because so many people were deploying TTLS with an inner authenticator. I can't think of a single example of a TLS deployment that can't be given a better user experience by migrating to TTLS (old Windows excluded of course). Nathaniel From simo at redhat.com Wed Jun 11 17:30:54 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 13:30:54 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <53988D11.9080903@redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> Message-ID: <1402507854.13617.10.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote: > On 06/11/2014 06:58 PM, Simo Sorce wrote: > > On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote: > >> On 06/11/2014 06:45 PM, Simo Sorce wrote: > >>> On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > >>>> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > >> > >>>> > >>>> Do the installed schema files have ipatokenHOTP? Did you dump the schema > >>>> from 389DS to see if this object class is present? > >>> > >>> They are not. The schema files in /usr/share/ipa do have the > >>> objectclasses, but the server schema has not been updated (or the update > >>> failed). > >> > >> Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or > >> send it and I can check. > > > > Uhmm it failed because I previously had one of the getkeytab attributes > > in the server but we later changed its OID when the feature was > > deferred... sigh ... > > Yeah, that would be a problem. > > > I now have removed the offending attributes by turning off dirsrv and > > manually removing them from 99user.ldif, but running ipa-ldap-updater > > does not seem to do try to add the missing schema ... > > Are you saying there's nothing about schema in the log? Not for following ipa-ldap-update runs ... they seem to actually fail with a timeout ... investigating. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 17:32:46 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 13:32:46 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402507854.13617.10.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> Message-ID: <1402507966.13617.12.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 13:30 -0400, Simo Sorce wrote: > On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote: > > On 06/11/2014 06:58 PM, Simo Sorce wrote: > > > On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote: > > >> On 06/11/2014 06:45 PM, Simo Sorce wrote: > > >>> On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > > >>>> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > >> > > >>>> > > >>>> Do the installed schema files have ipatokenHOTP? Did you dump the schema > > >>>> from 389DS to see if this object class is present? > > >>> > > >>> They are not. The schema files in /usr/share/ipa do have the > > >>> objectclasses, but the server schema has not been updated (or the update > > >>> failed). > > >> > > >> Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or > > >> send it and I can check. > > > > > > Uhmm it failed because I previously had one of the getkeytab attributes > > > in the server but we later changed its OID when the feature was > > > deferred... sigh ... > > > > Yeah, that would be a problem. > > > > > I now have removed the offending attributes by turning off dirsrv and > > > manually removing them from 99user.ldif, but running ipa-ldap-updater > > > does not seem to do try to add the missing schema ... > > > > Are you saying there's nothing about schema in the log? > > Not for following ipa-ldap-update runs ... they seem to actually fail > with a timeout ... investigating. Nevermind, I re-run ipa-ldap-updater and this time it is trying (but it found another of the old attributes I hadn't deleted. I don't know why previous attempts at running ipa-ldap-updater failed, but I did reboot the machine since ... so maybe there was something wonky about DS. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 17:36:37 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 13:36:37 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402507966.13617.12.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> Message-ID: <1402508197.13617.13.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 13:32 -0400, Simo Sorce wrote: > On Wed, 2014-06-11 at 13:30 -0400, Simo Sorce wrote: > > On Wed, 2014-06-11 at 19:08 +0200, Petr Viktorin wrote: > > > On 06/11/2014 06:58 PM, Simo Sorce wrote: > > > > On Wed, 2014-06-11 at 18:48 +0200, Petr Viktorin wrote: > > > >> On 06/11/2014 06:45 PM, Simo Sorce wrote: > > > >>> On Wed, 2014-06-11 at 12:36 -0400, Nathaniel McCallum wrote: > > > >>>> On Wed, 2014-06-11 at 08:47 -0400, Simo Sorce wrote: > > > >> > > > >>>> > > > >>>> Do the installed schema files have ipatokenHOTP? Did you dump the schema > > > >>>> from 389DS to see if this object class is present? > > > >>> > > > >>> They are not. The schema files in /usr/share/ipa do have the > > > >>> objectclasses, but the server schema has not been updated (or the update > > > >>> failed). > > > >> > > > >> Can you check /var/log/ipaupgrade.log to see why the upgrade failed? Or > > > >> send it and I can check. > > > > > > > > Uhmm it failed because I previously had one of the getkeytab attributes > > > > in the server but we later changed its OID when the feature was > > > > deferred... sigh ... > > > > > > Yeah, that would be a problem. > > > > > > > I now have removed the offending attributes by turning off dirsrv and > > > > manually removing them from 99user.ldif, but running ipa-ldap-updater > > > > does not seem to do try to add the missing schema ... > > > > > > Are you saying there's nothing about schema in the log? > > > > Not for following ipa-ldap-update runs ... they seem to actually fail > > with a timeout ... investigating. > > Nevermind, I re-run ipa-ldap-updater and this time it is trying (but it > found another of the old attributes I hadn't deleted. I don't know why > previous attempts at running ipa-ldap-updater failed, but I did reboot > the machine since ... so maybe there was something wonky about DS. Ok now ipa-ldap-updater does a lot more and passes through schema upgrade, however it fails again later complaining ipaVirtualOperation is an unknown object class .. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 17:54:10 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 13:54:10 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402508197.13617.13.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> Message-ID: <1402509250.13617.16.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: > Ok now ipa-ldap-updater does a lot more and passes through schema > upgrade, however it fails again later complaining ipaVirtualOperation > is > an unknown object class .. Ok I manually added ipaVirtualOperation to user99.ldif, and the updater made some more progress, but now complains it doesn't know about ipapermissionv2 ... Why is the updater failing to recognize that some schema is missing ? I see it checking the schema file but it tries to replace a few attributes (every time) where the only thing that differs is the X-ORIGIN and does nothing else ... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 18:17:48 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 14:17:48 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402509250.13617.16.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> <1402509250.13617.16.camel@willson.usersys.redhat.com> Message-ID: <1402510668.13617.18.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote: > On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: > > Ok now ipa-ldap-updater does a lot more and passes through schema > > upgrade, however it fails again later complaining ipaVirtualOperation > > is > > an unknown object class .. > > Ok I manually added ipaVirtualOperation to user99.ldif, and the updater > made some more progress, but now complains it doesn't know about > ipapermissionv2 ... > > Why is the updater failing to recognize that some schema is missing ? > I see it checking the schema file but it tries to replace a few > attributes (every time) where the only thing that differs is the > X-ORIGIN and does nothing else ... Ok after adding a few manually also some schema for dna plugin was missing, I decided to use the big hammer and simply copied all schema files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema directory. This way ipa-ldap-updater finished successfully. And after a restart of httpd the UI came up. So *hopefully* all is ok now ... Should I open a ticket about ipa-ldap-updater being unsuccessful at updating ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Jun 11 18:50:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 11 Jun 2014 20:50:21 +0200 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402510668.13617.18.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> <1402509250.13617.16.camel@willson.usersys.redhat.com> <1402510668.13617.18.camel@willson.usersys.redhat.com> Message-ID: <5398A4ED.3020805@redhat.com> On 06/11/2014 08:17 PM, Simo Sorce wrote: > On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote: >> On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: >>> Ok now ipa-ldap-updater does a lot more and passes through schema >>> upgrade, however it fails again later complaining ipaVirtualOperation >>> is >>> an unknown object class .. >> >> Ok I manually added ipaVirtualOperation to user99.ldif, and the updater >> made some more progress, but now complains it doesn't know about >> ipapermissionv2 ... Simo, could you please post the actual error message when something goes wrong? Otherwise I can't really debug this. >> Why is the updater failing to recognize that some schema is missing ? >> I see it checking the schema file but it tries to replace a few >> attributes (every time) where the only thing that differs is the >> X-ORIGIN and does nothing else ... > > Ok after adding a few manually also some schema for dna plugin was > missing, I decided to use the big hammer and simply copied all schema > files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema > directory. > > This way ipa-ldap-updater finished successfully. > > And after a restart of httpd the UI came up. > So *hopefully* all is ok now ... > > Should I open a ticket about ipa-ldap-updater being unsuccessful at > updating ? Sure. Just include the debugging info; your system seems to be quite special. -- Petr? From simo at redhat.com Wed Jun 11 19:17:26 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 15:17:26 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <5398A4ED.3020805@redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> <1402509250.13617.16.camel@willson.usersys.redhat.com> <1402510668.13617.18.camel@willson.usersys.redhat.com> <5398A4ED.3020805@redhat.com> Message-ID: <1402514246.13617.25.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 20:50 +0200, Petr Viktorin wrote: > On 06/11/2014 08:17 PM, Simo Sorce wrote: > > On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote: > >> On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: > >>> Ok now ipa-ldap-updater does a lot more and passes through schema > >>> upgrade, however it fails again later complaining ipaVirtualOperation > >>> is > >>> an unknown object class .. > >> > >> Ok I manually added ipaVirtualOperation to user99.ldif, and the updater > >> made some more progress, but now complains it doesn't know about > >> ipapermissionv2 ... > > Simo, could you please post the actual error message when something goes > wrong? Otherwise I can't really debug this. More or less the same as before, it is understandable that operations fail when the schema they depend on is not available. The problem is that the schema hasn't been updated, not where it fails because it is missing. > >> Why is the updater failing to recognize that some schema is missing ? > >> I see it checking the schema file but it tries to replace a few > >> attributes (every time) where the only thing that differs is the > >> X-ORIGIN and does nothing else ... > > > > Ok after adding a few manually also some schema for dna plugin was > > missing, I decided to use the big hammer and simply copied all schema > > files from /etc/dirsrv/schema and /usr/share/ipa in the ds schema > > directory. > > > > This way ipa-ldap-updater finished successfully. > > > > And after a restart of httpd the UI came up. > > So *hopefully* all is ok now ... > > > > Should I open a ticket about ipa-ldap-updater being unsuccessful at > > updating ? > > Sure. Just include the debugging info; your system seems to be quite > special. I would say "battle-tested" :-) But honestly I do not think this is a common problem, it was just me messing up with the schema previously and forgetting I'd done that. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Jun 11 19:43:17 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 15:43:17 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402445582.29921.7.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> Message-ID: <1402515797.13617.27.camel@willson.usersys.redhat.com> On Tue, 2014-06-10 at 20:13 -0400, Simo Sorce wrote: > Still upgrading my server, so still untested, but again just to catch > style issues, I'll post news once I can test the changes do not break > functionality. I finished upgrading the server and redone my functional testing. Both getting ad setting keys seem to work as expected with the last batch of patches. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jun 11 21:03:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jun 2014 17:03:02 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402445582.29921.7.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> Message-ID: <5398C406.6060007@redhat.com> Simo Sorce wrote: > On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote: >> On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: >>> On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: >>>> On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: >>>>> On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: >>>>>> On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: >>>>>>> On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: >>>>>>>> Simo Sorce wrote: >>>>>>>>> This patch set is an initial implementation of ticket #3859 >>>>>>>>> >>>>>>>>> It seem to be working fine in my initial testing but I have not yet >>>>>>>>> tested all cases. >>>>>>>>> >>>>>>>>> However I wonted to throw it on the list to get some initial feedback >>>>>>>>> about the choices I made wrt access control and ipa-getkeytab flags and >>>>>>>>> default behavior. >>>>>>>>> >>>>>>>>> In particular, the current patch set would require us to make >>>>>>>>> host/service keytabs readable by the requesting party (whoever that is, >>>>>>>>> admin or host itself) in order to allow it to get back the actual >>>>>>>>> keytab. I am not sure this is ideal. Also write access to the keytab is >>>>>>>>> still all is needed to allow someone to change it. >>>>>>>>> >>>>>>>>> Neither is ideal, but it was simpler as a first implementation. In >>>>>>>>> particular I think we should allow either permission indipendently, and >>>>>>>>> it should be something an admin can change. However I do not like >>>>>>>>> allowing normal writes or reads to these attributes, mostly because w/o >>>>>>>>> access to the master key nobody can really make sense of actually >>>>>>>>> reading out the contents of KrbPrincipalKey or could write a blob that >>>>>>>>> can be successfully decrypted. >>>>>>>>> >>>>>>>>> So I was wondering if we might want to prevent both reading and writing >>>>>>>>> via LDAP (except via extended operations) and instead use another method >>>>>>>>> to determine access patterns. >>>>>>>>> >>>>>>>>> As for ipa-getkeytab is everyone ok with tryin the new method first and >>>>>>>>> always falling back to the old one (if a password has been provided) ? >>>>>>>> >>>>>>>> 0001 >>>>>>>> get_realm_backend() should probably have a comment on why returning NULL >>>>>>>> is ok (either because there is no sdn or because there is no be). It >>>>>>>> appears that things will eventually fail in get_entry_by_principal() >>>>>>> >>>>>>> Instead of adding complex explanations I immediately return with an >>>>>>> error if get_realm_backend() returns NULL. >>>>>> >>>>>> The logic here is correct, it just reads awkwardly. It is probably fine >>>>>> as is. >>>>>> >>>>>> There appear to be indiscriminate tab indents throughout the patch. >>>>>> Please changes these to spaces. >>>>> >>>>> There are because the coed is old, I do not change the style of a piece >>>>> of code if we are just changing a few lines. >>>>> You need to read the patch in the context of the code to seen it. >>>> >>>> If it were just the problem you alluded to, I wouldn't have called it >>>> out. I'm referring to tabs in the middle of new code that uses spaces. >>>> This is most likely the result of copy/paste. Either write all the new >>>> code to use tabs or match the copy/pasted lines to the surrounding new >>>> code (my preference). >> >> Nearly all the new code in ipapwd_setkeytab() uses space indents where >> the surrounding code uses tab indents. > > Yes although it looks a bit ugly a long time ago we decided that we'd > move to space indenting for big blocks of code, or keep tab indent only > for minor modification. In the hope of eventually converting the > remaining tabs. > > While we are here I decided to split setkeytab along the lines of > getkeytab too, HTH. > >> I'm not sure the block comment in is_allowed_to_access_attr() belongs >> there. > > Uhhmm now that we check an arbitrary attribute I need to change it. > >> Also, a utility function like is_allowed_to_access_attr() would probably >> be handy in upstream 389ds. I might use this in an upcoming token sync >> patch. This is not a requirement of ACK'ing the patch. > > The generic 389ds function is slapi_access_allowed() which is normally > sufficient, is_allowed_to_access_attr() is just a wrapper around some > additional boilerplate that is not normally needed. > Anyway feel free to open a bug in 389ds's trac. > >>>>>>>> 0002 >>>>>>>> >>>>>>>> ACK >>>>>> >>>>>> One small nitpick, then I too say ACK. In the commit message, the second >>>>>> sentence doesn't need a line break. >>>>> >>>>> I try to keep comments within 72 chars (though sometimes I forget and go >>>>> past till 80), which is why there is a line break there. >>>> >>>> Yeah, it just looks bad when sent over email, which is why I noticed it. >> >> This didn't get fixed. "Add" should follow "patch." on the same line. > > Well, kind of arbitrary, but ok > >>>>>>>> 0003 >>>>>> >>>>>> Same as patch 002: unnecessary line breaks in the commit message. >>>>> >>>>> See above. >> >> Also not fixed. "The new set of keys" should follow "existing ones." on >> the same line. > > ok > >>>>>> I think ipapwd_getkeytab() is unnecessarily long. Several sections of it >>>>>> could be broken out into functions and would make it much more readable. >>>>> >>>>> That has already been done :-) >>>>> You should see the original ipa_setkeytab() ... >>>> >>>> I'm not talking about ipapwd_setkeytab(). I'm talking about >>>> ipapwd_getkeytab(). This is entirely new code. There are very clear >>>> spots where it could be broken up. I consider this the biggest issue in >>>> this set of patches for two important reasons: >>>> 1. It makes the function really hard to review. >>>> 2. It is one of the most security/policy sensitive part of the code. >>>> >>>> These two are a bad combo. >> >> Much better! I was a bit disappointed that >> decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a >> single request/response struct, but I'm not going to hold up the review >> on that nitpick. > > Good, because I would not use a struct anyway :) > >>>>>>>> Since getnew is defined as a boolean in the ASN.1, is the conditional >>>>>>>> >>>>>>>> if (getnew == 0) >>>>>>>> >>>>>>>> preferred over just >>>>>>>> >>>>>>>> if (getnew)? >>>>>>> >>>>>>> Future proof if we want to change it to a non-boolean value for whatever >>>>>>> reason in the future ? :) >>>>>> >>>>>> I agree with rcrit. Fix this. :) >>>>> >>>>> Fixing how ? There is nothing wrong with this code, note that if >>>>> (getnew) would require to change the order of the 2 blocks and I wanted >>>>> the short one first intentionally, so I would have to use if (!getnew), >>>>> is this ok ? >>>> >>>> That is how I would write it. >> >> There is one dangling reference to "(getnew == 0)" on line 172. > > Nope, there is an intentional reference to it, getnew is an integer type > so it gets compared to an integer to get your boolean. > >>>>>>>> 0004 >>>>>> >>>>>> More occasional indentation issues (tab vs space). >> >> These still need to be fixed. See line 289 of the patch and following. >> All the new additions after this line in ldap_set_keytab() are using >> spaces, but the surrounding code uses tabs. > > Right, and it is intentional, although ugly to see we want to slowly > transition all code to space and 4 chars indent. We just didn't want to > arbitrarily mass re-indent and clobber git annotate. > > So the idea is to slowly convert all isolated blocks when new code is > added or a substantial part is changed. > >>>>>>>> 0005 >>>>>> >>>>>> Unnecessary line breaks in git commit message. >>>>> >>>>> As above >> >> Still needs to be fixed. "The new method" should follow "fails." on the >> same line. > > ok > >>>>>> Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to >>>>>> match the tab indents of the surrounding code. >>>>> >>>>> ah nice catch >> >> This still needs to be fixed. Also, there is indentation mismatches >> below this (starting on line 331 and following. > > ah forgot about this one, let's see if I got them all this time. > > Still upgrading my server, so still untested, but again just to catch > style issues, I'll post news once I can test the changes do not break > functionality. > > Simo. 0001 When is_allowed_to_access_attr() fails it should include the value of access in the error log for debugging. Nit: Coluld not fetch REALM backend There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm fine keeping a common err_msg but the fatal error should be unique. This breaks normal host delegation. If you add a host to another host's managedby, getting the keytab will fail. This is due to: [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny write on entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(97): aciname= "Groups allowed to create keytab keys", acidn="cn=accounts,dc=example,dc=com" 0003 In ipapwd_getkeytab() there is an odd comment, /* ok access allowed */, before access control is checked. I tested a RHEL-5 client and it seems to work ok. rob From simo at redhat.com Wed Jun 11 21:13:36 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 17:13:36 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <5398C406.6060007@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> Message-ID: <1402521216.20064.9.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2014-06-10 at 14:27 -0400, Nathaniel McCallum wrote: > >> On Tue, 2014-06-10 at 12:02 -0400, Simo Sorce wrote: > >>> On Mon, 2014-06-09 at 21:49 -0400, Nathaniel McCallum wrote: > >>>> On Mon, 2014-06-09 at 20:58 -0400, Simo Sorce wrote: > >>>>> On Mon, 2014-06-09 at 17:53 -0400, Nathaniel McCallum wrote: > >>>>>> On Mon, 2014-06-09 at 15:02 -0400, Simo Sorce wrote: > >>>>>>> On Mon, 2014-06-09 at 13:39 -0400, Rob Crittenden wrote: > >>>>>>>> Simo Sorce wrote: > >>>>>>>>> This patch set is an initial implementation of ticket #3859 > >>>>>>>>> > >>>>>>>>> It seem to be working fine in my initial testing but I have not yet > >>>>>>>>> tested all cases. > >>>>>>>>> > >>>>>>>>> However I wonted to throw it on the list to get some initial feedback > >>>>>>>>> about the choices I made wrt access control and ipa-getkeytab flags and > >>>>>>>>> default behavior. > >>>>>>>>> > >>>>>>>>> In particular, the current patch set would require us to make > >>>>>>>>> host/service keytabs readable by the requesting party (whoever that is, > >>>>>>>>> admin or host itself) in order to allow it to get back the actual > >>>>>>>>> keytab. I am not sure this is ideal. Also write access to the keytab is > >>>>>>>>> still all is needed to allow someone to change it. > >>>>>>>>> > >>>>>>>>> Neither is ideal, but it was simpler as a first implementation. In > >>>>>>>>> particular I think we should allow either permission indipendently, and > >>>>>>>>> it should be something an admin can change. However I do not like > >>>>>>>>> allowing normal writes or reads to these attributes, mostly because w/o > >>>>>>>>> access to the master key nobody can really make sense of actually > >>>>>>>>> reading out the contents of KrbPrincipalKey or could write a blob that > >>>>>>>>> can be successfully decrypted. > >>>>>>>>> > >>>>>>>>> So I was wondering if we might want to prevent both reading and writing > >>>>>>>>> via LDAP (except via extended operations) and instead use another method > >>>>>>>>> to determine access patterns. > >>>>>>>>> > >>>>>>>>> As for ipa-getkeytab is everyone ok with tryin the new method first and > >>>>>>>>> always falling back to the old one (if a password has been provided) ? > >>>>>>>> > >>>>>>>> 0001 > >>>>>>>> get_realm_backend() should probably have a comment on why returning NULL > >>>>>>>> is ok (either because there is no sdn or because there is no be). It > >>>>>>>> appears that things will eventually fail in get_entry_by_principal() > >>>>>>> > >>>>>>> Instead of adding complex explanations I immediately return with an > >>>>>>> error if get_realm_backend() returns NULL. > >>>>>> > >>>>>> The logic here is correct, it just reads awkwardly. It is probably fine > >>>>>> as is. > >>>>>> > >>>>>> There appear to be indiscriminate tab indents throughout the patch. > >>>>>> Please changes these to spaces. > >>>>> > >>>>> There are because the coed is old, I do not change the style of a piece > >>>>> of code if we are just changing a few lines. > >>>>> You need to read the patch in the context of the code to seen it. > >>>> > >>>> If it were just the problem you alluded to, I wouldn't have called it > >>>> out. I'm referring to tabs in the middle of new code that uses spaces. > >>>> This is most likely the result of copy/paste. Either write all the new > >>>> code to use tabs or match the copy/pasted lines to the surrounding new > >>>> code (my preference). > >> > >> Nearly all the new code in ipapwd_setkeytab() uses space indents where > >> the surrounding code uses tab indents. > > > > Yes although it looks a bit ugly a long time ago we decided that we'd > > move to space indenting for big blocks of code, or keep tab indent only > > for minor modification. In the hope of eventually converting the > > remaining tabs. > > > > While we are here I decided to split setkeytab along the lines of > > getkeytab too, HTH. > > > >> I'm not sure the block comment in is_allowed_to_access_attr() belongs > >> there. > > > > Uhhmm now that we check an arbitrary attribute I need to change it. > > > >> Also, a utility function like is_allowed_to_access_attr() would probably > >> be handy in upstream 389ds. I might use this in an upcoming token sync > >> patch. This is not a requirement of ACK'ing the patch. > > > > The generic 389ds function is slapi_access_allowed() which is normally > > sufficient, is_allowed_to_access_attr() is just a wrapper around some > > additional boilerplate that is not normally needed. > > Anyway feel free to open a bug in 389ds's trac. > > > >>>>>>>> 0002 > >>>>>>>> > >>>>>>>> ACK > >>>>>> > >>>>>> One small nitpick, then I too say ACK. In the commit message, the second > >>>>>> sentence doesn't need a line break. > >>>>> > >>>>> I try to keep comments within 72 chars (though sometimes I forget and go > >>>>> past till 80), which is why there is a line break there. > >>>> > >>>> Yeah, it just looks bad when sent over email, which is why I noticed it. > >> > >> This didn't get fixed. "Add" should follow "patch." on the same line. > > > > Well, kind of arbitrary, but ok > > > >>>>>>>> 0003 > >>>>>> > >>>>>> Same as patch 002: unnecessary line breaks in the commit message. > >>>>> > >>>>> See above. > >> > >> Also not fixed. "The new set of keys" should follow "existing ones." on > >> the same line. > > > > ok > > > >>>>>> I think ipapwd_getkeytab() is unnecessarily long. Several sections of it > >>>>>> could be broken out into functions and would make it much more readable. > >>>>> > >>>>> That has already been done :-) > >>>>> You should see the original ipa_setkeytab() ... > >>>> > >>>> I'm not talking about ipapwd_setkeytab(). I'm talking about > >>>> ipapwd_getkeytab(). This is entirely new code. There are very clear > >>>> spots where it could be broken up. I consider this the biggest issue in > >>>> this set of patches for two important reasons: > >>>> 1. It makes the function really hard to review. > >>>> 2. It is one of the most security/policy sensitive part of the code. > >>>> > >>>> These two are a bad combo. > >> > >> Much better! I was a bit disappointed that > >> decode_getkeytab_request()/encode_getkeytab_reply() don't output/input a > >> single request/response struct, but I'm not going to hold up the review > >> on that nitpick. > > > > Good, because I would not use a struct anyway :) > > > >>>>>>>> Since getnew is defined as a boolean in the ASN.1, is the conditional > >>>>>>>> > >>>>>>>> if (getnew == 0) > >>>>>>>> > >>>>>>>> preferred over just > >>>>>>>> > >>>>>>>> if (getnew)? > >>>>>>> > >>>>>>> Future proof if we want to change it to a non-boolean value for whatever > >>>>>>> reason in the future ? :) > >>>>>> > >>>>>> I agree with rcrit. Fix this. :) > >>>>> > >>>>> Fixing how ? There is nothing wrong with this code, note that if > >>>>> (getnew) would require to change the order of the 2 blocks and I wanted > >>>>> the short one first intentionally, so I would have to use if (!getnew), > >>>>> is this ok ? > >>>> > >>>> That is how I would write it. > >> > >> There is one dangling reference to "(getnew == 0)" on line 172. > > > > Nope, there is an intentional reference to it, getnew is an integer type > > so it gets compared to an integer to get your boolean. > > > >>>>>>>> 0004 > >>>>>> > >>>>>> More occasional indentation issues (tab vs space). > >> > >> These still need to be fixed. See line 289 of the patch and following. > >> All the new additions after this line in ldap_set_keytab() are using > >> spaces, but the surrounding code uses tabs. > > > > Right, and it is intentional, although ugly to see we want to slowly > > transition all code to space and 4 chars indent. We just didn't want to > > arbitrarily mass re-indent and clobber git annotate. > > > > So the idea is to slowly convert all isolated blocks when new code is > > added or a substantial part is changed. > > > >>>>>>>> 0005 > >>>>>> > >>>>>> Unnecessary line breaks in git commit message. > >>>>> > >>>>> As above > >> > >> Still needs to be fixed. "The new method" should follow "fails." on the > >> same line. > > > > ok > > > >>>>>> Line 308 ("int retrieve = 0;") has an 8 space indent. This was likely to > >>>>>> match the tab indents of the surrounding code. > >>>>> > >>>>> ah nice catch > >> > >> This still needs to be fixed. Also, there is indentation mismatches > >> below this (starting on line 331 and following. > > > > ah forgot about this one, let's see if I got them all this time. > > > > Still upgrading my server, so still untested, but again just to catch > > style issues, I'll post news once I can test the changes do not break > > functionality. > > > > Simo. > > 0001 > > When is_allowed_to_access_attr() fails it should include the value of > access in the error log for debugging. > > Nit: Coluld not fetch REALM backend > > There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm > fine keeping a common err_msg but the fatal error should be unique. > > This breaks normal host delegation. If you add a host to another host's > managedby, getting the keytab will fail. This is due to: > > [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny > write on > entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) > to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: > no aci matched the subject by aci(97): aciname= "Groups allowed to > create keytab keys", acidn="cn=accounts,dc=example,dc=com" Did this ever work ? What API is it using ? I am not aware of a rule that would allow it, what did I miss ? > 0003 > > In ipapwd_getkeytab() there is an odd comment, /* ok access allowed */, > before access control is checked. > > I tested a RHEL-5 client and it seems to work ok. Great. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Jun 11 21:41:49 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Jun 2014 17:41:49 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <53984A8D.9070508@redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> Message-ID: <1402522909.2955.26.camel@ipa.example.com> On Wed, 2014-06-11 at 14:24 +0200, Jan Cholasta wrote: > Hi, > > On 13.5.2014 18:40, Nathaniel McCallum wrote: > > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > >> This patch adds support for importing tokens using RFC 6030 key > >> container files. This includes decryption support. For sysadmin sanity, > >> any tokens which fail to add will be written to the output file for > >> examination. The main use case here is where a small subset of a large > >> set of tokens fails to validate or add. Using the output file, the > >> sysadmin can attempt to recover these specific tokens. > >> > >> This code is implemented as a server-side script. However, it doesn't > >> actually need to run on the server. This was done because importing is > >> an odd fit for the IPA command framework: > >> 1. We need to write an output file. > >> 2. The operation may be long-running (thousands of tokens). > >> 3. Only admins need to perform this task and it only happens > >> infrequently. > > > > I forgot to put the link to the ticket in the commit message. Fixed. > > 1) I think you should initialize NSS in ipa_otptoken_import.py, not in > the ipa-otptoken-import script. Fixed. > 2) The pep8 tool reports a lot of errors in ipa_otptoken_import.py. Fixed (mostly). The remaining output from pep8 is, I think, entirely justifiable. > 3) Other error messages are in the form "message: %s", I think this one > should use that form as well: > > + if encoding != 'DECIMAL': > + raise ValidationError('Unsupported encoding (%s)!' % encoding) Fixed. > 4) This is not right: > > + except: > + self.log.warn("Error adding token: " + > str(sys.exc_info()[1])) > > I think it should be something like this instead: > > except ValidationError, e: > self.log.warn("Error adding token: %s", e) Fixed. > 5) There is no man page for ipa-otptoken-import. TODO (tomorrow). > 6) Output file is created even when ipa-otptoken-import fails with > "Unable to connect to LDAP! Did you kinit?" and other initialization > errors, which makes subsequent ipa-otptoken-import fail with "Output > file already exists!". Fixed. > 7) When a key is specified by reference in Key/KeyReference instead of > directly in Key/Data/Secret like in > , > import fails with "Key not found in token!". I would expect a different > error message. This error is now: Referenced keys are not supported! > 8) Importing > > produces this output: > > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: > FutureWarning: The behavior of this method will change in future > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > if data.get('pinpolicy', None): > Error adding token: 'NoneType' object has no attribute 'strip' This now states: Error adding token: PINPolicy policy not supported! Error adding token: Unsupported token type! > 9) Using an arbitrary file in -k produces this output: > > (SEC_ERROR_INVALID_KEY) The key does not support the requested operation. > Traceback (most recent call last): > File "/usr/sbin/ipa-otptoken-import", line 29, in > nss.nss_shutdown() > nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects > are still in use. What do you mean by "arbitrary file"? A file that is not the key? Like /dev/null? I'm not able to reproduce this. > 10) Importing > > and > > produces this output: > > Error adding token: object of type 'NoneType' has no len() Import fails with: Derived keys are not currently supported! or X.509 keys are not currently supported! It would be nice to support these in the future. > 11) Importing > > or > > produces this output: > > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:304: > FutureWarning: The behavior of this method will change in future > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > if data.get('maxtransact', None): > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: > FutureWarning: The behavior of this method will change in future > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > if data.get('pinpolicy', None): Both of these now output: Error adding token: NumberOfTransactions policy not supported! > 12) Importing > > succeeds, but it should fail. This now errors with: PSKC file is invalid! > 13) Importing > > fails, but it should succeed, I think. I think this should fail in our case since we can't possibly support that configuration. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053.1-Implement-OTP-token-importing.patch Type: text/x-patch Size: 21605 bytes Desc: not available URL: From simo at redhat.com Wed Jun 11 22:27:20 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Jun 2014 18:27:20 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <5398C406.6060007@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> Message-ID: <1402525640.22737.3.camel@willson.usersys.redhat.com> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: > 0001 > > When is_allowed_to_access_attr() fails it should include the value of > access in the error log for debugging. Ok added more detailed logging > Nit: Coluld not fetch REALM backend Fixed > There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm > fine keeping a common err_msg but the fatal error should be unique. Yeah thanks to this comment, I had a small change of heart. Instead of sending such detailed information to clients I reverted to send a little less information to the clients and instead LOG_FATAL in a more detailed way. HTH > This breaks normal host delegation. If you add a host to another host's > managedby, getting the keytab will fail. This is due to: > > [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny > write on > entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) > to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: > no aci matched the subject by aci(97): aciname= "Groups allowed to > create keytab keys", acidn="cn=accounts,dc=example,dc=com" Ok this should be working now, I added a new ACI to allow also managedby#USERDN to operate on keytabs. New patches attached. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 36281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 27554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15976 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jun 12 01:18:14 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 12 Jun 2014 11:18:14 +1000 Subject: [Freeipa-devel] user certificates In-Reply-To: <539851B8.1060102@redhat.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> <539851B8.1060102@redhat.com> Message-ID: <20140612011814.GZ11349@dhcp-40-8.bne.redhat.com> On Wed, Jun 11, 2014 at 08:55:20AM -0400, John Dennis wrote: > On 06/11/2014 04:02 AM, Fraser Tweedale wrote: > > There are other use cases for user certificates, e.g. client > > authentication for HTTP or other network services. Perhaps you know > > of others - in which case let us know. > > 802.11 wireless authentication using EAP-TLS > > A common discussion on the RADIUS mailing lists is the desire to deploy > using EAP-TLS but the difficulty of provisioning user certs is always > the stumbling block. > Thanks John, I've created http://www.freeipa.org/page/User_certificate_use_cases to collect and discuss these use cases. Fraser > -- > John From dpal at redhat.com Thu Jun 12 03:10:21 2014 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Jun 2014 23:10:21 -0400 Subject: [Freeipa-devel] user certificates In-Reply-To: <20140612011814.GZ11349@dhcp-40-8.bne.redhat.com> References: <20140611080217.GX11349@dhcp-40-8.bne.redhat.com> <539851B8.1060102@redhat.com> <20140612011814.GZ11349@dhcp-40-8.bne.redhat.com> Message-ID: <53991A1D.8080401@redhat.com> On 06/11/2014 09:18 PM, Fraser Tweedale wrote: > On Wed, Jun 11, 2014 at 08:55:20AM -0400, John Dennis wrote: >> On 06/11/2014 04:02 AM, Fraser Tweedale wrote: >>> There are other use cases for user certificates, e.g. client >>> authentication for HTTP or other network services. Perhaps you know >>> of others - in which case let us know. >> 802.11 wireless authentication using EAP-TLS >> >> A common discussion on the RADIUS mailing lists is the desire to deploy >> using EAP-TLS but the difficulty of provisioning user certs is always >> the stumbling block. >> > Thanks John, > > I've created http://www.freeipa.org/page/User_certificate_use_cases > to collect and discuss these use cases. I think it is important to differ short term and long term certificates for users. The long term certificates are used for authentication and signing. They are put on devices like smart cards. They need to be associated with the user in the back end. They can be revoked. The short lived certificates do not need to be recorded on the server side. They are just issued and since they do not live long there is no need to record them in the back end or to try to revoke them. This IMO a crucial difference. For now we focus on the long living certificates for hosts, services, devices and short lived certificates for any identity. IMO long lived certs for users is a separate big use case that we currently should set aside and solve after we solve the other use cases. > > Fraser > >> -- >> John > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jcholast at redhat.com Thu Jun 12 07:49:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Jun 2014 09:49:30 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <537BAF42.5060502@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> <5374E16D.9050509@redhat.com> <537BAF42.5060502@redhat.com> Message-ID: <53995B8A.1090409@redhat.com> On 20.5.2014 21:38, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 25.4.2014 10:51, Jan Cholasta wrote: >>> On 24.4.2014 23:16, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>>>> Some in-line, a whole ton of data appended to end. >>>>>> >>>>>> Jan Cholasta wrote: >>>>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>>>> Rob Crittenden wrote: >>>>>>>>> >>>>>>>>> 247 >>>>>>>>> >>>>>>>>> We've been burned by hardcoded timeouts in the past. Should this be >>>>>>>>> configurable? This module doesn't currently do any logging but it >>>>>>>>> might >>>>>>>>> be worth spitting out a "waiting" message, at least for debugging. >>>>>>> >>>>>>> Added a timeout argument. >>>>>> >>>>>> Did you forget to send this one, I didn't see an update to 247. >>>>> >>>>> Are you sure you have 247.1 (now 247.2)? >>>>> >>>>> I can see at >>>>> >>>>> that I have sent the correct version of the patches. >>>> >>>> The call has a timeout, the callers don't use it. I guess it'll do for >>>> now, but these almost always come back to bite us. >>> >>> Well, I can add --certmonger-timeout option to ipa-cacert-manage, if >>> that's what you want. >>> >>>> >>>>> >>>>>>>>> >>>>>>>>> 251 >>>>>>>>> >>>>>>>>> The tool should provide some feedback while it's running. For the >>>>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>>>> what is >>>>>>>>> going on, something in between nothing and full debug output. >>>>>>> >>>>>>> Added some messages about what's going on. >>>>>> >>>>>> I dpn't see an update to 251 either. >>>>> >>>>> Please make sure you have 251.1 (now 251.2). >>>> >>>> There is a little bit more output but there are still very long periods >>>> of waiting between any visual activity, particularly when doing it on an >>>> IPA self-signed CA. >>> >>> This stuff takes time :-) What would you like to see in the output, >>> that's not already there? >>> >>>>>> >>>>>> I think the ipa-cacert-manage man page is missing one really important >>>>>> piece: why would you ever need to run this? And when? >>>>> >>>>> Added a paragraph about this. >>>> >>>> It's better, couple of comments: >>>> >>>> Add "the" in between renew and CA in "used to manually renew CA >>>> certificate of" and "When IPA CA...". >>> >>> OK. >>> >>>> I haven't had any luck renewing >>>> the CA certificate yet. I see that it is tracked now. I started moving >>>> the system clock forward in order to get to renewal and about the 3rd >>>> iteration the requests started failing with an XML error. Did you see >>>> this? >>>> >>>> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most >>>> recent call last): >>>> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in >>>> wsgi_execute >>>> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >>>> self.Command[name](*args, **options) >>>> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>> __call__ >>>> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >>>> self.run(*args, **options) >>>> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >>>> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >>>> self.execute(*args, **options) >>>> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in >>>> execute >>>> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >>>> api.Command['cert_show'](unicode(serial))['result'] >>>> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>> __call__ >>>> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >>>> self.run(*args, **options) >>>> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run >>>> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >>>> self.execute(*args, **options) >>>> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in >>>> execute >>>> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >>>> result=self.Backend.ra.get_certificate(serial_number) >>>> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>> 1502, in get_certificate >>>> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result >>>> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >>>> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>> 1363, in get_parse_result_xml >>>> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >>>> etree.fromstring(xml_text, parser) >>>> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >>>> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >>>> (src/lxml/lxml.etree.c:68129) >>>> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >>>> (src/lxml/lxml.etree.c:102493) >>>> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 1673, in lxml.etree._parseDoc >>>> (src/lxml/lxml.etree.c:101322) >>>> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >>>> (src/lxml/lxml.etree.c:96504) >>>> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 582, in >>>> lxml.etree._ParserContext._handleParseResultDoc >>>> (src/lxml/lxml.etree.c:91308) >>>> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 683, in lxml.etree._handleParseResult >>>> (src/lxml/lxml.etree.c:92494) >>>> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >>>> "parser.pxi", line 633, in lxml.etree._raiseParseError >>>> (src/lxml/lxml.etree.c:91957) >>>> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: >>>> None >>>> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >>>> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >>>> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8! V! > P! >>>> >> Z! >>>> >>> gm! >>>> >>>> 3VCtgMvPVk >>>> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >>>> >>>> >>>> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >>>> version=u'2.51'): XMLSyntaxError >>> >>> I have never seen this. The error message does not say much... Is there >>> anything interesting in other logs? >> >> I was able to get the CA certificate to be renewed after moving system >> time forward step by step. >> >> One thing I haven't noticed before is that the renewed certificate's >> validity never exceeds that of the original certificate. This is most >> likely Dogtag issue (something along the lines of "certificate validity >> cannot exceed validity of the CA certificate", except it shouldn't apply >> to the CA certificate itself). >> >> There were other issues here and there, all of them were caused by race >> conditions between concurrent renewals (unreachable CA, XML syntax >> errors, etc. because Dogtag was stopped by stop_pkicad in another >> request, CMS internal error because it used old subsystem cert to >> authenticate to LDAP while the cert was being renewed, etc.) and all of >> them could be fixed by restarting relevant IPA services and resubmitting >> the requests manually. Some synchronization is really missing there. > > I hadn't noticed that, but my CA was issued externally so I expected > this. I also saw the bumps during renewal but things always tended to > smooth out, with the errors generally restricted to restarts and > certmonger. This backtrace was the only thing that really stood out. > IIRC at this point things were pretty much blocked. > > In any case, these patches basically seem to work. I never did work out > whether the above error was due to dogtag, IPA or something else. > > rob Rebased the patches on top of current master. Give up retrieving certificate from LDAP in patch 265 after a few unsuccessful attempts. This is to prevent certmonger requests from staying in CA_WORKING state forever when you manually resubmit a request. Added patch 266 which adds ACIs missing after the permission refactoring. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.3-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.3-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.3-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.3-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.3-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5094 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.3-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.3-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2104 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.3-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.3-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.3-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 2916 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.3-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 16850 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.3-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.3-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.2-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.1-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.1-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 11902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.1-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jun 12 07:51:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Jun 2014 09:51:50 +0200 Subject: [Freeipa-devel] [PATCH] 654 webui: fix SSH Key widget update In-Reply-To: <1402502609.2955.8.camel@ipa.example.com> References: <539853DA.1090504@redhat.com> <1402502609.2955.8.camel@ipa.example.com> Message-ID: <53995C16.2010407@redhat.com> On 11.6.2014 18:03, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 15:04 +0200, Petr Vobornik wrote: >> Update widget status text on update. > > ACK > Pushed to master: 352ef8428c8e2faef8b93b8ecbee9db7e40e1ab6 -- Petr Vobornik From pviktori at redhat.com Thu Jun 12 07:51:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Jun 2014 09:51:57 +0200 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <1402514246.13617.25.camel@willson.usersys.redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> <1402509250.13617.16.camel@willson.usersys.redhat.com> <1402510668.13617.18.camel@willson.usersys.redhat.com> <5398A4ED.3020805@redhat.com> <1402514246.13617.25.camel@willson.usersys.redhat.com> Message-ID: <53995C1D.7040301@redhat.com> On 06/11/2014 09:17 PM, Simo Sorce wrote: > On Wed, 2014-06-11 at 20:50 +0200, Petr Viktorin wrote: >> On 06/11/2014 08:17 PM, Simo Sorce wrote: >>> On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote: >>>> On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: >>>>> Ok now ipa-ldap-updater does a lot more and passes through schema >>>>> upgrade, however it fails again later complaining ipaVirtualOperation >>>>> is >>>>> an unknown object class .. >>>> >>>> Ok I manually added ipaVirtualOperation to user99.ldif, and the updater >>>> made some more progress, but now complains it doesn't know about >>>> ipapermissionv2 ... >> >> Simo, could you please post the actual error message when something goes >> wrong? Otherwise I can't really debug this. > > More or less the same as before, it is understandable that operations > fail when the schema they depend on is not available. The problem is > that the schema hasn't been updated, not where it fails because it is > missing. I'm interested in the "updater made some more progress" part. The schema updater logs there are quite detailed, so from them it should be possible to tell where things went wrong. -- Petr? From pviktori at redhat.com Thu Jun 12 07:58:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Jun 2014 09:58:18 +0200 Subject: [Freeipa-devel] [PATCH 0018] Fix --ttl description for DNS zones In-Reply-To: <1402504641.2955.14.camel@ipa.example.com> References: <53983CF7.9040905@redhat.com> <1402504641.2955.14.camel@ipa.example.com> Message-ID: <53995D9A.3020903@redhat.com> On 06/11/2014 06:37 PM, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 13:26 +0200, Petr Spacek wrote: >> Hello, >> >> Fix --ttl description for DNS zones >> >> TTL specified in idnsZone object class affects all records at zone apex, >> not only SOA record. >> >> I have realized that current description is incorrect when I was doing doc review. > > ACK Pushed to master: 91d3d4d7b2abf6441f8be033323d3849bbb57217 -- Petr? From pvoborni at redhat.com Thu Jun 12 07:58:44 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Jun 2014 09:58:44 +0200 Subject: [Freeipa-devel] [PATCH] 656 webui: handle "unknown" result of automember-default-group-show In-Reply-To: <1402502573.2955.7.camel@ipa.example.com> References: <5398547D.3090704@redhat.com> <1402502573.2955.7.camel@ipa.example.com> Message-ID: <53995DB4.7040402@redhat.com> On 11.6.2014 18:02, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 15:07 +0200, Petr Vobornik wrote: >> Interface for setting default group is hidden when user doesn't have >> necessary rights or if there is some error while loading the state. >> >> https://fedorahosted.org/freeipa/ticket/4356 > > ACK > Pushed to master f0c19f907e27f2cd80b68ae32d20befe847ba443 -- Petr Vobornik From pvoborni at redhat.com Thu Jun 12 08:00:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Jun 2014 10:00:08 +0200 Subject: [Freeipa-devel] [PATCH] 657 webui: control sudo rule deny command tables by category switch In-Reply-To: <1402504203.2955.12.camel@ipa.example.com> References: <539854BF.9020800@redhat.com> <1402504203.2955.12.camel@ipa.example.com> Message-ID: <53995E08.7080508@redhat.com> On 11.6.2014 18:30, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 15:08 +0200, Petr Vobornik wrote: >> `memberdenycmd_sudocmd` and `memberdenycmd_sudocmdgroup` tables are now >> enabled/disabled based on `cmdcategory` as well. >> >> https://fedorahosted.org/freeipa/ticket/4361 > > ACK Pushed to master: f1b83198da67b6cbf49209371b8a96536a13703e > > I'm curious about the lack of space around the '+' operator in: > + container.append(title+': '); > > Is that the right style? It isn't, copy&paste error, fixed before push. > > Nathaniel > -- Petr Vobornik From pvoborni at redhat.com Thu Jun 12 08:00:54 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Jun 2014 10:00:54 +0200 Subject: [Freeipa-devel] [PATCH] 658 webui: add sudoorder field to sudo rule page In-Reply-To: <1402502499.2955.6.camel@ipa.example.com> References: <539854EC.8020201@redhat.com> <1402502499.2955.6.camel@ipa.example.com> Message-ID: <53995E36.5070108@redhat.com> On 11.6.2014 18:01, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 15:09 +0200, Petr Vobornik wrote: >> part of >> https://fedorahosted.org/freeipa/ticket/2348 > > ACK > Pushed to master: 8f286d5c510c30f2319a8b0142cb68ee8e81f664 -- Petr Vobornik From mkosek at redhat.com Thu Jun 12 08:45:17 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Jun 2014 10:45:17 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <1402505346.2955.19.camel@ipa.example.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> Message-ID: <5399689D.10203@redhat.com> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >> Hi, >> >> As due to possible race conditions, the preop.pin might not be >> written in the CS.cfg at the time installer tries to read it. >> >> In case no value for preop.pin was found, retry until timeout >> was reached. >> >> https://fedorahosted.org/freeipa/ticket/3382 >> >> (applies on ipa-3-0 branch) > > There is inconsistent spacing around '='. For instance: > + f=open(filename, 'r') > + data = f.read() > > Also, I'm fairly certain this is incorrect: > + total_timeout =+ 1 > > Nathaniel +1, this is certainly is not a deterministic, constant measuring of a timeout. I would rather see something like op_timeout = time.time() + api.env.startup_timeout while preop_pin is None and time.time() < op_timeout: Also, I do not think this will work, IOError is risen when a file is not found, so this code would not solve the problem if waiting on file to appear. Martin From mbasti at redhat.com Thu Jun 12 08:47:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Jun 2014 10:47:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> Message-ID: <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-11 at 17:41 +0200, Martin Basti wrote: > On Mon, 2014-06-02 at 13:57 +0200, Martin Basti wrote: > > Rebased patches attached > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Rebased patches attached > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Fixed patch attached Error caused by rebase -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-4-Create-BASE-zone-class.patch Type: text/x-patch Size: 38681 bytes Desc: not available URL: From pviktori at redhat.com Thu Jun 12 10:06:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Jun 2014 12:06:24 +0200 Subject: [Freeipa-devel] [PATCH] 0580 Change group permission object filter to posixgroup Message-ID: <53997BA0.50608@redhat.com> A fix for https://fedorahosted.org/freeipa/ticket/4372 -- Petr? From pviktori at redhat.com Thu Jun 12 10:07:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Jun 2014 12:07:01 +0200 Subject: [Freeipa-devel] [PATCH] 0580 Change group permission object filter to posixgroup In-Reply-To: <53997BA0.50608@redhat.com> References: <53997BA0.50608@redhat.com> Message-ID: <53997BC5.6000901@redhat.com> > A fix for https://fedorahosted.org/freeipa/ticket/4372 is attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0580-Change-group-permission-object-filter-to-posixgroup.patch Type: text/x-patch Size: 3779 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jun 12 11:17:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Jun 2014 13:17:30 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0064 Update DNSSEC attributes/record types In-Reply-To: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> Message-ID: <53998C4A.1060804@redhat.com> On 9.6.2014 17:28, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/4328 > > Petr please make the WebUI patch review (0062) :-) > > Patches attached. > Patch #0059: LGTM Patch #0060: 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise you get general "Text does not match field pattern" error message in Web UI. 2. Could be in one if: + if nsec3params is not None: + if len(nsec3params) > 1: Maybe I'm missing something. But why does the dns plugin code use following all over the place: try: nsec3params = rrattrs['nsec3paramrecord'] except KeyError: pass else: if nsec3params is not None: instead of: nsec3params = rrattrs.get('nsec3paramrecord') if nsec3params is not None: btw you use both patterns in the patch. Patch #0061: ACK Patch #0062: 3. Why are there the idnafsdbrec1 variables? 4. related to ^^: ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing whitespace after ',' Patch #0063: LGTM IDK if they work because I'm experiencing some weird issues with xmlrpc_tests in general. -- Petr Vobornik From tbabej at redhat.com Thu Jun 12 11:29:46 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Jun 2014 13:29:46 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <5399689D.10203@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> Message-ID: <53998F2A.6060703@redhat.com> On 06/12/2014 10:45 AM, Martin Kosek wrote: > On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>> Hi, >>> >>> As due to possible race conditions, the preop.pin might not be >>> written in the CS.cfg at the time installer tries to read it. >>> >>> In case no value for preop.pin was found, retry until timeout >>> was reached. >>> >>> https://fedorahosted.org/freeipa/ticket/3382 >>> >>> (applies on ipa-3-0 branch) >> There is inconsistent spacing around '='. For instance: >> + f=open(filename, 'r') >> + data = f.read() >> >> Also, I'm fairly certain this is incorrect: >> + total_timeout =+ 1 >> >> Nathaniel > +1, this is certainly is not a deterministic, constant measuring of a timeout. Fixed. > > I would rather see something like > > op_timeout = time.time() + api.env.startup_timeout > > while preop_pin is None and time.time() < op_timeout: > > > Also, I do not think this will work, IOError is risen when a file is not found, > so this code would not solve the problem if waiting on file to appear. Yes, but the problem was not in being unable to open the file, but that certain file content is not in the file yet. It seems that pkicreate creates the file in time, but the content written later and that causes the race condition. If you inspect the original code, and bugzilla, you can see that installation fails with: 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? While the original code # read the config file and get the preop pin try: f=open(filename) except IOError, e: root_logger.error("Cannot open configuration file." + str(e)) raise e data = f.read() data = data.split('\n') pattern = re.compile("preop.pin=(.*)" ) for line in data: match = re.search(pattern, line) if (match): preop_pin=match.group(1) break if preop_pin is None: raise RuntimeError("Unable to find preop.pin in %s. Is your CA already configured?" % filename) does raise the IOError in case the file was not able to be opened. Since we get the Runtime error, file must exist, only the desired content is missing. That said, I have no objections to amending the patch so that it properly handles this race condition we did not encounter. Better safe than sorry, it's a simple change and already included in the current iteration of the patch. Updated patch attached. > > Martin -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0224-2-cainstance-Read-CS.cfg-for-preop.pin-in-a-loop.patch Type: text/x-patch Size: 2856 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jun 12 12:37:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Jun 2014 08:37:19 -0400 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <53998F2A.6060703@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> Message-ID: <1402576639.4842.1.camel@ipa.example.com> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: > On 06/12/2014 10:45 AM, Martin Kosek wrote: > > On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: > >> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: > >>> Hi, > >>> > >>> As due to possible race conditions, the preop.pin might not be > >>> written in the CS.cfg at the time installer tries to read it. > >>> > >>> In case no value for preop.pin was found, retry until timeout > >>> was reached. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3382 > >>> > >>> (applies on ipa-3-0 branch) > >> There is inconsistent spacing around '='. For instance: > >> + f=open(filename, 'r') > >> + data = f.read() > >> > >> Also, I'm fairly certain this is incorrect: > >> + total_timeout =+ 1 > >> > >> Nathaniel > > +1, this is certainly is not a deterministic, constant measuring of a timeout. > > Fixed. > > > > > I would rather see something like > > > > op_timeout = time.time() + api.env.startup_timeout > > > > while preop_pin is None and time.time() < op_timeout: > > > > > > Also, I do not think this will work, IOError is risen when a file is not found, > > so this code would not solve the problem if waiting on file to appear. > > Yes, but the problem was not in being unable to open the file, but that > certain file content > is not in the file yet. It seems that pkicreate creates the file in > time, but the content written > later and that causes the race condition. > > If you inspect the original code, and bugzilla, you can see that > installation fails with: > > 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: > RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? > > While the original code > > # read the config file and get the preop pin > > try: > > > f=open(filename) > > except IOError, > e: > > root_logger.error("Cannot open configuration file." + > str(e)) > raise > e > > data = > f.read() > > data = > data.split('\n') > > pattern = re.compile("preop.pin=(.*)" > ) > for line in > data: > > match = re.search(pattern, > line) > if > (match): > > > preop_pin=match.group(1) > > break > if preop_pin is None: > raise RuntimeError("Unable to find preop.pin in %s. Is your CA > already configured?" % filename) > > does raise the IOError in case the file was not able to be opened. Since > we get the Runtime error, > file must exist, only the desired content is missing. > > That said, I have no objections to amending the patch so that it > properly handles this race condition > we did not encounter. Better safe than sorry, it's a simple change and > already included in the > current iteration of the patch. > > Updated patch attached. I think I would prefer something like inotify watching for IN_CLOSE_WRITE rather than this polling. Nathaniel From edewata at redhat.com Thu Jun 12 12:40:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Jun 2014 07:40:02 -0500 Subject: [Freeipa-devel] [PATCH] 546 webui: expose krbprincipalexpiration In-Reply-To: <530CCDCB.6000009@redhat.com> References: <530CCDCB.6000009@redhat.com> Message-ID: <53999FA2.8020209@redhat.com> On 2/25/2014 11:07 AM, Petr Vobornik wrote: > Depends on tbabej's patches # 137, 138 and my 546. > > https://fedorahosted.org/freeipa/ticket/3306 ACK on #547. -- Endi S. Dewata From edewata at redhat.com Thu Jun 12 12:40:54 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Jun 2014 07:40:54 -0500 Subject: [Freeipa-devel] [PATCH] 655 webui: move RPC result extraction logic to Adapter In-Reply-To: <53985418.9050700@redhat.com> References: <53985418.9050700@redhat.com> Message-ID: <53999FD6.6060600@redhat.com> On 6/11/2014 8:05 AM, Petr Vobornik wrote: > It enables declarative extraction of values from partial > results of a batch commands and also further extensibility > in custom adapters. > > The default adapter has detection logic for this extraction so > it can use bare record or extract data from normal or batch RPC > command. > > Minor change of user plugin fixed: > https://fedorahosted.org/freeipa/ticket/4355 ACK. -- Endi S. Dewata From edewata at redhat.com Thu Jun 12 12:53:03 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Jun 2014 07:53:03 -0500 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <5398730A.1010907@redhat.com> References: <5374C821.60004@redhat.com> <5397745F.3060100@redhat.com> <53983820.2040606@redhat.com> <5398730A.1010907@redhat.com> Message-ID: <5399A2AF.2090903@redhat.com> On 6/11/2014 10:17 AM, Endi Sukma Dewata wrote: > On 6/11/2014 6:06 AM, Petr Vobornik wrote: >>> 1. If I recall correctly, a new user is required to change the password >>> upon the initial login. This can be done with kinit, but can this be >>> done via UI too? Right now a new user will get a login error without any >>> message or link to reset the password. >> >> It works for me. There was a ticket >> https://fedorahosted.org/freeipa/ticket/4339 which corresponds to the >> description. >> >> Or it could be related to: >> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=c41b782bc59cd0cb70cbd62d543f9c538109d410 >> >> (if you use an IPA version before the revert) > > I just built the master yesterday. Let me see if I can reproduce it with > a newer build. I'm still seeing the problem in the new build. Here are the steps to reproduce: 1. Login as admin. 2. Add a new user with a password. 3. Logout. 4. Login as the new user. It will say "The password or username you entered is incorrect." There's no message about expiration or link to change the password. So far the only way to change the password is via kinit. -- Endi S. Dewata From simo at redhat.com Thu Jun 12 13:08:22 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jun 2014 09:08:22 -0400 Subject: [Freeipa-devel] Woes updating and oldish devel server to latest master In-Reply-To: <53995C1D.7040301@redhat.com> References: <1402447699.29921.10.camel@willson.usersys.redhat.com> <53981CE4.3050901@redhat.com> <1402490860.29921.11.camel@willson.usersys.redhat.com> <1402504588.2955.13.camel@ipa.example.com> <1402505115.13617.4.camel@willson.usersys.redhat.com> <5398886D.9020506@redhat.com> <1402505925.13617.8.camel@willson.usersys.redhat.com> <53988D11.9080903@redhat.com> <1402507854.13617.10.camel@willson.usersys.redhat.com> <1402507966.13617.12.camel@willson.usersys.redhat.com> <1402508197.13617.13.camel@willson.usersys.redhat.com> <1402509250.13617.16.camel@willson.usersys.redhat.com> <1402510668.13617.18.camel@willson.usersys.redhat.com> <5398A4ED.3020805@redhat.com> <1402514246.13617.25.camel@willson.usersys.redhat.com> <53995C1D.7040301@redhat.com> Message-ID: <1402578502.22737.32.camel@willson.usersys.redhat.com> On Thu, 2014-06-12 at 09:51 +0200, Petr Viktorin wrote: > On 06/11/2014 09:17 PM, Simo Sorce wrote: > > On Wed, 2014-06-11 at 20:50 +0200, Petr Viktorin wrote: > >> On 06/11/2014 08:17 PM, Simo Sorce wrote: > >>> On Wed, 2014-06-11 at 13:54 -0400, Simo Sorce wrote: > >>>> On Wed, 2014-06-11 at 13:36 -0400, Simo Sorce wrote: > >>>>> Ok now ipa-ldap-updater does a lot more and passes through schema > >>>>> upgrade, however it fails again later complaining ipaVirtualOperation > >>>>> is > >>>>> an unknown object class .. > >>>> > >>>> Ok I manually added ipaVirtualOperation to user99.ldif, and the updater > >>>> made some more progress, but now complains it doesn't know about > >>>> ipapermissionv2 ... > >> > >> Simo, could you please post the actual error message when something goes > >> wrong? Otherwise I can't really debug this. > > > > More or less the same as before, it is understandable that operations > > fail when the schema they depend on is not available. The problem is > > that the schema hasn't been updated, not where it fails because it is > > missing. > > I'm interested in the "updater made some more progress" part. The schema > updater logs there are quite detailed, so from them it should be > possible to tell where things went wrong. I'll send the logs to you privately. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Thu Jun 12 13:15:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Jun 2014 15:15:40 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <1402576639.4842.1.camel@ipa.example.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> Message-ID: <5399A7FC.4090305@redhat.com> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: > On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: >> On 06/12/2014 10:45 AM, Martin Kosek wrote: >>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> As due to possible race conditions, the preop.pin might not be >>>>> written in the CS.cfg at the time installer tries to read it. >>>>> >>>>> In case no value for preop.pin was found, retry until timeout >>>>> was reached. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3382 >>>>> >>>>> (applies on ipa-3-0 branch) >>>> There is inconsistent spacing around '='. For instance: >>>> + f=open(filename, 'r') >>>> + data = f.read() >>>> >>>> Also, I'm fairly certain this is incorrect: >>>> + total_timeout =+ 1 >>>> >>>> Nathaniel >>> +1, this is certainly is not a deterministic, constant measuring of a timeout. >> Fixed. >> >>> I would rather see something like >>> >>> op_timeout = time.time() + api.env.startup_timeout >>> >>> while preop_pin is None and time.time() < op_timeout: >>> >>> >>> Also, I do not think this will work, IOError is risen when a file is not found, >>> so this code would not solve the problem if waiting on file to appear. >> Yes, but the problem was not in being unable to open the file, but that >> certain file content >> is not in the file yet. It seems that pkicreate creates the file in >> time, but the content written >> later and that causes the race condition. >> >> If you inspect the original code, and bugzilla, you can see that >> installation fails with: >> >> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: >> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? >> >> While the original code >> >> # read the config file and get the preop pin >> >> try: >> >> >> f=open(filename) >> >> except IOError, >> e: >> >> root_logger.error("Cannot open configuration file." + >> str(e)) >> raise >> e >> >> data = >> f.read() >> >> data = >> data.split('\n') >> >> pattern = re.compile("preop.pin=(.*)" >> ) >> for line in >> data: >> >> match = re.search(pattern, >> line) >> if >> (match): >> >> >> preop_pin=match.group(1) >> >> break >> if preop_pin is None: >> raise RuntimeError("Unable to find preop.pin in %s. Is your CA >> already configured?" % filename) >> >> does raise the IOError in case the file was not able to be opened. Since >> we get the Runtime error, >> file must exist, only the desired content is missing. >> >> That said, I have no objections to amending the patch so that it >> properly handles this race condition >> we did not encounter. Better safe than sorry, it's a simple change and >> already included in the >> current iteration of the patch. >> >> Updated patch attached. > I think I would prefer something like inotify watching for > IN_CLOSE_WRITE rather than this polling. > > Nathaniel > Wouldn't that be a little bit of an overkill for that purpose? - we'll need to introduce an additional dependency for python-inotify - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin written to CS.cfg (and we don't know that unless we inspect the code for pkicreate, which in turn would make our code dependant on code not located in our codebase), so we will still need to check if preop_pin is there, and loop over if not -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mbasti at redhat.com Thu Jun 12 14:20:14 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Jun 2014 16:20:14 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0064 Update DNSSEC attributes/record types In-Reply-To: <53998C4A.1060804@redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> Message-ID: <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: > On 9.6.2014 17:28, Martin Basti wrote: > > Ticket: https://fedorahosted.org/freeipa/ticket/4328 > > > > Petr please make the WebUI patch review (0062) :-) > > > > Patches attached. > > > > Patch #0059: LGTM > > Patch #0060: > > 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise > you get general "Text does not match field pattern" error message in Web UI. > I will add the message. > 2. Could be in one if: > + if nsec3params is not None: > + if len(nsec3params) > 1: > > Maybe I'm missing something. But why does the dns plugin code use > following all over the place: > > try: > nsec3params = rrattrs['nsec3paramrecord'] > except KeyError: > pass > else: > if nsec3params is not None: > > instead of: > > nsec3params = rrattrs.get('nsec3paramrecord') > if nsec3params is not None: > > btw you use both patterns in the patch. I will use shorten form, I wrote it in the same way as the other code in the block was written, that's why. > > Patch #0061: ACK > > > Patch #0062: > > 3. Why are there the idnafsdbrec1 variables? > It was replace for NSEC records, which are not supported anymore. Now I realize, there is wrong description, so the idnafsbrec1 variable is not needed. I will remove it. > 4. related to ^^: > ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing > whitespace after ',' > > > Patch #0063: LGTM > IDK if they work because I'm experiencing some weird issues with > xmlrpc_tests in general. I had troubles only with permission tests, but all DNS test worked fine for me. Thank you for review. -- Martin^2 Basti From mkosek at redhat.com Thu Jun 12 14:20:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Jun 2014 16:20:32 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <5399A7FC.4090305@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> Message-ID: <5399B730.7040602@redhat.com> On 06/12/2014 03:15 PM, Tomas Babej wrote: > > On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: >> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: >>> On 06/12/2014 10:45 AM, Martin Kosek wrote: >>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> As due to possible race conditions, the preop.pin might not be >>>>>> written in the CS.cfg at the time installer tries to read it. >>>>>> >>>>>> In case no value for preop.pin was found, retry until timeout >>>>>> was reached. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3382 >>>>>> >>>>>> (applies on ipa-3-0 branch) >>>>> There is inconsistent spacing around '='. For instance: >>>>> + f=open(filename, 'r') >>>>> + data = f.read() >>>>> >>>>> Also, I'm fairly certain this is incorrect: >>>>> + total_timeout =+ 1 >>>>> >>>>> Nathaniel >>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. >>> Fixed. >>> >>>> I would rather see something like >>>> >>>> op_timeout = time.time() + api.env.startup_timeout >>>> >>>> while preop_pin is None and time.time() < op_timeout: >>>> >>>> >>>> Also, I do not think this will work, IOError is risen when a file is not found, >>>> so this code would not solve the problem if waiting on file to appear. >>> Yes, but the problem was not in being unable to open the file, but that >>> certain file content >>> is not in the file yet. It seems that pkicreate creates the file in >>> time, but the content written >>> later and that causes the race condition. >>> >>> If you inspect the original code, and bugzilla, you can see that >>> installation fails with: >>> >>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: >>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? >>> >>> While the original code >>> >>> # read the config file and get the preop pin >>> >>> try: >>> >>> >>> f=open(filename) >>> >>> except IOError, >>> e: >>> >>> root_logger.error("Cannot open configuration file." + >>> str(e)) >>> raise >>> e >>> >>> data = >>> f.read() >>> >>> data = >>> data.split('\n') >>> >>> pattern = re.compile("preop.pin=(.*)" >>> ) >>> for line in >>> data: >>> >>> match = re.search(pattern, >>> line) >>> if >>> (match): >>> >>> >>> preop_pin=match.group(1) >>> >>> break >>> if preop_pin is None: >>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA >>> already configured?" % filename) >>> >>> does raise the IOError in case the file was not able to be opened. Since >>> we get the Runtime error, >>> file must exist, only the desired content is missing. >>> >>> That said, I have no objections to amending the patch so that it >>> properly handles this race condition >>> we did not encounter. Better safe than sorry, it's a simple change and >>> already included in the >>> current iteration of the patch. >>> >>> Updated patch attached. >> I think I would prefer something like inotify watching for >> IN_CLOSE_WRITE rather than this polling. >> >> Nathaniel >> > Wouldn't that be a little bit of an overkill for that purpose? If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this problem in current master as this issue only affects Dogtag 9 installation. The target is to have small, contained and the non-intrusive patch. Thus the proposed solution to just implement a little wait loop. > > - we'll need to introduce an additional dependency for python-inotify > - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin > written to CS.cfg (and we don't know that unless we inspect the code for > pkicreate, which in turn would make our code dependant on code not > located in our codebase), so we will still need to check if preop_pin is > there, and loop over if not > From pspacek at redhat.com Thu Jun 12 14:23:49 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 Jun 2014 16:23:49 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <5361229A.7030303@redhat.com> References: <5361229A.7030303@redhat.com> Message-ID: <5399B7F5.1040306@redhat.com> On 30.4.2014 18:19, Petr Spacek wrote: > following text summarizes schema & DIT layout for DNSSEC key storage in LDAP. I have added object classes and default values for attributes I consider important. This is final proposal for implementation. Please review it ASAP. > This is subset of full PKCS#11 schema [0]. It stores bare keys with few > metadata attributes when necessary. > > The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy > as possible. This transition should happen in next minor version of FreeIPA. > > In theory, the transition should be just adding few object classes to existing > objects and populating few new metadata attributes. Related object classes are > marked below with "(in long-term)". > > Please comment on it soon. We want to implement it ASAP :-) > > > DNSSEC key > ========== > - Asymmetric > - Private key is stored in LDAP as encrypted PKCS#8 blob > - Public key is published in LDAP > - Encrypted with symmetric "DNSSEC master key" (see below) > - Private key - represented as LDAP object with object classes: > ipaEPrivateKey [1] # encrypted data > ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 > ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata > - Public key - represented as LDAP object with object classes: > ipaPublicKey [1] # public key data > ipk11PublicKey [3] (in long-term) # PKCS#11 metadata > > > Master key > ========== > - Symmetric > - Stored in LDAP as encrypted blob > - Encrypted with asymmetric "replica key" (see below) > - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys > - A replica uses it's own key for master key en/decryption > - Represented as LDAP object with object classes: > ipaESecretKey [1] > ipk11SecretKey [3] (in long-term) > > Replica key > =========== > - Asymmetric > - Private key is stored on replica's disk only > - Public key for all replicas is stored in LDAP > - Represented as LDAP object with object classes: > ipaPublicKey [1] > ipk11PublicKey [3] (in long-term) > > > DIT layout > ========== > DNSSEC key material > ------------------- > - Container: cn=keys, cn=sec, cn=dns, dc=example > - Private and public keys are stored as separate objects to accommodate all > PKCS#11 metadata. > - We need to decide about object naming: > - One obvious option for RDN is to use uniqueID but I don't like it. It is > hard to read for humans. > - Other option is to use uniqueID+PKCS#11 label or other attributes to make > it more readable. Can we use multi-valued RDN? If not, why? What are technical > reasons behind it? > > It is question if we like: > nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda > nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda > more than: > ipk11Label=meaningful_label+ipk11Private=TRUE > ipk11Label=meaningful_label+ipk11Private=FALSE dn: ipk11Label=zone1_keyid123_public, cn=keys, cn=sec, cn=dns, dc=example objectClass: ipk11Object objectClass: ipk11PublicKey objectClass: ipaPublicKeyObject ipk11UniqueId: ipk11Label: zone1_keyid123_public ipk11Wrap: FALSE ipk11Verify: TRUE ipaPublicKey: dn: ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, cn=dns, dc=example objectClass: ipk11Object objectClass: ipk11PrivateKey objectClass: ipaPrivateKeyObject objectClass: ipaWrappedKey ipaWrappingKey:ipk11Label=dnssec_m1,cn=master,cn=keys,cn=sec,cn=dns,dc=example ipk11Sign: TRUE ipk11Decrypt: FALSE ipk11Unwrap: FALSE ipaPrivateKey: > DNSSEC key metadata > ------------------- > - Container (per-zone): cn=keys, idnsname=example.net, cn=dns > - Key metadata can be linked to key material via DN or ipk11Id. > - This allows key sharing between zones. > (DNSSEC-metadata will be specified later. That is not important for key storage.) This will be sorted out in separate thread. > > Replica public keys > ------------------- > - Container: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example > - or it's child object like cn=wrappingKey - Please note that private part of this key is stored on disk. dn: ipk11Label=wrapkey_replica1,cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example objectClass: ipk11Object objectClass: ipk11PublicKey objectClass: ipaPublicKeyObject ipk11UniqueId: ipk11Label: wrapkey_replica1 ipk11Wrap: TRUE ipk11Encrypt: FALSE ipk11Verify: FALSE ipaPublicKey: > Master keys > ----------- > - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example > - Single key = single object. > - We can use ipk11Label or ipk11Id for naming: > ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. dn: ipk11Label=dnssec_m1, cn=master, cn=keys, cn=sec, cn=dns, dc=example objectClass: ipk11Object objectClass: ipk11SecretKey objectClass: ipaWrappedKey objectClass: ipaSecretKeyObject ipk11UniqueId: ipk11Label: dnssec_m1 ipk11Wrap: TRUE ipk11UnWrap: TRUE ipk11Encrypt: FALSE ipk11Decrypt: FALSE ipk11Sign: FALSE ipk11Verify: FALSE ipaWrappingAlgo: ipaSecretKeyWrappedData: ipaSecretKeyWrappedData: ipaWrappingKey: ipaWrappingKey: Petr^2 Spacek > Work flows > ========== > Read DNSSEC private key > ----------------------- > 1) read DNSSEC private key from LDAP > 2) ipaWrappedKey objectClass is present - key is encrypted > 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key object > 4) use local replica key to decrypt master key > 5) use decrypted master key to decrypt DNSSEC private key > > Add DNSSEC private key > ---------------------- > 1) use local replica key to decrypt master key > 2) encrypt DNSSEC private key with master key > 3) add ipaWrappingKey attribute pointing to master key > 4) store encrypted blob in a new LDAP object > > Add a replica > ------------- > ipa-replica-prepare: > 1) generate a new replica-key pair for the new replica > 2) store key pair to replica-file (don't scream yet :-) > 4) add public key for the new replica to LDAP > 3) fetch master key from LDAP > 4) encrypt master key with new replica public key > 5) store resulting master key blob to LDAP > ipa-replica-install: > 6) generate a new replica-key pair (!) > 7) store new public key to LDAP > 8) remove old public key (from replica-file) from LDAP > 9) fetch master key > 10) decrypt master key using old private key (from replica-file) > 11) encrypt master key using new private key (generated locally) > 12) replace old master key blob in LDAP with new blob (from step 11) > > Delete a replica > ---------------- > This is the tricky part. New master key has to be generated on some other > replica. What should we do if the ipa-replica-manage command was run on > deleted replica? > > I propose to split replica master key roll-over to two phases: > Any machine in IPA domain (including to-be deleted replica): > 1) Delete public key associated with replica from LDAP > 2) Flip a bit in master key metadata and say "this key needs to be > re-generated" > (Maybe we can disable ipk11Wrap boolean to indicate that this key should > not be used for key wrapping.) > > Remaining replicas: > 3) Periodically check that master key is obsolete > 4) Wait for (random period of time) to limit probability of collision > 5) Check that master key is really obsolete and new one is not present > 6) Generate a new master key > 7) Encrypt new master key with all replica-public-keys stored in LDAP > 8) Store new master key blobs to a new LDAP object > (Conflicts are not a problem up to now because we are not deleting old > key. In worst case, we will have multiple new master keys.) > *What should we do now?* > 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we have > write conflict now?) > ??? Let old keys there and wait until key rotation mechanism replaces > all old DNSSEC keys with new DNSSEC keys encrypted with a new master key (~ > one year)? > 10) Old master key can be deleted when no other object is referencing to it. > > > Congratulations to people who reached this line and didn't skip anything :-) > > [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 > [2] > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping > > [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects From npmccallum at redhat.com Thu Jun 12 14:27:04 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Jun 2014 10:27:04 -0400 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <5399B730.7040602@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> Message-ID: <1402583224.4842.4.camel@ipa.example.com> On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: > On 06/12/2014 03:15 PM, Tomas Babej wrote: > > > > On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: > >> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: > >>> On 06/12/2014 10:45 AM, Martin Kosek wrote: > >>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: > >>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: > >>>>>> Hi, > >>>>>> > >>>>>> As due to possible race conditions, the preop.pin might not be > >>>>>> written in the CS.cfg at the time installer tries to read it. > >>>>>> > >>>>>> In case no value for preop.pin was found, retry until timeout > >>>>>> was reached. > >>>>>> > >>>>>> https://fedorahosted.org/freeipa/ticket/3382 > >>>>>> > >>>>>> (applies on ipa-3-0 branch) > >>>>> There is inconsistent spacing around '='. For instance: > >>>>> + f=open(filename, 'r') > >>>>> + data = f.read() > >>>>> > >>>>> Also, I'm fairly certain this is incorrect: > >>>>> + total_timeout =+ 1 > >>>>> > >>>>> Nathaniel > >>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. > >>> Fixed. > >>> > >>>> I would rather see something like > >>>> > >>>> op_timeout = time.time() + api.env.startup_timeout > >>>> > >>>> while preop_pin is None and time.time() < op_timeout: > >>>> > >>>> > >>>> Also, I do not think this will work, IOError is risen when a file is not found, > >>>> so this code would not solve the problem if waiting on file to appear. > >>> Yes, but the problem was not in being unable to open the file, but that > >>> certain file content > >>> is not in the file yet. It seems that pkicreate creates the file in > >>> time, but the content written > >>> later and that causes the race condition. > >>> > >>> If you inspect the original code, and bugzilla, you can see that > >>> installation fails with: > >>> > >>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: > >>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? > >>> > >>> While the original code > >>> > >>> # read the config file and get the preop pin > >>> > >>> try: > >>> > >>> > >>> f=open(filename) > >>> > >>> except IOError, > >>> e: > >>> > >>> root_logger.error("Cannot open configuration file." + > >>> str(e)) > >>> raise > >>> e > >>> > >>> data = > >>> f.read() > >>> > >>> data = > >>> data.split('\n') > >>> > >>> pattern = re.compile("preop.pin=(.*)" > >>> ) > >>> for line in > >>> data: > >>> > >>> match = re.search(pattern, > >>> line) > >>> if > >>> (match): > >>> > >>> > >>> preop_pin=match.group(1) > >>> > >>> break > >>> if preop_pin is None: > >>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA > >>> already configured?" % filename) > >>> > >>> does raise the IOError in case the file was not able to be opened. Since > >>> we get the Runtime error, > >>> file must exist, only the desired content is missing. > >>> > >>> That said, I have no objections to amending the patch so that it > >>> properly handles this race condition > >>> we did not encounter. Better safe than sorry, it's a simple change and > >>> already included in the > >>> current iteration of the patch. > >>> > >>> Updated patch attached. > >> I think I would prefer something like inotify watching for > >> IN_CLOSE_WRITE rather than this polling. > >> > >> Nathaniel > >> > > Wouldn't that be a little bit of an overkill for that purpose? > > If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this > problem in current master as this issue only affects Dogtag 9 installation. > > The target is to have small, contained and the non-intrusive patch. Thus the > proposed solution to just implement a little wait loop. > > > > > - we'll need to introduce an additional dependency for python-inotify > > - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin > > written to CS.cfg (and we don't know that unless we inspect the code for > > pkicreate, which in turn would make our code dependant on code not > > located in our codebase), so we will still need to check if preop_pin is > > there, and loop over if not Sorry, I forgot this was for 3.0 branch. Nitpick: '=' spacing is still not fixed. Also, is it your intention to keep looping through the loop with no delay on IOError? If there is a race condition where this file isn't created yet, you could very likely get log spam. Nathaniel From tbabej at redhat.com Thu Jun 12 14:36:29 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Jun 2014 16:36:29 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <1402583224.4842.4.camel@ipa.example.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> <1402583224.4842.4.camel@ipa.example.com> Message-ID: <5399BAED.2090306@redhat.com> On 06/12/2014 04:27 PM, Nathaniel McCallum wrote: > On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: >> On 06/12/2014 03:15 PM, Tomas Babej wrote: >>> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: >>>> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: >>>>> On 06/12/2014 10:45 AM, Martin Kosek wrote: >>>>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> As due to possible race conditions, the preop.pin might not be >>>>>>>> written in the CS.cfg at the time installer tries to read it. >>>>>>>> >>>>>>>> In case no value for preop.pin was found, retry until timeout >>>>>>>> was reached. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3382 >>>>>>>> >>>>>>>> (applies on ipa-3-0 branch) >>>>>>> There is inconsistent spacing around '='. For instance: >>>>>>> + f=open(filename, 'r') >>>>>>> + data = f.read() >>>>>>> >>>>>>> Also, I'm fairly certain this is incorrect: >>>>>>> + total_timeout =+ 1 >>>>>>> >>>>>>> Nathaniel >>>>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. >>>>> Fixed. >>>>> >>>>>> I would rather see something like >>>>>> >>>>>> op_timeout = time.time() + api.env.startup_timeout >>>>>> >>>>>> while preop_pin is None and time.time() < op_timeout: >>>>>> >>>>>> >>>>>> Also, I do not think this will work, IOError is risen when a file is not found, >>>>>> so this code would not solve the problem if waiting on file to appear. >>>>> Yes, but the problem was not in being unable to open the file, but that >>>>> certain file content >>>>> is not in the file yet. It seems that pkicreate creates the file in >>>>> time, but the content written >>>>> later and that causes the race condition. >>>>> >>>>> If you inspect the original code, and bugzilla, you can see that >>>>> installation fails with: >>>>> >>>>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: >>>>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? >>>>> >>>>> While the original code >>>>> >>>>> # read the config file and get the preop pin >>>>> >>>>> try: >>>>> >>>>> >>>>> f=open(filename) >>>>> >>>>> except IOError, >>>>> e: >>>>> >>>>> root_logger.error("Cannot open configuration file." + >>>>> str(e)) >>>>> raise >>>>> e >>>>> >>>>> data = >>>>> f.read() >>>>> >>>>> data = >>>>> data.split('\n') >>>>> >>>>> pattern = re.compile("preop.pin=(.*)" >>>>> ) >>>>> for line in >>>>> data: >>>>> >>>>> match = re.search(pattern, >>>>> line) >>>>> if >>>>> (match): >>>>> >>>>> >>>>> preop_pin=match.group(1) >>>>> >>>>> break >>>>> if preop_pin is None: >>>>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA >>>>> already configured?" % filename) >>>>> >>>>> does raise the IOError in case the file was not able to be opened. Since >>>>> we get the Runtime error, >>>>> file must exist, only the desired content is missing. >>>>> >>>>> That said, I have no objections to amending the patch so that it >>>>> properly handles this race condition >>>>> we did not encounter. Better safe than sorry, it's a simple change and >>>>> already included in the >>>>> current iteration of the patch. >>>>> >>>>> Updated patch attached. >>>> I think I would prefer something like inotify watching for >>>> IN_CLOSE_WRITE rather than this polling. >>>> >>>> Nathaniel >>>> >>> Wouldn't that be a little bit of an overkill for that purpose? >> If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this >> problem in current master as this issue only affects Dogtag 9 installation. >> >> The target is to have small, contained and the non-intrusive patch. Thus the >> proposed solution to just implement a little wait loop. >> >>> - we'll need to introduce an additional dependency for python-inotify >>> - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin >>> written to CS.cfg (and we don't know that unless we inspect the code for >>> pkicreate, which in turn would make our code dependant on code not >>> located in our codebase), so we will still need to check if preop_pin is >>> there, and loop over if not > Sorry, I forgot this was for 3.0 branch. > > Nitpick: '=' spacing is still not fixed. I fixed the spacing. > Also, is it your intention to keep looping through the loop with no > delay on IOError? If there is a race condition where this file isn't > created yet, you could very likely get log spam. Read the patch more carefully please. There is delay on IOError (preop_pin is still None, since we jumped out of the try block when the exception occured at the opening of the file and therefore had no chance to set it to something else than None). > Nathaniel > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0224-3-cainstance-Read-CS.cfg-for-preop.pin-in-a-loop.patch Type: text/x-patch Size: 2860 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jun 12 14:45:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Jun 2014 10:45:15 -0400 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <5399BAED.2090306@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> <1402583224.4842.4.camel@ipa.example.com> <5399BAED.2090306@redhat.com> Message-ID: <1402584315.4842.6.camel@ipa.example.com> On Thu, 2014-06-12 at 16:36 +0200, Tomas Babej wrote: > On 06/12/2014 04:27 PM, Nathaniel McCallum wrote: > > On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: > >> On 06/12/2014 03:15 PM, Tomas Babej wrote: > >>> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: > >>>> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: > >>>>> On 06/12/2014 10:45 AM, Martin Kosek wrote: > >>>>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: > >>>>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> As due to possible race conditions, the preop.pin might not be > >>>>>>>> written in the CS.cfg at the time installer tries to read it. > >>>>>>>> > >>>>>>>> In case no value for preop.pin was found, retry until timeout > >>>>>>>> was reached. > >>>>>>>> > >>>>>>>> https://fedorahosted.org/freeipa/ticket/3382 > >>>>>>>> > >>>>>>>> (applies on ipa-3-0 branch) > >>>>>>> There is inconsistent spacing around '='. For instance: > >>>>>>> + f=open(filename, 'r') > >>>>>>> + data = f.read() > >>>>>>> > >>>>>>> Also, I'm fairly certain this is incorrect: > >>>>>>> + total_timeout =+ 1 > >>>>>>> > >>>>>>> Nathaniel > >>>>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. > >>>>> Fixed. > >>>>> > >>>>>> I would rather see something like > >>>>>> > >>>>>> op_timeout = time.time() + api.env.startup_timeout > >>>>>> > >>>>>> while preop_pin is None and time.time() < op_timeout: > >>>>>> > >>>>>> > >>>>>> Also, I do not think this will work, IOError is risen when a file is not found, > >>>>>> so this code would not solve the problem if waiting on file to appear. > >>>>> Yes, but the problem was not in being unable to open the file, but that > >>>>> certain file content > >>>>> is not in the file yet. It seems that pkicreate creates the file in > >>>>> time, but the content written > >>>>> later and that causes the race condition. > >>>>> > >>>>> If you inspect the original code, and bugzilla, you can see that > >>>>> installation fails with: > >>>>> > >>>>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: > >>>>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? > >>>>> > >>>>> While the original code > >>>>> > >>>>> # read the config file and get the preop pin > >>>>> > >>>>> try: > >>>>> > >>>>> > >>>>> f=open(filename) > >>>>> > >>>>> except IOError, > >>>>> e: > >>>>> > >>>>> root_logger.error("Cannot open configuration file." + > >>>>> str(e)) > >>>>> raise > >>>>> e > >>>>> > >>>>> data = > >>>>> f.read() > >>>>> > >>>>> data = > >>>>> data.split('\n') > >>>>> > >>>>> pattern = re.compile("preop.pin=(.*)" > >>>>> ) > >>>>> for line in > >>>>> data: > >>>>> > >>>>> match = re.search(pattern, > >>>>> line) > >>>>> if > >>>>> (match): > >>>>> > >>>>> > >>>>> preop_pin=match.group(1) > >>>>> > >>>>> break > >>>>> if preop_pin is None: > >>>>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA > >>>>> already configured?" % filename) > >>>>> > >>>>> does raise the IOError in case the file was not able to be opened. Since > >>>>> we get the Runtime error, > >>>>> file must exist, only the desired content is missing. > >>>>> > >>>>> That said, I have no objections to amending the patch so that it > >>>>> properly handles this race condition > >>>>> we did not encounter. Better safe than sorry, it's a simple change and > >>>>> already included in the > >>>>> current iteration of the patch. > >>>>> > >>>>> Updated patch attached. > >>>> I think I would prefer something like inotify watching for > >>>> IN_CLOSE_WRITE rather than this polling. > >>>> > >>>> Nathaniel > >>>> > >>> Wouldn't that be a little bit of an overkill for that purpose? > >> If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this > >> problem in current master as this issue only affects Dogtag 9 installation. > >> > >> The target is to have small, contained and the non-intrusive patch. Thus the > >> proposed solution to just implement a little wait loop. > >> > >>> - we'll need to introduce an additional dependency for python-inotify > >>> - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin > >>> written to CS.cfg (and we don't know that unless we inspect the code for > >>> pkicreate, which in turn would make our code dependant on code not > >>> located in our codebase), so we will still need to check if preop_pin is > >>> there, and loop over if not > > Sorry, I forgot this was for 3.0 branch. > > > > Nitpick: '=' spacing is still not fixed. > I fixed the spacing. > > > Also, is it your intention to keep looping through the loop with no > > delay on IOError? If there is a race condition where this file isn't > > created yet, you could very likely get log spam. > Read the patch more carefully please. There is delay on IOError > (preop_pin is still > None, since we jumped out of the try block when the exception occured at the > opening of the file and therefore had no chance to set it to something > else than None). Ah, good point. One more issue. In the case of an exception during f.read(), the file descriptor is leaked (in a loop). Why not do something like (is 3.x's python new enough for with?): with open(filename, 'r') as f: data = f.read() ... In any case, the file can be closed immediately after the read(). Nathaniel From tbabej at redhat.com Thu Jun 12 15:07:57 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 12 Jun 2014 17:07:57 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <1402584315.4842.6.camel@ipa.example.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> <1402583224.4842.4.camel@ipa.example.com> <5399BAED.2090306@redhat.com> <1402584315.4842.6.camel@ipa.example.com> Message-ID: <5399C24D.1020207@redhat.com> On 06/12/2014 04:45 PM, Nathaniel McCallum wrote: > On Thu, 2014-06-12 at 16:36 +0200, Tomas Babej wrote: >> On 06/12/2014 04:27 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: >>>> On 06/12/2014 03:15 PM, Tomas Babej wrote: >>>>> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: >>>>>>> On 06/12/2014 10:45 AM, Martin Kosek wrote: >>>>>>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >>>>>>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As due to possible race conditions, the preop.pin might not be >>>>>>>>>> written in the CS.cfg at the time installer tries to read it. >>>>>>>>>> >>>>>>>>>> In case no value for preop.pin was found, retry until timeout >>>>>>>>>> was reached. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3382 >>>>>>>>>> >>>>>>>>>> (applies on ipa-3-0 branch) >>>>>>>>> There is inconsistent spacing around '='. For instance: >>>>>>>>> + f=open(filename, 'r') >>>>>>>>> + data = f.read() >>>>>>>>> >>>>>>>>> Also, I'm fairly certain this is incorrect: >>>>>>>>> + total_timeout =+ 1 >>>>>>>>> >>>>>>>>> Nathaniel >>>>>>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. >>>>>>> Fixed. >>>>>>> >>>>>>>> I would rather see something like >>>>>>>> >>>>>>>> op_timeout = time.time() + api.env.startup_timeout >>>>>>>> >>>>>>>> while preop_pin is None and time.time() < op_timeout: >>>>>>>> >>>>>>>> >>>>>>>> Also, I do not think this will work, IOError is risen when a file is not found, >>>>>>>> so this code would not solve the problem if waiting on file to appear. >>>>>>> Yes, but the problem was not in being unable to open the file, but that >>>>>>> certain file content >>>>>>> is not in the file yet. It seems that pkicreate creates the file in >>>>>>> time, but the content written >>>>>>> later and that causes the race condition. >>>>>>> >>>>>>> If you inspect the original code, and bugzilla, you can see that >>>>>>> installation fails with: >>>>>>> >>>>>>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: >>>>>>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? >>>>>>> >>>>>>> While the original code >>>>>>> >>>>>>> # read the config file and get the preop pin >>>>>>> >>>>>>> try: >>>>>>> >>>>>>> >>>>>>> f=open(filename) >>>>>>> >>>>>>> except IOError, >>>>>>> e: >>>>>>> >>>>>>> root_logger.error("Cannot open configuration file." + >>>>>>> str(e)) >>>>>>> raise >>>>>>> e >>>>>>> >>>>>>> data = >>>>>>> f.read() >>>>>>> >>>>>>> data = >>>>>>> data.split('\n') >>>>>>> >>>>>>> pattern = re.compile("preop.pin=(.*)" >>>>>>> ) >>>>>>> for line in >>>>>>> data: >>>>>>> >>>>>>> match = re.search(pattern, >>>>>>> line) >>>>>>> if >>>>>>> (match): >>>>>>> >>>>>>> >>>>>>> preop_pin=match.group(1) >>>>>>> >>>>>>> break >>>>>>> if preop_pin is None: >>>>>>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA >>>>>>> already configured?" % filename) >>>>>>> >>>>>>> does raise the IOError in case the file was not able to be opened. Since >>>>>>> we get the Runtime error, >>>>>>> file must exist, only the desired content is missing. >>>>>>> >>>>>>> That said, I have no objections to amending the patch so that it >>>>>>> properly handles this race condition >>>>>>> we did not encounter. Better safe than sorry, it's a simple change and >>>>>>> already included in the >>>>>>> current iteration of the patch. >>>>>>> >>>>>>> Updated patch attached. >>>>>> I think I would prefer something like inotify watching for >>>>>> IN_CLOSE_WRITE rather than this polling. >>>>>> >>>>>> Nathaniel >>>>>> >>>>> Wouldn't that be a little bit of an overkill for that purpose? >>>> If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this >>>> problem in current master as this issue only affects Dogtag 9 installation. >>>> >>>> The target is to have small, contained and the non-intrusive patch. Thus the >>>> proposed solution to just implement a little wait loop. >>>> >>>>> - we'll need to introduce an additional dependency for python-inotify >>>>> - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin >>>>> written to CS.cfg (and we don't know that unless we inspect the code for >>>>> pkicreate, which in turn would make our code dependant on code not >>>>> located in our codebase), so we will still need to check if preop_pin is >>>>> there, and loop over if not >>> Sorry, I forgot this was for 3.0 branch. >>> >>> Nitpick: '=' spacing is still not fixed. >> I fixed the spacing. >> >>> Also, is it your intention to keep looping through the loop with no >>> delay on IOError? If there is a race condition where this file isn't >>> created yet, you could very likely get log spam. >> Read the patch more carefully please. There is delay on IOError >> (preop_pin is still >> None, since we jumped out of the try block when the exception occured at the >> opening of the file and therefore had no chance to set it to something >> else than None). > Ah, good point. > > One more issue. In the case of an exception during f.read(), the file > descriptor is leaked (in a loop). Why not do something like (is 3.x's > python new enough for with?): > > with open(filename, 'r') as f: > data = f.read() > ... > > In any case, the file can be closed immediately after the read(). > > Nathaniel > It is (available from python 2.6). I did not mean to refactor the old code, but you raise a point so I did convert the block to somewhat more pythonic code. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0224-4-cainstance-Read-CS.cfg-for-preop.pin-in-a-loop.patch Type: text/x-patch Size: 2743 bytes Desc: not available URL: From pspacek at redhat.com Thu Jun 12 15:08:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 Jun 2014 17:08:32 +0200 Subject: [Freeipa-devel] DNSSEC key metadata handling Message-ID: <5399C270.1060608@redhat.com> Hello list, I have realized that we need to store certain DNSSEC metadata for every (zone,key,replica) triplet. It is necessary to handle splits in replication topology. DNSSEC key can be in one of following states: - key created - published but not used for signing - published and used for signing - published and not used for signing but old signatures exist - unpublished Every state transition has to be postponed until relevant TTL expires, and of course, we need to consider TTL on all replicas. Example of a problem ==================== DNS TTL=10 units Key life time=100 units Replica=1 Key=1 Time=0 Published Replica=2 Key=1 Time=0 Published Replica=1 Key=1 Time=10 Published, signing Replica=2 Key=1 Time=10 Published, signing Replica=1 Key=2 Time=90 Generated, published, not signing yet Replica=2 Key=2 Time=90 Replica=1 Key=1 Time=100 ^^^ From time=100, all new signatures should be created with key=2 but that can break DNSSEC validation because key=2 is not available on replica=2. Proposal 1 ========== - Store state and timestamps for (zone,key,replica) triplet - Do state transition only if all triplets (zone,key,?) indicate that all replicas reached desired state so the transition is safe. - This implicitly means that no transition will happen if one or more replicas is down. This is necessary otherwise DNSSEC validation can break mysteriously when keys got out of sync. dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, cn=dns, dc=example idnssecKeyCreated: idnssecKeyPublished: idnssecKeyActivated: idnssecKeyInactivated: idnssecKeyDeleted: Effectively, state machine will be controlled by max(attribute) over all replicas (for given key). Replication traffic estimation ------------------------------ Number of writes to LDAP = (State transitions per key) * (Keys per zone) * (Number of zones) * (Number of replicas) The obvious problem is that amount of traffic grows linearly with all variables. State transitions per key: 5 Keys per zone: 10 Zones: 100 Replicas: 30 Key life time: 1 month 5*10*100*30 / 1 month i.e. 150 000 writes / 1 month i.e. ~ 1 write / 17 seconds It seems like that this generates a lot of replication traffic. (Please note that number of replicas/zones/keys per zone is also quite high but it will be hard to improve scalability later if we decide to use LDAP in this way.) And ... our favorite question :-) What should I use for cn= ? I would propose use either FQDN of replica or value returned by LDAP whoami. Proposal 2 ========== Another possibility is to make timestamp attributes non-replicated and (somehow) use DNS queries to determine if the desired key is available on all other replicas before any state transition is allowed. That would require: - Full-mesh replica-to-replica connectivity - Similar amount of DNS query/response round trips (multiply ) - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS answers and break key rotation mechanism during bootstrap (when no keys are available) and maybe even later. It is easy to detect that key is: - published - unpublished - used for signing The problem is that there is no reliable way to detect that is a key was created/is available on replica but is not published yet and similarly that the key is published but not used for signing anymore (it would require to check all names published in the zone). I will think about it a bit more but I would like to know if full-mesh replica-to-replica connectivity is acceptable requirement or not. Almost-joke-proposal ==================== The other alternative is to invent other mechanism for synchronous replica-to-replica communication... -- Petr^2 Spacek From simo at redhat.com Thu Jun 12 15:19:53 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Jun 2014 11:19:53 -0400 Subject: [Freeipa-devel] DNSSEC key metadata handling In-Reply-To: <5399C270.1060608@redhat.com> References: <5399C270.1060608@redhat.com> Message-ID: <1402586393.22737.42.camel@willson.usersys.redhat.com> On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: > Hello list, > > I have realized that we need to store certain DNSSEC metadata for every > (zone,key,replica) triplet. It is necessary to handle splits in replication > topology. > > DNSSEC key can be in one of following states: > - key created > - published but not used for signing > - published and used for signing > - published and not used for signing but old signatures exist > - unpublished > > Every state transition has to be postponed until relevant TTL expires, and of > course, we need to consider TTL on all replicas. > > > Example of a problem > ==================== > DNS TTL=10 units > Key life time=100 units > > Replica=1 Key=1 Time=0 Published > Replica=2 Key=1 Time=0 Published > Replica=1 Key=1 Time=10 Published, signing > Replica=2 Key=1 Time=10 Published, signing > Replica=1 Key=2 Time=90 Generated, published, not signing yet > Replica=2 Key=2 Time=90 > Replica=1 Key=1 Time=100 > ^^^ From time=100, all new signatures should be created with key=2 but that > can break DNSSEC validation because key=2 is not available on replica=2. Can you explain how this break validation ? Aren't signatures regenerated on each replica ? And so isn't each replica self-consistent ? > Proposal 1 > ========== > - Store state and timestamps for (zone,key,replica) triplet > - Do state transition only if all triplets (zone,key,?) indicate that all > replicas reached desired state so the transition is safe. > - This implicitly means that no transition will happen if one or more replicas > is down. This is necessary otherwise DNSSEC validation can break mysteriously > when keys got out of sync. > > dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, > cn=dns, dc=example > idnssecKeyCreated: > idnssecKeyPublished: > idnssecKeyActivated: > idnssecKeyInactivated: > idnssecKeyDeleted: Why do you care for all 5 states ? It looks to me the only relevant states are Activated and (perhaps) Deactivated. But then again if replication is broken *many* other things are, so should we *really* care to handle broken replication by adding all this information ? > Effectively, state machine will be controlled by max(attribute) over all > replicas (for given key). > > Replication traffic estimation > ------------------------------ > Number of writes to LDAP = (State transitions per key) * (Keys per zone) * > (Number of zones) * (Number of replicas) > > The obvious problem is that amount of traffic grows linearly with all variables. > > State transitions per key: 5 > Keys per zone: 10 > Zones: 100 > Replicas: 30 > Key life time: 1 month > > 5*10*100*30 / 1 month > i.e. > 150 000 writes / 1 month > i.e. > ~ 1 write / 17 seconds > > It seems like that this generates a lot of replication traffic. (Please note > that number of replicas/zones/keys per zone is also quite high but it will be > hard to improve scalability later if we decide to use LDAP in this way.) Right, and for an edge case that is already a broken state. I would rather spend time on a monitoring process that warns the amdin replication is broken rather than adding all this unnecessary traffic. > And ... our favorite question :-) > What should I use for cn= ? I would propose use either FQDN > of replica or value returned by LDAP whoami. Add to this dealing with dead/removed replicas ? I question the sanity of this approach :) > Proposal 2 > ========== > Another possibility is to make timestamp attributes non-replicated and > (somehow) use DNS queries to determine if the desired key is available on all > other replicas before any state transition is allowed. > > That would require: > - Full-mesh replica-to-replica connectivity > - Similar amount of DNS query/response round trips (multiply ) > - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS > answers and break key rotation mechanism during bootstrap (when no keys are > available) and maybe even later. > > It is easy to detect that key is: > - published > - unpublished > - used for signing > > The problem is that there is no reliable way to detect that is a key was > created/is available on replica but is not published yet and similarly that > the key is published but not used for signing anymore (it would require to > check all names published in the zone). > > I will think about it a bit more but I would like to know if full-mesh > replica-to-replica connectivity is acceptable requirement or not. Not really, and again I question the need to do this. > Almost-joke-proposal > ==================== > The other alternative is to invent other mechanism for synchronous > replica-to-replica communication... Also called zone transfer ? :-P Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Thu Jun 12 15:25:13 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Jun 2014 10:25:13 -0500 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <538473E0.6070702@redhat.com> References: <538473E0.6070702@redhat.com> Message-ID: <5399C659.30109@redhat.com> On 5/27/2014 6:15 AM, Petr Vobornik wrote: > This is just a first draft of implementation of > https://fedorahosted.org/freeipa/ticket/4345 > > It introduces a `freeipa/extend` module which should serve as a more > stable API for Web UI plugins. I think it requires further discussion - > what to have there, the level of abstraction... > > Other patches fixes navigation/router to support custom URL path patterns. > > The usage of facet.create_hash(router) method in patch #649 is > questionable. > > The WIP patch contains an example of a plugin which uses this > functionality. Some comments: 1. As discussed on IRC, the plugin is causing an error due to missing extend.js. This needs to be fixed. 2. Also discussed, a base widget class for StateWidget might help providing a structure and simplifying the plugin code by defining the default widget behavior (e.g. event registration). 3. Related to inheritance, instead of conditionally calling a method like this: if (facet.create_hash) return facet.create_hash(router); // otherwise, do the default behavior if we use inheritance it could be simplified like this: return facet.create_hash(router); So the method will "do the default behavior" as defined in the base class unless it's overridden by the subclass. 4. I agree that the facet shouldn't define the hash. The hash should be part of the plugin declaration. 5. Also discussed about moving away from declarative entity/facet definitions into template-based framework. It could help reduce the code complexity. -- Endi S. Dewata From pspacek at redhat.com Thu Jun 12 15:49:52 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 12 Jun 2014 17:49:52 +0200 Subject: [Freeipa-devel] DNSSEC key metadata handling In-Reply-To: <1402586393.22737.42.camel@willson.usersys.redhat.com> References: <5399C270.1060608@redhat.com> <1402586393.22737.42.camel@willson.usersys.redhat.com> Message-ID: <5399CC20.9090907@redhat.com> On 12.6.2014 17:19, Simo Sorce wrote: > On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: >> Hello list, >> >> I have realized that we need to store certain DNSSEC metadata for every >> (zone,key,replica) triplet. It is necessary to handle splits in replication >> topology. >> >> DNSSEC key can be in one of following states: >> - key created >> - published but not used for signing >> - published and used for signing >> - published and not used for signing but old signatures exist >> - unpublished >> >> Every state transition has to be postponed until relevant TTL expires, and of >> course, we need to consider TTL on all replicas. >> >> >> Example of a problem >> ==================== >> DNS TTL=10 units >> Key life time=100 units >> >> Replica=1 Key=1 Time=0 Published >> Replica=2 Key=1 Time=0 Published >> Replica=1 Key=1 Time=10 Published, signing >> Replica=2 Key=1 Time=10 Published, signing >> Replica=1 Key=2 Time=90 Generated, published, not signing yet >> Replica=2 Key=2 Time=90 >> Replica=1 Key=1 Time=100 >> ^^^ From time=100, all new signatures should be created with key=2 but that >> can break DNSSEC validation because key=2 is not available on replica=2. > > Can you explain how this break validation ? > Aren't signatures regenerated on each replica ? They are. > And so isn't each replica self-consistent ? Ah, sorry, I didn't mention one important detail. Keys published in the zone 'example.com.' have to match keys published in parent zone. There has to be a mechanism for synchronizing this. Validation will break if (keys published by parent) are not subset of (keys on replicas). Next logical step in the example above is to remove key1 from replica 1 so you will end replica1 having key2 and replica2 having only key1. How can we guarantee that synchronization mechanism will not wipe key1 from parent? Or the other way around? How can we guarantee that key2 was uploaded? Also, things will break is number of keys in parent exceeds reasonable number (because DNS replies will be to big etc.). >> Proposal 1 >> ========== >> - Store state and timestamps for (zone,key,replica) triplet >> - Do state transition only if all triplets (zone,key,?) indicate that all >> replicas reached desired state so the transition is safe. >> - This implicitly means that no transition will happen if one or more replicas >> is down. This is necessary otherwise DNSSEC validation can break mysteriously >> when keys got out of sync. >> >> dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, >> cn=dns, dc=example >> idnssecKeyCreated: >> idnssecKeyPublished: >> idnssecKeyActivated: >> idnssecKeyInactivated: >> idnssecKeyDeleted: > > Why do you care for all 5 states ? In short, to follow RFC 6781 and all it's requirements. > It looks to me the only relevant states are Activated and (perhaps) > Deactivated. > > But then again if replication is broken *many* other things are, so > should we *really* care to handle broken replication by adding all this > information ? We need to keep track of timestamps anyway (to follow RFC 6781) so we need some other way how to *make sure* that timestamps never go backwards, even if replication was broken and later restarted. What do you propose? >> Effectively, state machine will be controlled by max(attribute) over all >> replicas (for given key). >> >> Replication traffic estimation >> ------------------------------ >> Number of writes to LDAP = (State transitions per key) * (Keys per zone) * >> (Number of zones) * (Number of replicas) >> >> The obvious problem is that amount of traffic grows linearly with all variables. >> >> State transitions per key: 5 >> Keys per zone: 10 >> Zones: 100 >> Replicas: 30 >> Key life time: 1 month >> >> 5*10*100*30 / 1 month >> i.e. >> 150 000 writes / 1 month >> i.e. >> ~ 1 write / 17 seconds >> >> It seems like that this generates a lot of replication traffic. (Please note >> that number of replicas/zones/keys per zone is also quite high but it will be >> hard to improve scalability later if we decide to use LDAP in this way.) > > Right, and for an edge case that is already a broken state. I would > rather spend time on a monitoring process that warns the amdin > replication is broken rather than adding all this unnecessary traffic. > >> And ... our favorite question :-) >> What should I use for cn= ? I would propose use either FQDN >> of replica or value returned by LDAP whoami. > > Add to this dealing with dead/removed replicas ? I question the sanity > of this approach :) > >> Proposal 2 >> ========== >> Another possibility is to make timestamp attributes non-replicated and >> (somehow) use DNS queries to determine if the desired key is available on all >> other replicas before any state transition is allowed. >> >> That would require: >> - Full-mesh replica-to-replica connectivity >> - Similar amount of DNS query/response round trips (multiply ) >> - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS >> answers and break key rotation mechanism during bootstrap (when no keys are >> available) and maybe even later. >> >> It is easy to detect that key is: >> - published >> - unpublished >> - used for signing >> >> The problem is that there is no reliable way to detect that is a key was >> created/is available on replica but is not published yet and similarly that >> the key is published but not used for signing anymore (it would require to >> check all names published in the zone). >> >> I will think about it a bit more but I would like to know if full-mesh >> replica-to-replica connectivity is acceptable requirement or not. > > Not really, and again I question the need to do this. > >> Almost-joke-proposal >> ==================== >> The other alternative is to invent other mechanism for synchronous >> replica-to-replica communication... > > Also called zone transfer ? :-P Which is extremely expensive as mere existence check... :-) I have to leave for today, let me know if you are interested in some details. Have a nice day! -- Petr^2 Spacek From npmccallum at redhat.com Thu Jun 12 16:22:47 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Jun 2014 12:22:47 -0400 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <5399C24D.1020207@redhat.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> <1402583224.4842.4.camel@ipa.example.com> <5399BAED.2090306@redhat.com> <1402584315.4842.6.camel@ipa.example.com> <5399C24D.1020207@redhat.com> Message-ID: <1402590167.4842.8.camel@ipa.example.com> On Thu, 2014-06-12 at 17:07 +0200, Tomas Babej wrote: > On 06/12/2014 04:45 PM, Nathaniel McCallum wrote: > > On Thu, 2014-06-12 at 16:36 +0200, Tomas Babej wrote: > >> On 06/12/2014 04:27 PM, Nathaniel McCallum wrote: > >>> On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: > >>>> On 06/12/2014 03:15 PM, Tomas Babej wrote: > >>>>> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: > >>>>>> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: > >>>>>>> On 06/12/2014 10:45 AM, Martin Kosek wrote: > >>>>>>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: > >>>>>>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> As due to possible race conditions, the preop.pin might not be > >>>>>>>>>> written in the CS.cfg at the time installer tries to read it. > >>>>>>>>>> > >>>>>>>>>> In case no value for preop.pin was found, retry until timeout > >>>>>>>>>> was reached. > >>>>>>>>>> > >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3382 > >>>>>>>>>> > >>>>>>>>>> (applies on ipa-3-0 branch) > >>>>>>>>> There is inconsistent spacing around '='. For instance: > >>>>>>>>> + f=open(filename, 'r') > >>>>>>>>> + data = f.read() > >>>>>>>>> > >>>>>>>>> Also, I'm fairly certain this is incorrect: > >>>>>>>>> + total_timeout =+ 1 > >>>>>>>>> > >>>>>>>>> Nathaniel > >>>>>>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. > >>>>>>> Fixed. > >>>>>>> > >>>>>>>> I would rather see something like > >>>>>>>> > >>>>>>>> op_timeout = time.time() + api.env.startup_timeout > >>>>>>>> > >>>>>>>> while preop_pin is None and time.time() < op_timeout: > >>>>>>>> > >>>>>>>> > >>>>>>>> Also, I do not think this will work, IOError is risen when a file is not found, > >>>>>>>> so this code would not solve the problem if waiting on file to appear. > >>>>>>> Yes, but the problem was not in being unable to open the file, but that > >>>>>>> certain file content > >>>>>>> is not in the file yet. It seems that pkicreate creates the file in > >>>>>>> time, but the content written > >>>>>>> later and that causes the race condition. > >>>>>>> > >>>>>>> If you inspect the original code, and bugzilla, you can see that > >>>>>>> installation fails with: > >>>>>>> > >>>>>>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: > >>>>>>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? > >>>>>>> > >>>>>>> While the original code > >>>>>>> > >>>>>>> # read the config file and get the preop pin > >>>>>>> > >>>>>>> try: > >>>>>>> > >>>>>>> > >>>>>>> f=open(filename) > >>>>>>> > >>>>>>> except IOError, > >>>>>>> e: > >>>>>>> > >>>>>>> root_logger.error("Cannot open configuration file." + > >>>>>>> str(e)) > >>>>>>> raise > >>>>>>> e > >>>>>>> > >>>>>>> data = > >>>>>>> f.read() > >>>>>>> > >>>>>>> data = > >>>>>>> data.split('\n') > >>>>>>> > >>>>>>> pattern = re.compile("preop.pin=(.*)" > >>>>>>> ) > >>>>>>> for line in > >>>>>>> data: > >>>>>>> > >>>>>>> match = re.search(pattern, > >>>>>>> line) > >>>>>>> if > >>>>>>> (match): > >>>>>>> > >>>>>>> > >>>>>>> preop_pin=match.group(1) > >>>>>>> > >>>>>>> break > >>>>>>> if preop_pin is None: > >>>>>>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA > >>>>>>> already configured?" % filename) > >>>>>>> > >>>>>>> does raise the IOError in case the file was not able to be opened. Since > >>>>>>> we get the Runtime error, > >>>>>>> file must exist, only the desired content is missing. > >>>>>>> > >>>>>>> That said, I have no objections to amending the patch so that it > >>>>>>> properly handles this race condition > >>>>>>> we did not encounter. Better safe than sorry, it's a simple change and > >>>>>>> already included in the > >>>>>>> current iteration of the patch. > >>>>>>> > >>>>>>> Updated patch attached. > >>>>>> I think I would prefer something like inotify watching for > >>>>>> IN_CLOSE_WRITE rather than this polling. > >>>>>> > >>>>>> Nathaniel > >>>>>> > >>>>> Wouldn't that be a little bit of an overkill for that purpose? > >>>> If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this > >>>> problem in current master as this issue only affects Dogtag 9 installation. > >>>> > >>>> The target is to have small, contained and the non-intrusive patch. Thus the > >>>> proposed solution to just implement a little wait loop. > >>>> > >>>>> - we'll need to introduce an additional dependency for python-inotify > >>>>> - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin > >>>>> written to CS.cfg (and we don't know that unless we inspect the code for > >>>>> pkicreate, which in turn would make our code dependant on code not > >>>>> located in our codebase), so we will still need to check if preop_pin is > >>>>> there, and loop over if not > >>> Sorry, I forgot this was for 3.0 branch. > >>> > >>> Nitpick: '=' spacing is still not fixed. > >> I fixed the spacing. > >> > >>> Also, is it your intention to keep looping through the loop with no > >>> delay on IOError? If there is a race condition where this file isn't > >>> created yet, you could very likely get log spam. > >> Read the patch more carefully please. There is delay on IOError > >> (preop_pin is still > >> None, since we jumped out of the try block when the exception occured at the > >> opening of the file and therefore had no chance to set it to something > >> else than None). > > Ah, good point. > > > > One more issue. In the case of an exception during f.read(), the file > > descriptor is leaked (in a loop). Why not do something like (is 3.x's > > python new enough for with?): > > > > with open(filename, 'r') as f: > > data = f.read() > > ... > > > > In any case, the file can be closed immediately after the read(). > > > > Nathaniel > > > It is (available from python 2.6). > > I did not mean to refactor the old code, but you raise a point so I did > convert the block to somewhat more pythonic code. Yup, understood. The leak pre-existed your modifications. But putting the leak into a loop makes it worth fixing. Looks good to me now! ACK From jcholast at redhat.com Thu Jun 12 17:45:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Jun 2014 19:45:45 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP Message-ID: <5399E749.6070806@redhat.com> Hi, the attached patches implement and . This work depends on my patches 241-253 and 262-266 (). Note that automatic distribution of CA certificates to IPA systems is not implemented yet (it's planned for IPA 4.2, see ), so /etc/ipa/ca.crt, /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated *only* during client/server install. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 9914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 3603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 6714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 12123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282-Add-method-for-adding-certificates-by-value-to-NSSDa.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 1938 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 2309 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 4246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 3379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4588 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 7056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 9692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3329 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 13 07:05:50 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 09:05:50 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <5399E749.6070806@redhat.com> References: <5399E749.6070806@redhat.com> Message-ID: <539AA2CE.4080602@redhat.com> On 06/12/2014 07:45 PM, Jan Cholasta wrote: ... > Note that automatic distribution of CA certificates to IPA systems is not > implemented yet (it's planned for IPA 4.2, see > ), so /etc/ipa/ca.crt, > /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated *only* > during client/server install. > > Honza For 4.0, we will need to come up with manual procedure how to renew the certificates *without* reinstalling the client or server. I think the best way would be to prepare a simple script to renew client/server, something like /usr/share/ipa/ipa-renew-client-certificate /usr/share/ipa/ipa-renew-server-certificate and refer to it in the ipa-cacert-manage man page. People could then pretty easily run those after a cert change, using whatever means their infrastructure uses - puppet, ssh, ... Martin From mkosek at redhat.com Fri Jun 13 07:11:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 09:11:01 +0200 Subject: [Freeipa-devel] [PATCH 0224] cainstance: Read CS.cfg for preop.pin in a loop In-Reply-To: <1402590167.4842.8.camel@ipa.example.com> References: <53981C8E.6000600@redhat.com> <1402505346.2955.19.camel@ipa.example.com> <5399689D.10203@redhat.com> <53998F2A.6060703@redhat.com> <1402576639.4842.1.camel@ipa.example.com> <5399A7FC.4090305@redhat.com> <5399B730.7040602@redhat.com> <1402583224.4842.4.camel@ipa.example.com> <5399BAED.2090306@redhat.com> <1402584315.4842.6.camel@ipa.example.com> <5399C24D.1020207@redhat.com> <1402590167.4842.8.camel@ipa.example.com> Message-ID: <539AA405.2040102@redhat.com> On 06/12/2014 06:22 PM, Nathaniel McCallum wrote: > On Thu, 2014-06-12 at 17:07 +0200, Tomas Babej wrote: >> On 06/12/2014 04:45 PM, Nathaniel McCallum wrote: >>> On Thu, 2014-06-12 at 16:36 +0200, Tomas Babej wrote: >>>> On 06/12/2014 04:27 PM, Nathaniel McCallum wrote: >>>>> On Thu, 2014-06-12 at 16:20 +0200, Martin Kosek wrote: >>>>>> On 06/12/2014 03:15 PM, Tomas Babej wrote: >>>>>>> On 06/12/2014 02:37 PM, Nathaniel McCallum wrote: >>>>>>>> On Thu, 2014-06-12 at 13:29 +0200, Tomas Babej wrote: >>>>>>>>> On 06/12/2014 10:45 AM, Martin Kosek wrote: >>>>>>>>>> On 06/11/2014 06:49 PM, Nathaniel McCallum wrote: >>>>>>>>>>> On Wed, 2014-06-11 at 11:08 +0200, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> As due to possible race conditions, the preop.pin might not be >>>>>>>>>>>> written in the CS.cfg at the time installer tries to read it. >>>>>>>>>>>> >>>>>>>>>>>> In case no value for preop.pin was found, retry until timeout >>>>>>>>>>>> was reached. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3382 >>>>>>>>>>>> >>>>>>>>>>>> (applies on ipa-3-0 branch) >>>>>>>>>>> There is inconsistent spacing around '='. For instance: >>>>>>>>>>> + f=open(filename, 'r') >>>>>>>>>>> + data = f.read() >>>>>>>>>>> >>>>>>>>>>> Also, I'm fairly certain this is incorrect: >>>>>>>>>>> + total_timeout =+ 1 >>>>>>>>>>> >>>>>>>>>>> Nathaniel >>>>>>>>>> +1, this is certainly is not a deterministic, constant measuring of a timeout. >>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>>> I would rather see something like >>>>>>>>>> >>>>>>>>>> op_timeout = time.time() + api.env.startup_timeout >>>>>>>>>> >>>>>>>>>> while preop_pin is None and time.time() < op_timeout: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, I do not think this will work, IOError is risen when a file is not found, >>>>>>>>>> so this code would not solve the problem if waiting on file to appear. >>>>>>>>> Yes, but the problem was not in being unable to open the file, but that >>>>>>>>> certain file content >>>>>>>>> is not in the file yet. It seems that pkicreate creates the file in >>>>>>>>> time, but the content written >>>>>>>>> later and that causes the race condition. >>>>>>>>> >>>>>>>>> If you inspect the original code, and bugzilla, you can see that >>>>>>>>> installation fails with: >>>>>>>>> >>>>>>>>> 2013-01-25T02:58:44Z INFO The ipa-server-install command failed, exception: >>>>>>>>> RuntimeError: Unable to find preop.pin in /var/lib/pki-ca/conf/CS.cfg. Is your CA already configured? >>>>>>>>> >>>>>>>>> While the original code >>>>>>>>> >>>>>>>>> # read the config file and get the preop pin >>>>>>>>> >>>>>>>>> try: >>>>>>>>> >>>>>>>>> >>>>>>>>> f=open(filename) >>>>>>>>> >>>>>>>>> except IOError, >>>>>>>>> e: >>>>>>>>> >>>>>>>>> root_logger.error("Cannot open configuration file." + >>>>>>>>> str(e)) >>>>>>>>> raise >>>>>>>>> e >>>>>>>>> >>>>>>>>> data = >>>>>>>>> f.read() >>>>>>>>> >>>>>>>>> data = >>>>>>>>> data.split('\n') >>>>>>>>> >>>>>>>>> pattern = re.compile("preop.pin=(.*)" >>>>>>>>> ) >>>>>>>>> for line in >>>>>>>>> data: >>>>>>>>> >>>>>>>>> match = re.search(pattern, >>>>>>>>> line) >>>>>>>>> if >>>>>>>>> (match): >>>>>>>>> >>>>>>>>> >>>>>>>>> preop_pin=match.group(1) >>>>>>>>> >>>>>>>>> break >>>>>>>>> if preop_pin is None: >>>>>>>>> raise RuntimeError("Unable to find preop.pin in %s. Is your CA >>>>>>>>> already configured?" % filename) >>>>>>>>> >>>>>>>>> does raise the IOError in case the file was not able to be opened. Since >>>>>>>>> we get the Runtime error, >>>>>>>>> file must exist, only the desired content is missing. >>>>>>>>> >>>>>>>>> That said, I have no objections to amending the patch so that it >>>>>>>>> properly handles this race condition >>>>>>>>> we did not encounter. Better safe than sorry, it's a simple change and >>>>>>>>> already included in the >>>>>>>>> current iteration of the patch. >>>>>>>>> >>>>>>>>> Updated patch attached. >>>>>>>> I think I would prefer something like inotify watching for >>>>>>>> IN_CLOSE_WRITE rather than this polling. >>>>>>>> >>>>>>>> Nathaniel >>>>>>>> >>>>>>> Wouldn't that be a little bit of an overkill for that purpose? >>>>>> If would. Nathaniel, this is a fix for ipa-3-0 branch only, we do not have this >>>>>> problem in current master as this issue only affects Dogtag 9 installation. >>>>>> >>>>>> The target is to have small, contained and the non-intrusive patch. Thus the >>>>>> proposed solution to just implement a little wait loop. >>>>>> >>>>>>> - we'll need to introduce an additional dependency for python-inotify >>>>>>> - watching for IN_CLOSE_WRITE is not equivalent with the preop_pin >>>>>>> written to CS.cfg (and we don't know that unless we inspect the code for >>>>>>> pkicreate, which in turn would make our code dependant on code not >>>>>>> located in our codebase), so we will still need to check if preop_pin is >>>>>>> there, and loop over if not >>>>> Sorry, I forgot this was for 3.0 branch. >>>>> >>>>> Nitpick: '=' spacing is still not fixed. >>>> I fixed the spacing. >>>> >>>>> Also, is it your intention to keep looping through the loop with no >>>>> delay on IOError? If there is a race condition where this file isn't >>>>> created yet, you could very likely get log spam. >>>> Read the patch more carefully please. There is delay on IOError >>>> (preop_pin is still >>>> None, since we jumped out of the try block when the exception occured at the >>>> opening of the file and therefore had no chance to set it to something >>>> else than None). >>> Ah, good point. >>> >>> One more issue. In the case of an exception during f.read(), the file >>> descriptor is leaked (in a loop). Why not do something like (is 3.x's >>> python new enough for with?): >>> >>> with open(filename, 'r') as f: >>> data = f.read() >>> ... >>> >>> In any case, the file can be closed immediately after the read(). >>> >>> Nathaniel >>> >> It is (available from python 2.6). >> >> I did not mean to refactor the old code, but you raise a point so I did >> convert the block to somewhat more pythonic code. > > Yup, understood. The leak pre-existed your modifications. But putting > the leak into a loop makes it worth fixing. > > Looks good to me now! ACK > Thanks for review! Pushed to ipa-3-0: 1ec270e5d2fee90605578d04047d675a51318245 Martin From mbasti at redhat.com Fri Jun 13 07:55:45 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Jun 2014 09:55:45 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0063 Update DNSSEC attributes/record types In-Reply-To: <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> Message-ID: <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> On Thu, 2014-06-12 at 16:20 +0200, Martin Basti wrote: > On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: > > On 9.6.2014 17:28, Martin Basti wrote: > > > Ticket: https://fedorahosted.org/freeipa/ticket/4328 > > > > > > Petr please make the WebUI patch review (0062) :-) > > > > > > Patches attached. > > > > > > > Patch #0059: LGTM > > > > Patch #0060: > > > > 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise > > you get general "Text does not match field pattern" error message in Web UI. > > > I will add the message. > > > 2. Could be in one if: > > + if nsec3params is not None: > > + if len(nsec3params) > 1: > > > > Maybe I'm missing something. But why does the dns plugin code use > > following all over the place: > > > > try: > > nsec3params = rrattrs['nsec3paramrecord'] > > except KeyError: > > pass > > else: > > if nsec3params is not None: > > > > instead of: > > > > nsec3params = rrattrs.get('nsec3paramrecord') > > if nsec3params is not None: > > > > btw you use both patterns in the patch. > I will use shorten form, I wrote it in the same way as the other code in > the block was written, that's why. > > > > > Patch #0061: ACK > > > > > > Patch #0062: > > > > 3. Why are there the idnafsdbrec1 variables? > > > It was replace for NSEC records, which are not supported anymore. > Now I realize, there is wrong description, so the idnafsbrec1 variable > is not needed. > I will remove it. > > > 4. related to ^^: > > ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing > > whitespace after ',' > > > > > > Patch #0063: LGTM > > IDK if they work because I'm experiencing some weird issues with > > xmlrpc_tests in general. > I had troubles only with permission tests, but all DNS test worked fine for me. > > Thank you for review. > Updated patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0059-2-DNSSEC-remove-unsuported-records.patch Type: text/x-patch Size: 22390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0060-2-DNSSEC-added-NSEC3PARAM-record-type.patch Type: text/x-patch Size: 31803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0061-2-DNSSEC-webui-update-DNSSEC-attributes.patch Type: text/x-patch Size: 6106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0062-2-Tests-remove-unused-records-from-tests.patch Type: text/x-patch Size: 4534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0063-2-Tests-tests-for-NSEC3PARAM-records.patch Type: text/x-patch Size: 3186 bytes Desc: not available URL: From mbasti at redhat.com Fri Jun 13 08:28:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 13 Jun 2014 10:28:19 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones Message-ID: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> Patches attached, require patches mbasti 0052-0055. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0066-Added-upgrade-step-executed-before-schmema-is-upgrad.patch Type: text/x-patch Size: 6638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0067-Upgrade-special-master-zones-to-forward-zones.patch Type: text/x-patch Size: 8718 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 13 08:38:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 10:38:01 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments In-Reply-To: <539598BE.5030607@redhat.com> References: <53958ADF.3050306@redhat.com> <539598BE.5030607@redhat.com> Message-ID: <539AB869.7090407@redhat.com> On 06/09/2014 01:21 PM, Petr Viktorin wrote: > On 06/09/2014 12:22 PM, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll >> make a slightly less invasive patch for 3.x. >> >> Basically, the version argument is now expected for all commands >> (including e.g. ping & env), and also when calling the commands in_server. >> If it's not given, a message is returned, so this should should only >> really affect tests that check the output strictly. >> > > For the 3.x maintenance branches, here's a much smaller fix. This only checks > the version if it was given. Worked fine - tested on RHEL-6.5. Pushed to: ipa-3-0: 220539a3653b15e4f5679b53cab8e601abaf8990 ipa-3-1: 98f5abe37461844b42989766caee525c0d8864f8 ipa-3-2: b4d2637fc43798669b8ea1bc6fe0f851fd30401a ipa-3-3: 7486140e00c2f1e119250fb69040864fa902290d Martin From mkosek at redhat.com Fri Jun 13 08:41:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 10:41:41 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments In-Reply-To: <53958ADF.3050306@redhat.com> References: <53958ADF.3050306@redhat.com> Message-ID: <539AB945.1000504@redhat.com> On 06/09/2014 12:22 PM, Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll make a > slightly less invasive patch for 3.x. > > Basically, the version argument is now expected for all commands (including > e.g. ping & env), and also when calling the commands in_server. > If it's not given, a message is returned, so this should should only really > affect tests that check the output strictly. Functionally works fine, tested with curl. I see one issue in the test that may be related: ====================================================================== FAIL: Test the `ipalib.config.Env._finalize_core` method. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/ipatests/test_ipalib/test_config.py", line 572, in test_finalize_core assert o[key] == value, '%r is %r; should be %r' % (key, o[key], value) AssertionError: 'api_version' is 2.88; should be u'2.88' Martin From pviktori at redhat.com Fri Jun 13 12:12:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Jun 2014 14:12:41 +0200 Subject: [Freeipa-devel] [PATCHES] 0581-0582 ipalib.config: Only convert numeric values to float Message-ID: <539AEAB9.3050507@redhat.com> First patch: minor fix in env loading Second patch: When api.env is loaded, strings that "look like" floats get auto-converted to floats. This is wrong, as the conversion can lose precision, which matters for the new api_version. Here's a patch that disables this conversion, and fixes places that the disabling might break. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0581-ipalib.config-Only-convert-basedn-to-DN.patch Type: text/x-patch Size: 958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0582-ipalib.config-Don-t-autoconvert-values-to-float.patch Type: text/x-patch Size: 4024 bytes Desc: not available URL: From pviktori at redhat.com Fri Jun 13 12:14:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Jun 2014 14:14:19 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments In-Reply-To: <539AB945.1000504@redhat.com> References: <53958ADF.3050306@redhat.com> <539AB945.1000504@redhat.com> Message-ID: <539AEB1B.1090009@redhat.com> On 06/13/2014 10:41 AM, Martin Kosek wrote: > On 06/09/2014 12:22 PM, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll make a >> slightly less invasive patch for 3.x. >> >> Basically, the version argument is now expected for all commands (including >> e.g. ping & env), and also when calling the commands in_server. >> If it's not given, a message is returned, so this should should only really >> affect tests that check the output strictly. > > > Functionally works fine, tested with curl. I see one issue in the test that may > be related: > > ====================================================================== > FAIL: Test the `ipalib.config.Env._finalize_core` method. > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest > self.test(*self.arg) > File "/root/freeipa-master/ipatests/test_ipalib/test_config.py", line 572, in > test_finalize_core > assert o[key] == value, '%r is %r; should be %r' % (key, o[key], value) > AssertionError: 'api_version' is 2.88; should be u'2.88' That's a different issue; the test's been broken since 2a8c509. I've been meaning to get to it for a while. Addressed in my patch 0582. -- Petr? From mkosek at redhat.com Fri Jun 13 12:15:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 14:15:51 +0200 Subject: [Freeipa-devel] [PATCH] 0571 ipalib.frontend: Do API version check before converting arguments In-Reply-To: <539AEB1B.1090009@redhat.com> References: <53958ADF.3050306@redhat.com> <539AB945.1000504@redhat.com> <539AEB1B.1090009@redhat.com> Message-ID: <539AEB77.5090902@redhat.com> On 06/13/2014 02:14 PM, Petr Viktorin wrote: > On 06/13/2014 10:41 AM, Martin Kosek wrote: >> On 06/09/2014 12:22 PM, Petr Viktorin wrote: >>> Hello, >>> This fixes https://fedorahosted.org/freeipa/ticket/3963 for master. I'll make a >>> slightly less invasive patch for 3.x. >>> >>> Basically, the version argument is now expected for all commands (including >>> e.g. ping & env), and also when calling the commands in_server. >>> If it's not given, a message is returned, so this should should only really >>> affect tests that check the output strictly. >> >> >> Functionally works fine, tested with curl. I see one issue in the test that may >> be related: >> >> ====================================================================== >> FAIL: Test the `ipalib.config.Env._finalize_core` method. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest >> self.test(*self.arg) >> File "/root/freeipa-master/ipatests/test_ipalib/test_config.py", line 572, in >> test_finalize_core >> assert o[key] == value, '%r is %r; should be %r' % (key, o[key], value) >> AssertionError: 'api_version' is 2.88; should be u'2.88' > > That's a different issue; the test's been broken since 2a8c509. I've been > meaning to get to it for a while. > Addressed in my patch 0582. Ok. In that case it is an ACK. Pushed to master: ba53299b98977308966039fad9518c79296bccbf Martin From simo at redhat.com Fri Jun 13 12:55:50 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jun 2014 08:55:50 -0400 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <539AA2CE.4080602@redhat.com> References: <5399E749.6070806@redhat.com> <539AA2CE.4080602@redhat.com> Message-ID: <1402664150.22737.64.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 09:05 +0200, Martin Kosek wrote: > On 06/12/2014 07:45 PM, Jan Cholasta wrote: > ... > > Note that automatic distribution of CA certificates to IPA systems is not > > implemented yet (it's planned for IPA 4.2, see > > ), so /etc/ipa/ca.crt, > > /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated *only* > > during client/server install. > > > > Honza > > For 4.0, we will need to come up with manual procedure how to renew the > certificates *without* reinstalling the client or server. > > I think the best way would be to prepare a simple script to renew > client/server, something like > > /usr/share/ipa/ipa-renew-client-certificate > /usr/share/ipa/ipa-renew-server-certificate I assume you mean /usr/bin or /usr/libexec/ipa ? > and refer to it in the ipa-cacert-manage man page. People could then pretty > easily run those after a cert change, using whatever means their infrastructure > uses - puppet, ssh, ... -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Jun 13 13:06:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Jun 2014 15:06:59 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <1402664150.22737.64.camel@willson.usersys.redhat.com> References: <5399E749.6070806@redhat.com> <539AA2CE.4080602@redhat.com> <1402664150.22737.64.camel@willson.usersys.redhat.com> Message-ID: <539AF773.4030200@redhat.com> On 06/13/2014 02:55 PM, Simo Sorce wrote: > On Fri, 2014-06-13 at 09:05 +0200, Martin Kosek wrote: >> On 06/12/2014 07:45 PM, Jan Cholasta wrote: >> ... >>> Note that automatic distribution of CA certificates to IPA systems is not >>> implemented yet (it's planned for IPA 4.2, see >>> ), so /etc/ipa/ca.crt, >>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated *only* >>> during client/server install. >>> >>> Honza >> >> For 4.0, we will need to come up with manual procedure how to renew the >> certificates *without* reinstalling the client or server. >> >> I think the best way would be to prepare a simple script to renew >> client/server, something like >> >> /usr/share/ipa/ipa-renew-client-certificate >> /usr/share/ipa/ipa-renew-server-certificate > > I assume you mean /usr/bin or /usr/libexec/ipa ? Right, that's better. I think we do not want to store it in /usr/bin as fully supported scripts as I would feel obliged to keep that scripts supported and around even when automatic renewal is available in FreeIPA 4.2. So maybe /usr/libexec/ipa would be better. > >> and refer to it in the ipa-cacert-manage man page. People could then pretty >> easily run those after a cert change, using whatever means their infrastructure >> uses - puppet, ssh, ... From rcritten at redhat.com Fri Jun 13 13:11:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jun 2014 09:11:21 -0400 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <539AF773.4030200@redhat.com> References: <5399E749.6070806@redhat.com> <539AA2CE.4080602@redhat.com> <1402664150.22737.64.camel@willson.usersys.redhat.com> <539AF773.4030200@redhat.com> Message-ID: <539AF879.3070203@redhat.com> Martin Kosek wrote: > On 06/13/2014 02:55 PM, Simo Sorce wrote: >> On Fri, 2014-06-13 at 09:05 +0200, Martin Kosek wrote: >>> On 06/12/2014 07:45 PM, Jan Cholasta wrote: >>> ... >>>> Note that automatic distribution of CA certificates to IPA systems is not >>>> implemented yet (it's planned for IPA 4.2, see >>>> ), so /etc/ipa/ca.crt, >>>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated *only* >>>> during client/server install. >>>> >>>> Honza >>> >>> For 4.0, we will need to come up with manual procedure how to renew the >>> certificates *without* reinstalling the client or server. >>> >>> I think the best way would be to prepare a simple script to renew >>> client/server, something like >>> >>> /usr/share/ipa/ipa-renew-client-certificate >>> /usr/share/ipa/ipa-renew-server-certificate >> >> I assume you mean /usr/bin or /usr/libexec/ipa ? > > Right, that's better. I think we do not want to store it in /usr/bin as fully > supported scripts as I would feel obliged to keep that scripts supported and > around even when automatic renewal is available in FreeIPA 4.2. > > So maybe /usr/libexec/ipa would be better. I guess it depends on what our expectations of user's running this are. If it is basically sample code, then yeah, /usr/share may be ok. If it's something supported we expect some people to run, /usr/[s]bin is probably the place. /usr/libexec is for binaries run by other programs IIRC. rob From pviktori at redhat.com Fri Jun 13 15:25:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Jun 2014 17:25:10 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed Message-ID: <539B17D6.6040908@redhat.com> With the first patch, old SYSTEM permissions can be replaced. The "Read DNS Entries" did not have an associated ACI, but was rather rolled into a single ACI with the managedBy rule used for per-zone access. (and before that it was part of a deny rule.) We can't remove this permission in an update file, because we need to check that it is indeed an old SYSTEM perm and not a new one with the same name. The second patch converts DNS permissions to managed. The ACIs are put directly in $SUFFIX, because the cn=dns subtree does not exist in all installations. I hope to change this for https://fedorahosted.org/freeipa/ticket/4058, when I've thought more about relationships between plugins, packages, install options, and the updater. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0583-managed-permission-updater-Add-mechanism-to-replace-.patch Type: text/x-patch Size: 2880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0584-Convert-DNS-default-permissions-to-managed.patch Type: text/x-patch Size: 30237 bytes Desc: not available URL: From pviktori at redhat.com Fri Jun 13 16:03:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Jun 2014 18:03:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0585-0587 Convert Password Policy & COSTemplate default permissions to managed Message-ID: <539B20E2.8060805@redhat.com> The first patch is preparation. As for the second two, this is how the bulk of the transition will look. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0585-Add-REALM-to-variables-supported-by-the-managed-perm.patch Type: text/x-patch Size: 1223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0586-Convert-COSTemplate-default-permissions-to-managed.patch Type: text/x-patch Size: 8658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0587-Convert-Password-Policy-default-permissions-to-manag.patch Type: text/x-patch Size: 8160 bytes Desc: not available URL: From pspacek at redhat.com Fri Jun 13 16:43:40 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Jun 2014 18:43:40 +0200 Subject: [Freeipa-devel] DNSSEC key metadata handling In-Reply-To: <5399CC20.9090907@redhat.com> References: <5399C270.1060608@redhat.com> <1402586393.22737.42.camel@willson.usersys.redhat.com> <5399CC20.9090907@redhat.com> Message-ID: <539B2A3C.80908@redhat.com> On 12.6.2014 17:49, Petr Spacek wrote: > On 12.6.2014 17:19, Simo Sorce wrote: >> On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: >>> Hello list, >>> >>> I have realized that we need to store certain DNSSEC metadata for every >>> (zone,key,replica) triplet. It is necessary to handle splits in replication >>> topology. >>> >>> DNSSEC key can be in one of following states: >>> - key created >>> - published but not used for signing >>> - published and used for signing >>> - published and not used for signing but old signatures exist >>> - unpublished >>> >>> Every state transition has to be postponed until relevant TTL expires, and of >>> course, we need to consider TTL on all replicas. >>> >>> >>> Example of a problem >>> ==================== >>> DNS TTL=10 units >>> Key life time=100 units >>> >>> Replica=1 Key=1 Time=0 Published >>> Replica=2 Key=1 Time=0 Published >>> Replica=1 Key=1 Time=10 Published, signing >>> Replica=2 Key=1 Time=10 Published, signing >>> Replica=1 Key=2 Time=90 Generated, published, not signing yet >>> Replica=2 Key=2 Time=90 >>> Replica=1 Key=1 Time=100 >>> ^^^ From time=100, all new signatures should be created with key=2 but that >>> can break DNSSEC validation because key=2 is not available on replica=2. >> >> Can you explain how this break validation ? >> Aren't signatures regenerated on each replica ? > They are. > >> And so isn't each replica self-consistent ? > Ah, sorry, I didn't mention one important detail. Keys published in the zone > 'example.com.' have to match keys published in parent zone. There has to be a > mechanism for synchronizing this. > > Validation will break if (keys published by parent) are not subset of (keys on > replicas). > > Next logical step in the example above is to remove key1 from replica 1 so you > will end replica1 having key2 and replica2 having only key1. > > How can we guarantee that synchronization mechanism will not wipe key1 from > parent? Or the other way around? How can we guarantee that key2 was uploaded? > > Also, things will break is number of keys in parent exceeds reasonable number > (because DNS replies will be to big etc.). > >>> Proposal 1 >>> ========== >>> - Store state and timestamps for (zone,key,replica) triplet >>> - Do state transition only if all triplets (zone,key,?) indicate that all >>> replicas reached desired state so the transition is safe. >>> - This implicitly means that no transition will happen if one or more replicas >>> is down. This is necessary otherwise DNSSEC validation can break mysteriously >>> when keys got out of sync. >>> >>> dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, >>> cn=dns, dc=example >>> idnssecKeyCreated: >>> idnssecKeyPublished: >>> idnssecKeyActivated: >>> idnssecKeyInactivated: >>> idnssecKeyDeleted: >> >> Why do you care for all 5 states ? > In short, to follow RFC 6781 and all it's requirements. Simo and I have discussed this off-line. The final decision is to rely on replication. The assumption is that if replication is broken, everything will break soon anyway, so the original proposal is overkill. We have to store one set of timestamps somewhere to be able to follow RFC 6781, so we decided to store it in the key-metadata object. I added other attributes to object class definition so it contains all necessary metadata. The new object class idnsSecKey is now complete. Please note that DN in the previous example was incorrect. It is necessary to store the metadata separately for pairs (zone, key) to cover the case where key is shared between zones. This also nicely splits metadata from actual key material. All attributes are single-valued. MUST attributes are: idnsSecKeyRef idnsSecKeyCreated idnsSecAlgorithm dn: cn=, cn=keys, idnsname=example.com, cn=dns, dc=example objectClass: idnsSecKey idnsSecKeyRef: idnsSecKeyCreated: idnsSecKeyPublish: idnsSecKeyActivate: idnsSecKeyInactive: idnsSecKeyDelete: idnsSecKeyZone: equivalent to bit 7 (ZONE) in [1] idnsSecKeyRevoke: equivalent to bit 8 (REVOKE) in [1] idnsSecKeySep: equivalent to bit 15 (SEP) in [1] idnsSecAlgorithm: used as mnemonic in [2] [1] http://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1 [2] http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 >> It looks to me the only relevant states are Activated and (perhaps) >> Deactivated. >> >> But then again if replication is broken *many* other things are, so >> should we *really* care to handle broken replication by adding all this >> information ? > We need to keep track of timestamps anyway (to follow RFC 6781) so we need > some other way how to *make sure* that timestamps never go backwards, even if > replication was broken and later restarted. > > What do you propose? > >>> Effectively, state machine will be controlled by max(attribute) over all >>> replicas (for given key). >>> >>> Replication traffic estimation >>> ------------------------------ >>> Number of writes to LDAP = (State transitions per key) * (Keys per zone) * >>> (Number of zones) * (Number of replicas) >>> >>> The obvious problem is that amount of traffic grows linearly with all >>> variables. >>> >>> State transitions per key: 5 >>> Keys per zone: 10 >>> Zones: 100 >>> Replicas: 30 >>> Key life time: 1 month >>> >>> 5*10*100*30 / 1 month >>> i.e. >>> 150 000 writes / 1 month >>> i.e. >>> ~ 1 write / 17 seconds >>> >>> It seems like that this generates a lot of replication traffic. (Please note >>> that number of replicas/zones/keys per zone is also quite high but it will be >>> hard to improve scalability later if we decide to use LDAP in this way.) >> >> Right, and for an edge case that is already a broken state. I would >> rather spend time on a monitoring process that warns the amdin >> replication is broken rather than adding all this unnecessary traffic. >> >>> And ... our favorite question :-) >>> What should I use for cn= ? I would propose use either FQDN >>> of replica or value returned by LDAP whoami. >> >> Add to this dealing with dead/removed replicas ? I question the sanity >> of this approach :) >> >>> Proposal 2 >>> ========== >>> Another possibility is to make timestamp attributes non-replicated and >>> (somehow) use DNS queries to determine if the desired key is available on all >>> other replicas before any state transition is allowed. >>> >>> That would require: >>> - Full-mesh replica-to-replica connectivity >>> - Similar amount of DNS query/response round trips (multiply ) >>> - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS >>> answers and break key rotation mechanism during bootstrap (when no keys are >>> available) and maybe even later. >>> >>> It is easy to detect that key is: >>> - published >>> - unpublished >>> - used for signing >>> >>> The problem is that there is no reliable way to detect that is a key was >>> created/is available on replica but is not published yet and similarly that >>> the key is published but not used for signing anymore (it would require to >>> check all names published in the zone). >>> >>> I will think about it a bit more but I would like to know if full-mesh >>> replica-to-replica connectivity is acceptable requirement or not. >> >> Not really, and again I question the need to do this. We will do some limited set DNS queries to do sanity checking, mainly when new KSK is to-be published. In that case we need to wait until parent zone picks it up. Petr^2 Spacek From rcritten at redhat.com Fri Jun 13 16:54:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jun 2014 12:54:52 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402525640.22737.3.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> Message-ID: <539B2CDC.4040306@redhat.com> Simo Sorce wrote: > On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: >> 0001 >> >> When is_allowed_to_access_attr() fails it should include the value of >> access in the error log for debugging. > > Ok added more detailed logging > >> Nit: Coluld not fetch REALM backend > > Fixed > >> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm >> fine keeping a common err_msg but the fatal error should be unique. > > Yeah thanks to this comment, I had a small change of heart. > Instead of sending such detailed information to clients I reverted to > send a little less information to the clients and instead LOG_FATAL in a > more detailed way. HTH > >> This breaks normal host delegation. If you add a host to another host's >> managedby, getting the keytab will fail. This is due to: >> >> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny >> write on >> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) >> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: >> no aci matched the subject by aci(97): aciname= "Groups allowed to >> create keytab keys", acidn="cn=accounts,dc=example,dc=com" > > Ok this should be working now, I added a new ACI to allow also > managedby#USERDN to operate on keytabs. > > New patches attached. Functionally these seem to work ok. I think there should be some documented way to enable the -r in ipa-getkeytab. Right now I'm not even entirely sure how one would add a permission to do so. rob From simo at redhat.com Fri Jun 13 18:04:15 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jun 2014 14:04:15 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <539B2CDC.4040306@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> Message-ID: <1402682655.22737.79.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 12:54 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: > >> 0001 > >> > >> When is_allowed_to_access_attr() fails it should include the value of > >> access in the error log for debugging. > > > > Ok added more detailed logging > > > >> Nit: Coluld not fetch REALM backend > > > > Fixed > > > >> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm > >> fine keeping a common err_msg but the fatal error should be unique. > > > > Yeah thanks to this comment, I had a small change of heart. > > Instead of sending such detailed information to clients I reverted to > > send a little less information to the clients and instead LOG_FATAL in a > > more detailed way. HTH > > > >> This breaks normal host delegation. If you add a host to another host's > >> managedby, getting the keytab will fail. This is due to: > >> > >> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny > >> write on > >> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) > >> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: > >> no aci matched the subject by aci(97): aciname= "Groups allowed to > >> create keytab keys", acidn="cn=accounts,dc=example,dc=com" > > > > Ok this should be working now, I added a new ACI to allow also > > managedby#USERDN to operate on keytabs. > > > > New patches attached. > > Functionally these seem to work ok. I think there should be some > documented way to enable the -r in ipa-getkeytab. Right now I'm not even > entirely sure how one would add a permission to do so. > > rob > ATM the only way is to add the ipaAllowedOperations objectclass to the object you want to allow retrieving a keyt from and the ipaAllowedToPerform;reasd_key attribute Example: dn: test/foo.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com changetype: modify add: objectclass objectclass: ipaAllowedOperations - add: ipaAllowedToPerform;read_key ipaAllowedToPerform;reasd_key: uid=cluster-admin,cn=users,cn=accounts,dc=example,dc=com Once you do this the user called cluster-admin will be allowed to retrieve the keytab w/o changing it. Of course you can list there a group or another host/service DN. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jun 13 18:10:25 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jun 2014 14:10:25 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402682655.22737.79.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <1402682655.22737.79.camel@willson.usersys.redhat.com> Message-ID: <1402683025.22737.81.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 14:04 -0400, Simo Sorce wrote: > On Fri, 2014-06-13 at 12:54 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: > > >> 0001 > > >> > > >> When is_allowed_to_access_attr() fails it should include the value of > > >> access in the error log for debugging. > > > > > > Ok added more detailed logging > > > > > >> Nit: Coluld not fetch REALM backend > > > > > > Fixed > > > > > >> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm > > >> fine keeping a common err_msg but the fatal error should be unique. > > > > > > Yeah thanks to this comment, I had a small change of heart. > > > Instead of sending such detailed information to clients I reverted to > > > send a little less information to the clients and instead LOG_FATAL in a > > > more detailed way. HTH > > > > > >> This breaks normal host delegation. If you add a host to another host's > > >> managedby, getting the keytab will fail. This is due to: > > >> > > >> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny > > >> write on > > >> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) > > >> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: > > >> no aci matched the subject by aci(97): aciname= "Groups allowed to > > >> create keytab keys", acidn="cn=accounts,dc=example,dc=com" > > > > > > Ok this should be working now, I added a new ACI to allow also > > > managedby#USERDN to operate on keytabs. > > > > > > New patches attached. > > > > Functionally these seem to work ok. I think there should be some > > documented way to enable the -r in ipa-getkeytab. Right now I'm not even > > entirely sure how one would add a permission to do so. > > > > rob > > > > ATM the only way is to add the ipaAllowedOperations objectclass to the > object you want to allow retrieving a keyt from and the > ipaAllowedToPerform;reasd_key attribute > > Example: > dn: test/foo.example.com at EXAMPLE.COM,cn=services,cn=accounts,dc=example,dc=com > changetype: modify > add: objectclass > objectclass: ipaAllowedOperations > - > add: ipaAllowedToPerform;read_key > ipaAllowedToPerform;reasd_key: uid=cluster-admin,cn=users,cn=accounts,dc=example,dc=com > > Once you do this the user called cluster-admin will be allowed to > retrieve the keytab w/o changing it. > > Of course you can list there a group or another host/service DN. Doh, I realized we haven't created a feature page for this, I am going to create one now, so that the UI work we'll need in future can look it up and information like the above is registered. Will be available here: http://www.freeipa.org/page/V4/Keytab_Retrieval Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jun 13 18:29:46 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jun 2014 14:29:46 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <539B2CDC.4040306@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> Message-ID: <539B431A.10902@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: >>> 0001 >>> >>> When is_allowed_to_access_attr() fails it should include the value of >>> access in the error log for debugging. >> >> Ok added more detailed logging >> >>> Nit: Coluld not fetch REALM backend >> >> Fixed >> >>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm >>> fine keeping a common err_msg but the fatal error should be unique. >> >> Yeah thanks to this comment, I had a small change of heart. >> Instead of sending such detailed information to clients I reverted to >> send a little less information to the clients and instead LOG_FATAL in a >> more detailed way. HTH >> >>> This breaks normal host delegation. If you add a host to another host's >>> managedby, getting the keytab will fail. This is due to: >>> >>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny >>> write on >>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) >>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: >>> no aci matched the subject by aci(97): aciname= "Groups allowed to >>> create keytab keys", acidn="cn=accounts,dc=example,dc=com" >> >> Ok this should be working now, I added a new ACI to allow also >> managedby#USERDN to operate on keytabs. >> >> New patches attached. > > Functionally these seem to work ok. I think there should be some > documented way to enable the -r in ipa-getkeytab. Right now I'm not even > entirely sure how one would add a permission to do so. NACK Simo noticed that the ACIs are in cn=accounts. On the one hand this is a reasonable place to put these, on the other it is a bit broad. I think we'll need type-specific ACIs in a number of subtrees: users, computers and services. rob From npmccallum at redhat.com Fri Jun 13 19:39:20 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Jun 2014 15:39:20 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402522909.2955.26.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> Message-ID: <1402688360.4273.6.camel@ipa.example.com> I am CC'ing Simo because he wants to review my PBKDF2 implementation. On Wed, 2014-06-11 at 17:41 -0400, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 14:24 +0200, Jan Cholasta wrote: > > Hi, > > > > On 13.5.2014 18:40, Nathaniel McCallum wrote: > > > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > > >> This patch adds support for importing tokens using RFC 6030 key > > >> container files. This includes decryption support. For sysadmin sanity, > > >> any tokens which fail to add will be written to the output file for > > >> examination. The main use case here is where a small subset of a large > > >> set of tokens fails to validate or add. Using the output file, the > > >> sysadmin can attempt to recover these specific tokens. > > >> > > >> This code is implemented as a server-side script. However, it doesn't > > >> actually need to run on the server. This was done because importing is > > >> an odd fit for the IPA command framework: > > >> 1. We need to write an output file. > > >> 2. The operation may be long-running (thousands of tokens). > > >> 3. Only admins need to perform this task and it only happens > > >> infrequently. > > > > > > I forgot to put the link to the ticket in the commit message. Fixed. > > > > 1) I think you should initialize NSS in ipa_otptoken_import.py, not in > > the ipa-otptoken-import script. > > Fixed. > > > 2) The pep8 tool reports a lot of errors in ipa_otptoken_import.py. > > Fixed (mostly). The remaining output from pep8 is, I think, entirely > justifiable. > > > 3) Other error messages are in the form "message: %s", I think this one > > should use that form as well: > > > > + if encoding != 'DECIMAL': > > + raise ValidationError('Unsupported encoding (%s)!' % encoding) > > Fixed. > > > 4) This is not right: > > > > + except: > > + self.log.warn("Error adding token: " + > > str(sys.exc_info()[1])) > > > > I think it should be something like this instead: > > > > except ValidationError, e: > > self.log.warn("Error adding token: %s", e) > > Fixed. > > > 5) There is no man page for ipa-otptoken-import. > > TODO (tomorrow). Fixed. > > 6) Output file is created even when ipa-otptoken-import fails with > > "Unable to connect to LDAP! Did you kinit?" and other initialization > > errors, which makes subsequent ipa-otptoken-import fail with "Output > > file already exists!". > > Fixed. > > > 7) When a key is specified by reference in Key/KeyReference instead of > > directly in Key/Data/Secret like in > > , > > import fails with "Key not found in token!". I would expect a different > > error message. > > This error is now: Referenced keys are not supported! > > > 8) Importing > > > > produces this output: > > > > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: > > FutureWarning: The behavior of this method will change in future > > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > > if data.get('pinpolicy', None): > > Error adding token: 'NoneType' object has no attribute 'strip' > > This now states: > Error adding token: PINPolicy policy not supported! > Error adding token: Unsupported token type! > > > 9) Using an arbitrary file in -k produces this output: > > > > (SEC_ERROR_INVALID_KEY) The key does not support the requested operation. > > Traceback (most recent call last): > > File "/usr/sbin/ipa-otptoken-import", line 29, in > > nss.nss_shutdown() > > nss.error.NSPRError: (SEC_ERROR_BUSY) NSS could not shutdown. Objects > > are still in use. > > What do you mean by "arbitrary file"? A file that is not the key? > Like /dev/null? I'm not able to reproduce this. > > > 10) Importing > > > > and > > > > produces this output: > > > > Error adding token: object of type 'NoneType' has no len() > > Import fails with: > Derived keys are not currently supported! > or > X.509 keys are not currently supported! > > It would be nice to support these in the future. I added support for derived keys. However, pskc-figure7.xml appears to have a problem. This problem is actually in RFC 6030 itself (where pskc-figure7.xml comes from). According to the xenc11 standard, all of these tags should be in the xenc11 namespace (not pkcs5 or undefined as given in RFC 6030): Ej7/PEpyEpw= 1000 16 When fixing this error in pskc-figure7.xml, key derivation works in this latest patch. > > 11) Importing > > > > or > > > > produces this output: > > > > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:304: > > FutureWarning: The behavior of this method will change in future > > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > > if data.get('maxtransact', None): > > /usr/lib/python2.7/site-packages/ipaserver/install/ipa_otptoken_import.py:307: > > FutureWarning: The behavior of this method will change in future > > versions. Use specific 'len(elem)' or 'elem is not None' test instead. > > if data.get('pinpolicy', None): > > Both of these now output: > Error adding token: NumberOfTransactions policy not supported! > > > 12) Importing > > > > succeeds, but it should fail. > > This now errors with: > PSKC file is invalid! > > > 13) Importing > > > > fails, but it should succeed, I think. > > I think this should fail in our case since we can't possibly support > that configuration. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053.2-Implement-OTP-token-importing.patch Type: text/x-patch Size: 26405 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jun 13 19:59:13 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 13 Jun 2014 15:59:13 -0400 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1402504980.2955.16.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <53982B8C.1060206@redhat.com> <1402504980.2955.16.camel@ipa.example.com> Message-ID: <1402689553.4273.8.camel@ipa.example.com> On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote: > > On 05/13/2014 04:33 PM, Jan Cholasta wrote: > > > On 12.5.2014 21:02, Nathaniel McCallum wrote: > > >> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: > > >>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: > > >>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: > > >>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: > > >>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: > > >>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: > > >>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: > > >>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: > > >>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the > > >>>>>>>>>>> introduction of SELFDN support. > > >>>>>>>>>>> > > >>>>>>>>>>> Admins, as before, have full access to all token permissions. > > >>>>>>>>>>> > > >>>>>>>>>>> Normal users have read/search/compare access to all of the > > >>>>>>>>>>> non-secret > > >>>>>>>>>>> data for tokens assigned to them, whether protected or > > >>>>>>>>>>> non-protected. > > >>>>>>>>>>> Users can add or delete non-protected tokens and modify most > > >>>>>>>>>>> of their > > >>>>>>>>>>> metadata. However they cannot create, delete or modify > > >>>>>>>>>>> protected tokens. > > >>>>>>>>>>> Regardless of whether the token is protected or not, users > > >>>>>>>>>>> cannot change > > >>>>>>>>>>> a token's ownership or unique identity. > > >>>>>>>>>>> > > >>>>>>>>>>> In contrast, admins can create protected tokens. This > > >>>>>>>>>>> protects the token > > >>>>>>>>>>> from deletion or modification when assigned to users. > > >>>>>>>>>>> Additionally, when > > >>>>>>>>>>> a user account is deleted, the assigned non-protected tokens > > >>>>>>>>>>> are deleted > > >>>>>>>>>>> but the protected tokens are merely orphaned. This permits > > >>>>>>>>>>> the token to > > >>>>>>>>>>> be reassigned without having to recreate it. This last point is > > >>>>>>>>>>> particularly useful in the case of hardware tokens. > > >>>>>>>>>>> > > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 > > >>>>>>>>>>> > > >>>>>>>>>>> NOTE: This patch depends on my patch 0048. > > >>>>>>>>>> This new version makes ipatokenDisabled visible for token > > >>>>>>>>>> owners. It is > > >>>>>>>>>> also writable if the token is non-protected. This > > >>>>>>>>>> additionally fixes: > > >>>>>>>>>> > > >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 > > >>>>>>>>> This new version changes the way the default value of > > >>>>>>>>> protected is setup > > >>>>>>>>> in accordance with the changes made for the review of my patch > > >>>>>>>>> 0048.2. > > >>>>>>>>> > > >>>>>>>>> Nathaniel > > >>>>>>>> Is using the ipatokenprotected attribute the final design? > > >>>>>>> No. Alternate designs are welcome. The code is easy enough to > > >>>>>>> modify. > > >>>>>>> > > >>>>>>>> I did not dig too deep into this, but I think it might be > > >>>>>>>> better to > > >>>>>>>> instead use the managedby attribute on a token to limit who can > > >>>>>>>> delete > > >>>>>>>> (or administer in other way) the token. On otptoken-add, > > >>>>>>>> managedby would > > >>>>>>>> be set to the "whoami" user DN, unless run with --protected, in > > >>>>>>>> which > > >>>>>>>> case managedby would be left empty. Then, when deleting a user, > > >>>>>>>> the > > >>>>>>>> token would be deleted only if the user manages the token. > > >>>>>>> It seems to me that the mechanics of this are roughly the same as > > >>>>>>> protected, just with a different syntax. The cost of this is more > > >>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses > > >>>>>>> (is > > >>>>>>> this possible?) instead of a simple filter. If there is a clear > > >>>>>>> benefit, > > >>>>>>> we can justify the more obtuse syntax. > > >>>>>> > > >>>>>> We usually try not to create new attributes until it is fully > > >>>>>> justified. > > >>>>>> I would like Simo to chime in on this. > > >>>>> > > >>>>> I would also prefer to reuse existing attributes and mechanism if > > >>>>> possible and if it will not preclude future work. > > >>>>> > > >>>>> In this case, it "sounds" like managed-by has the appropriate > > >>>>> meaning: > > >>>>> "who manages the token ?" -> myself, admin, other, none ? > > >>>>> > > >>>>> Nathaniel can you send 2 lines showing the difference in ACIs between > > >>>>> using managed-by vs a new attribute ? > > >>>> > > >>>> These are the ACIs using the protected mechanism: > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > >>>> ipatokenModel > > >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > > >>>> acl "Users can read basic token info"; allow (read, search, compare) > > >>>> userattr = "ipatokenOwner#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > > >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > > >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > > >>>> "Users can > > >>>> see HOTP details"; allow (read, search, compare) userattr = > > >>>> "ipatokenOwner#USERDN";) > > >>>> > > >>>> aci: (targetfilter = > > >>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = > > >>>> "description || ipatokenDisabled || ipatokenNotBefore || > > >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > > >>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; > > >>>> allow (write) userattr = "ipatokenOwner#USERDN";) > > >>>> > > >>>> aci: (target = > > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > >>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version > > >>>> 3.0; > > >>>> acl "Users can create and delete tokens"; allow (add, delete) > > >>>> userattr = > > >>>> "ipatokenOwner#SELFDN";) > > >>>> > > >>>> This is what they look like using managedBy (I have not tested this): > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > >>>> ipatokenModel > > >>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; > > >>>> acl "Users can read basic token info"; allow (read, search, compare) > > >>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) > > >>>> userattr = "managedBy#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || > > >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; > > >>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow > > >>>> (read, search, compare) userattr = "managedBy#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > > >>>> "Users can > > >>>> see HOTP details"; allow (read, search, compare) userattr = > > >>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = > > >>>> "managedBy#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > >>>> "description || ipatokenDisabled || ipatokenNotBefore || > > >>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || > > >>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token > > >>>> info"; > > >>>> allow (write) userattr = "managedBy#USERDN";) > > >>>> > > >>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > > >>>> "Managers can delete tokens"; allow (delete) userattr = > > >>>> "managedBy#USERDN";) > > >>>> > > >>>> aci: (target = > > >>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter > > >>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create > > >>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > > >>>> and > > >>>> userattr = "managedBy#SELFDN";) > > >>>> > > >>>> In short: > > >>>> 1. Owner and manager get read, search and compare. > > >>>> 2. Manager gets write (to select attributes) and delete. > > >>>> 3. Users can create self-managed tokens for themselves only. > > >>>> > > >>>> The otptoken-add command should gain the following defaults: > > >>>> 1. The owner defaults to the user adding the token. > > >>>> 2. If owner == user adding token, managedBy defaults to owner. > > >>>> 3. Otherwise, managedBy defaults to None. > > >>>> > > >>>> This means that if neither owner nor managedBy are specified, the > > >>>> default is a self-owned, self-managed token. Likewise, if a different > > >>>> owner is specified, no manager is assumed. > > >>>> > > >>>> rcrit expresses worry that ipalib's ACI parser may not handle the > > >>>> above > > >>>> syntax. This will become clear during testing if we want this > > >>>> approach. > > >>>> > > >>>> Does this look sane? > > >>> > > >>> I am not entirely sure your ACI syntax is always right for the second > > >>> set. and perhaps we want to duplicate ACIs in some cases (once for > > >>> owner > > >>> once for manager). > > >>> > > >>> I think the read ACIs do not need to list managedby ? Do we plan to > > >>> have > > >>> a manager that is another regular user but not the owner nor an admin ? > > >>> > > >>> In any case I prefer the sytnax that uses managedby, as it has more > > >>> potential. > > >> > > >> Attached is a new version of the patch which implements the feature > > >> using managedBy instead of ipatokenProtected. One important thing needs > > >> to be said about this patch. I am not exposing managedBy in either the > > >> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I > > >> expose this similar to owner or as a relationship? > > > > > > I would expose it, as a relationship. (Note that ipatokenowner should > > > ideally be represented as a relationship too, but the framework does > > > not support 1-to-many relationships ATM.) > > > > > > > > > Just curious, why are the ACIs divided like this: > > > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > > ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl > > > "Users/managers can read basic token info"; allow (read, search, > > > compare) userattr = "ipatokenOwner#USERDN" or userattr = > > > "managedBy#USERDN";) > > > aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = > > > "ipatokenOTPalgorithm || ipatokenOTPdigits || > > > ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP > > > details"; allow (read, search, compare) userattr = > > > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > > aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = > > > "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl > > > "Users/managers can see HOTP details"; allow (read, search, compare) > > > userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) > > > > > > IMHO you could make them less complex by dividing them like this: > > > > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > > ipatokenModel || ipatokenSerial || ipatokenOwner || > > > ipatokenOTPalgorithm || ipatokenOTPdigits || > > > ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token > > > details"; allow (read, search, compare) userattr = > > > "ipatokenOwner#USERDN";) > > > aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = > > > "objectclass || description || ipatokenUniqueID || ipatokenDisabled || > > > ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || > > > ipatokenModel || ipatokenSerial || ipatokenOwner || > > > ipatokenOTPalgorithm || ipatokenOTPdigits || > > > ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token > > > details"; allow (read, search, compare) userattr = "managedBy#USERDN";) > > do you mean aci: (targetfilter = > > "(|(objectClass=ipaToken)(objectClass=ipatokenTOTP)(objectClass=ipatokenHOTP))") > > or are the attrs like ipatokenOTPdigits also in the ipatoken objectclass ? > > > > > Ludwig, > > objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top > ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) > MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore > $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) > X-ORIGIN 'IPA OTP') > > objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP > ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ > ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP') > > objectClasses: (2.16.840.1.113730.3.8.16.2.5 NAME 'ipatokenHOTP' SUP > ipaToken STRUCTURAL DESC 'HOTP Token Type' MUST (ipatokenOTPkey $ > ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenHOTPcounter) X-ORIGIN > 'IPA OTP') Ludwig / Jan, I'd like to propose that we move ahead and merge this patch since the only outstanding item is the question of performance for the ACIs. Nathaniel From simo at redhat.com Fri Jun 13 20:20:25 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Jun 2014 16:20:25 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <539B431A.10902@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> Message-ID: <1402690825.22737.84.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 14:29 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > Simo Sorce wrote: > >> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: > >>> 0001 > >>> > >>> When is_allowed_to_access_attr() fails it should include the value of > >>> access in the error log for debugging. > >> > >> Ok added more detailed logging > >> > >>> Nit: Coluld not fetch REALM backend > >> > >> Fixed > >> > >>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm > >>> fine keeping a common err_msg but the fatal error should be unique. > >> > >> Yeah thanks to this comment, I had a small change of heart. > >> Instead of sending such detailed information to clients I reverted to > >> send a little less information to the clients and instead LOG_FATAL in a > >> more detailed way. HTH > >> > >>> This breaks normal host delegation. If you add a host to another host's > >>> managedby, getting the keytab will fail. This is due to: > >>> > >>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny > >>> write on > >>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) > >>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: > >>> no aci matched the subject by aci(97): aciname= "Groups allowed to > >>> create keytab keys", acidn="cn=accounts,dc=example,dc=com" > >> > >> Ok this should be working now, I added a new ACI to allow also > >> managedby#USERDN to operate on keytabs. > >> > >> New patches attached. > > > > Functionally these seem to work ok. I think there should be some > > documented way to enable the -r in ipa-getkeytab. Right now I'm not even > > entirely sure how one would add a permission to do so. > > NACK > > Simo noticed that the ACIs are in cn=accounts. On the one hand this is a > reasonable place to put these, on the other it is a bit broad. > > I think we'll need type-specific ACIs in a number of subtrees: users, > computers and services. [Only patch 3 attached, as none of the others changed, and addiotional discussion is needed, see below.] Ok after looking carefully into this problem I see that there are really 2 issues. 1) managedby for users, we do not want someone adding a managedby attribute to inadvertently allow the manager to set a user's password. So I changed that ACI and restricted it only to ipaHost and ipaService objects (tested). I haven't touched any other ACI because in order to use them you need to have intentionally added an ipaAllowedToPerform attribute to the user entry. 2) and I think this is a MUCH bigger issue, the Admin users are unbounded and pass any Access Control Check and this means they can now retrieve any key for users or machines. It is already bad enough that admins can unconditionally set any key, but this at least leaves back a pretty big trail (the original client password/key fails to work), and is a necessary evil (password resets, hosts creation/recovery). But I am not very comfortable with the idea an admin can retrieve any key without actually ending up changing it. Petr do we have any short term plan to address the Admin's super ACI ? Otherwise we can add ipaProtectedOperation in the exclude list for the superACI ("Admins can manage any entry") and add the following ACI in cn=accounts, to restore admin ability to set keys (but not retrieve them): aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn="ldap :///cn=admins,cn=groups,cn=accounts,$SUFFIX";) I tested this combination and it effectively stops admin from retrieving all keys unless explicitly authorize by positive ACIs/ipaAllowedToPerform attributes. Thoughts ? -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 27981 bytes Desc: not available URL: From tbabej at redhat.com Fri Jun 13 21:16:33 2014 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 13 Jun 2014 23:16:33 +0200 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402690825.22737.84.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> Message-ID: <539B6A31.7090503@redhat.com> On 06/13/2014 10:20 PM, Simo Sorce wrote: > On Fri, 2014-06-13 at 14:29 -0400, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: >>>>> 0001 >>>>> >>>>> When is_allowed_to_access_attr() fails it should include the value of >>>>> access in the error log for debugging. >>>> Ok added more detailed logging >>>> >>>>> Nit: Coluld not fetch REALM backend >>>> Fixed >>>> >>>>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm >>>>> fine keeping a common err_msg but the fatal error should be unique. >>>> Yeah thanks to this comment, I had a small change of heart. >>>> Instead of sending such detailed information to clients I reverted to >>>> send a little less information to the clients and instead LOG_FATAL in a >>>> more detailed way. HTH >>>> >>>>> This breaks normal host delegation. If you add a host to another host's >>>>> managedby, getting the keytab will fail. This is due to: >>>>> >>>>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny >>>>> write on >>>>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) >>>>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: >>>>> no aci matched the subject by aci(97): aciname= "Groups allowed to >>>>> create keytab keys", acidn="cn=accounts,dc=example,dc=com" >>>> Ok this should be working now, I added a new ACI to allow also >>>> managedby#USERDN to operate on keytabs. >>>> >>>> New patches attached. >>> Functionally these seem to work ok. I think there should be some >>> documented way to enable the -r in ipa-getkeytab. Right now I'm not even >>> entirely sure how one would add a permission to do so. >> NACK >> >> Simo noticed that the ACIs are in cn=accounts. On the one hand this is a >> reasonable place to put these, on the other it is a bit broad. >> >> I think we'll need type-specific ACIs in a number of subtrees: users, >> computers and services. > [Only patch 3 attached, as none of the others changed, and addiotional > discussion is needed, see below.] > > Ok after looking carefully into this problem I see that there are really > 2 issues. > 1) managedby for users, we do not want someone adding a managedby > attribute to inadvertently allow the manager to set a user's password. > > So I changed that ACI and restricted it only to ipaHost and ipaService > objects (tested). > > I haven't touched any other ACI because in order to use them you need to > have intentionally added an ipaAllowedToPerform attribute to the user > entry. > > 2) and I think this is a MUCH bigger issue, the Admin users are > unbounded and pass any Access Control Check and this means they can now > retrieve any key for users or machines. > It is already bad enough that admins can unconditionally set any key, > but this at least leaves back a pretty big trail (the original client > password/key fails to work), and is a necessary evil (password resets, > hosts creation/recovery). > But I am not very comfortable with the idea an admin can retrieve any > key without actually ending up changing it. Petr do we have any short > term plan to address the Admin's super ACI ? > > Otherwise we can add ipaProtectedOperation in the exclude list for the > superACI ("Admins can manage any entry") and add the following ACI in > cn=accounts, to restore admin ability to set keys (but not retrieve > them): > > aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl > "Admins are allowed to rekey any entity"; allow(write) groupdn="ldap > :///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > I tested this combination and it effectively stops admin from retrieving > all keys unless explicitly authorize by positive > ACIs/ipaAllowedToPerform attributes. > > > Thoughts ? Just a heads up, I managed to catch a typo with my sleepy eyes: --- a/install/share/default-aci.ldif +++ b/install/share/default-aci.ldif @@ -21,11 +21,17 @@ changetype: modify add: aci aci: (targetfilter = "(|(objectClass=ipaConfigObject)(dnahostname=*))")(version 3.0;acl "Admins can change GUI config"; allow (delete) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) -dn: cn=accounts,$SUFFIX +dn: cngaccounts,$SUFFIX > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Fri Jun 13 22:05:49 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Jun 2014 18:05:49 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402688360.4273.6.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> Message-ID: <1402697149.22737.85.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: > I am CC'ing Simo because he wants to review my PBKDF2 implementation. Thank you. I am a bit concerned you are using etree.parse(self.args[0]) directly with the default parser configuration. I think we should, at least, do something like this: parser = etree.XMLParser(resolve_entities=False) parser.parse(self.args[0]) We wouldn't want to inadvertently hit the network when reading this xml file, would we ? Reading the PBKDF2KeyDerivation code I see no particular issue, although I found it a bit hard to decod what it was doing as there are no comments, nor a direct reference to the algorithm you are implementing. It would be nice to have comments either before the function or within the function that gives an explanation of the algorithm being implemented so that whoever needs to read this in the future can readily understand what is going on. I've used this as reference to refresh my memory on the algorithm: http://en.wikipedia.org/wiki/PBKDF2 Btw for the final join, wouldn't it be more compact to use: dk += ''.join(map(chr,u)) ? Actually this creates a new string at each iteration... if you declare dk = [] before the loop and dk.append(''.join(map(chr, u))) in the loop. Then you can return ''.join(dk)[:self.klen] and build the final string only once. Or given you already use lambdas in there perhaps simplify even to: dk = [] for i ... ... dk.append(u) return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] In general the flow is a bit hard to follow due to the clever use of map(), maybe a few comments sprinkled before functions about who/how is meant to use them would help the casual observer. Other than the first point though, anything else looks good to me. Simo. From simo at redhat.com Sat Jun 14 18:29:37 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 14 Jun 2014 14:29:37 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <539B6A31.7090503@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539B6A31.7090503@redhat.com> Message-ID: <1402770577.22737.86.camel@willson.usersys.redhat.com> On Fri, 2014-06-13 at 23:16 +0200, Tomas Babej wrote: > --- a/install/share/default-aci.ldif > +++ b/install/share/default-aci.ldif > @@ -21,11 +21,17 @@ changetype: modify > add: aci > aci: (targetfilter = > "(|(objectClass=ipaConfigObject)(dnahostname=*))")(version 3.0;acl > "Admins can change GUI config"; allow (delete) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";) > > -dn: cn=accounts,$SUFFIX > +dn: cngaccounts,$SUFFIX Ouch, thanks a lot! Simo. -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Mon Jun 16 05:04:57 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 16 Jun 2014 15:04:57 +1000 Subject: [Freeipa-devel] [PATCHES] 0581-0582 ipalib.config: Only convert numeric values to float In-Reply-To: <539AEAB9.3050507@redhat.com> References: <539AEAB9.3050507@redhat.com> Message-ID: <20140616050457.GF11349@dhcp-40-8.bne.redhat.com> On Fri, Jun 13, 2014 at 02:12:41PM +0200, Petr Viktorin wrote: > First patch: minor fix in env loading > > Second patch: > > When api.env is loaded, strings that "look like" floats get auto-converted > to floats. This is wrong, as the conversion can lose precision, which > matters for the new api_version. > > Here's a patch that disables this conversion, and fixes places that the > disabling might break. > > -- > Petr? Changes look fine, apply fine, and ipalib tests pass. ACK to both. Fraser > From 47b6db3e91a16b6598c655edf17d1533b5e3dcc8 Mon Sep 17 00:00:00 2001 > From: Petr Viktorin > Date: Fri, 13 Jun 2014 12:40:32 +0200 > Subject: [PATCH] ipalib.config: Only convert basedn to DN > > The current code would convert values to DN if the key was > a substring of 'basedn', e.g. 'base' or 'sed'. > > Only convert if we're actually dealing with 'basedn'. > --- > ipalib/config.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ipalib/config.py b/ipalib/config.py > index f86c0a5ea3885d2bf89712f91b0c0705dceedd32..709e067416046b2c5174554043be87fa27042bf9 100644 > --- a/ipalib/config.py > +++ b/ipalib/config.py > @@ -257,7 +257,7 @@ def __setitem__(self, key, value): > value = m[value] > elif value.isdigit(): > value = int(value) > - elif key in ('basedn'): > + elif key == 'basedn': > value = DN(value) > else: > try: > -- > 1.9.0 > > From bb3d1e766140b0ed1cbf37562080070cf46cab1e Mon Sep 17 00:00:00 2001 > From: Petr Viktorin > Date: Fri, 13 Jun 2014 12:47:48 +0200 > Subject: [PATCH] ipalib.config: Don't autoconvert values to float > > When api.env is loaded, strings that "look like" floats got > auto-converted to floats. > This is wrong, as the conversion to float can lose precision. > Case in point: the api_version (e.g. '2.88') should never be > interpreted as float. > > Do not automatically convert to float. > > We have two numeric options: startup_timeout and wait_for_dns. > wait_for_dns is already converted to int when used in the code. > Convert startup_timeout to float explicitly when used, so > configuration that specified it with a decimal point continues > to work. > --- > ipalib/config.py | 5 ----- > ipapython/ipautil.py | 2 ++ > ipapython/platform/fedora16/service.py | 2 +- > ipatests/test_ipalib/test_config.py | 5 ++--- > 4 files changed, 5 insertions(+), 9 deletions(-) > > diff --git a/ipalib/config.py b/ipalib/config.py > index 709e067416046b2c5174554043be87fa27042bf9..b12cfd32184edf964353fda9304dbb5149eb525f 100644 > --- a/ipalib/config.py > +++ b/ipalib/config.py > @@ -259,11 +259,6 @@ def __setitem__(self, key, value): > value = int(value) > elif key == 'basedn': > value = DN(value) > - else: > - try: > - value = float(value) > - except (TypeError, ValueError): > - pass > assert type(value) in (unicode, int, float, bool, NoneType, DN) > object.__setattr__(self, key, value) > self.__d[key] = value > diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py > index 844dbb68792c483552149be7ae442a1e40eb9626..d95983b208f47ff42dfc254248e2f4f03d372bff 100644 > --- a/ipapython/ipautil.py > +++ b/ipapython/ipautil.py > @@ -1135,6 +1135,7 @@ def wait_for_open_ports(host, ports, timeout=0): > in seconds may be specified to limit the wait. If the timeout is > exceeded, socket.timeout exception is raised. > """ > + timeout = float(timeout) > if not isinstance(ports, (tuple, list)): > ports = [ports] > > @@ -1156,6 +1157,7 @@ def wait_for_open_socket(socket_name, timeout=0): > Wait until the specified socket on the local host is open. Timeout > in seconds may be specified to limit the wait. > """ > + timeout = float(timeout) > op_timeout = time.time() + timeout > > while True: > diff --git a/ipapython/platform/fedora16/service.py b/ipapython/platform/fedora16/service.py > index 41c241ae5c31df56544b5b2bebd71c5ef109dd6e..86403d82583ed1e70044ce788d7ead7a5f3544a1 100644 > --- a/ipapython/platform/fedora16/service.py > +++ b/ipapython/platform/fedora16/service.py > @@ -152,7 +152,7 @@ def __wait_until_running(self): > 'The httpd proxy is not installed, wait on local port') > use_proxy = False > root_logger.debug('Waiting until the CA is running') > - timeout = api.env.startup_timeout > + timeout = float(api.env.startup_timeout) > op_timeout = time.time() + timeout > while time.time() < op_timeout: > try: > diff --git a/ipatests/test_ipalib/test_config.py b/ipatests/test_ipalib/test_config.py > index f896b893601c3ce85213cac39338095d7ac946f7..e04dd953074342f09b0ca4ca6dbea37eb37aaf48 100644 > --- a/ipatests/test_ipalib/test_config.py > +++ b/ipatests/test_ipalib/test_config.py > @@ -43,8 +43,7 @@ > ('trailing_whitespace', u' value ', u'value'), > ('an_int', 42, 42), > ('int_repr', ' 42 ', 42), > - ('a_float', 3.14, 3.14), > - ('float_repr', ' 3.14 ', 3.14), > + ('not_a_float', '3.14', u'3.14'), > ('true', True, True), > ('true_repr', ' True ', True), > ('false', False, False), > @@ -406,7 +405,7 @@ def test_merge_from_file(self): > assert o.yes is True > assert o.no is False > assert o.number == 42 > - assert o.floating == 3.14 > + assert o.floating == '3.14' > > def new(self, in_tree=False): > """ > -- > 1.9.0 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Mon Jun 16 07:17:09 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jun 2014 09:17:09 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <1402689553.4273.8.camel@ipa.example.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <53982B8C.1060206@redhat.com> <1402504980.2955.16.camel@ipa.example.com> <1402689553.4273.8.camel@ipa.example.com> Message-ID: <539E99F5.4020506@redhat.com> On 13.6.2014 21:59, Nathaniel McCallum wrote: > On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote: >>> On 05/13/2014 04:33 PM, Jan Cholasta wrote: >>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: >>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the >>>>>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Admins, as before, have full access to all token permissions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Normal users have read/search/compare access to all of the >>>>>>>>>>>>>> non-secret >>>>>>>>>>>>>> data for tokens assigned to them, whether protected or >>>>>>>>>>>>>> non-protected. >>>>>>>>>>>>>> Users can add or delete non-protected tokens and modify most >>>>>>>>>>>>>> of their >>>>>>>>>>>>>> metadata. However they cannot create, delete or modify >>>>>>>>>>>>>> protected tokens. >>>>>>>>>>>>>> Regardless of whether the token is protected or not, users >>>>>>>>>>>>>> cannot change >>>>>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In contrast, admins can create protected tokens. This >>>>>>>>>>>>>> protects the token >>>>>>>>>>>>>> from deletion or modification when assigned to users. >>>>>>>>>>>>>> Additionally, when >>>>>>>>>>>>>> a user account is deleted, the assigned non-protected tokens >>>>>>>>>>>>>> are deleted >>>>>>>>>>>>>> but the protected tokens are merely orphaned. This permits >>>>>>>>>>>>>> the token to >>>>>>>>>>>>>> be reassigned without having to recreate it. This last point is >>>>>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>>>>> >>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>>>>> This new version makes ipatokenDisabled visible for token >>>>>>>>>>>>> owners. It is >>>>>>>>>>>>> also writable if the token is non-protected. This >>>>>>>>>>>>> additionally fixes: >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>>>>> This new version changes the way the default value of >>>>>>>>>>>> protected is setup >>>>>>>>>>>> in accordance with the changes made for the review of my patch >>>>>>>>>>>> 0048.2. >>>>>>>>>>>> >>>>>>>>>>>> Nathaniel >>>>>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>>>>> No. Alternate designs are welcome. The code is easy enough to >>>>>>>>>> modify. >>>>>>>>>> >>>>>>>>>>> I did not dig too deep into this, but I think it might be >>>>>>>>>>> better to >>>>>>>>>>> instead use the managedby attribute on a token to limit who can >>>>>>>>>>> delete >>>>>>>>>>> (or administer in other way) the token. On otptoken-add, >>>>>>>>>>> managedby would >>>>>>>>>>> be set to the "whoami" user DN, unless run with --protected, in >>>>>>>>>>> which >>>>>>>>>>> case managedby would be left empty. Then, when deleting a user, >>>>>>>>>>> the >>>>>>>>>>> token would be deleted only if the user manages the token. >>>>>>>>>> It seems to me that the mechanics of this are roughly the same as >>>>>>>>>> protected, just with a different syntax. The cost of this is more >>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses >>>>>>>>>> (is >>>>>>>>>> this possible?) instead of a simple filter. If there is a clear >>>>>>>>>> benefit, >>>>>>>>>> we can justify the more obtuse syntax. >>>>>>>>> >>>>>>>>> We usually try not to create new attributes until it is fully >>>>>>>>> justified. >>>>>>>>> I would like Simo to chime in on this. >>>>>>>> >>>>>>>> I would also prefer to reuse existing attributes and mechanism if >>>>>>>> possible and if it will not preclude future work. >>>>>>>> >>>>>>>> In this case, it "sounds" like managed-by has the appropriate >>>>>>>> meaning: >>>>>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>>>>> >>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>>>>> using managed-by vs a new attribute ? >>>>>>> >>>>>>> These are the ACIs using the protected mechanism: >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>> ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>> "Users can >>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = >>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>> >>>>>>> aci: (target = >>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version >>>>>>> 3.0; >>>>>>> acl "Users can create and delete tokens"; allow (add, delete) >>>>>>> userattr = >>>>>>> "ipatokenOwner#SELFDN";) >>>>>>> >>>>>>> This is what they look like using managedBy (I have not tested this): >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>> ipatokenModel >>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>> userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>> "Users can >>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>> "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token >>>>>>> info"; >>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>> "managedBy#USERDN";) >>>>>>> >>>>>>> aci: (target = >>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >>>>>>> and >>>>>>> userattr = "managedBy#SELFDN";) >>>>>>> >>>>>>> In short: >>>>>>> 1. Owner and manager get read, search and compare. >>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>> >>>>>>> The otptoken-add command should gain the following defaults: >>>>>>> 1. The owner defaults to the user adding the token. >>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>> >>>>>>> This means that if neither owner nor managedBy are specified, the >>>>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>>>> owner is specified, no manager is assumed. >>>>>>> >>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the >>>>>>> above >>>>>>> syntax. This will become clear during testing if we want this >>>>>>> approach. >>>>>>> >>>>>>> Does this look sane? >>>>>> >>>>>> I am not entirely sure your ACI syntax is always right for the second >>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for >>>>>> owner >>>>>> once for manager). >>>>>> >>>>>> I think the read ACIs do not need to list managedby ? Do we plan to >>>>>> have >>>>>> a manager that is another regular user but not the owner nor an admin ? >>>>>> >>>>>> In any case I prefer the sytnax that uses managedby, as it has more >>>>>> potential. >>>>> >>>>> Attached is a new version of the patch which implements the feature >>>>> using managedBy instead of ipatokenProtected. One important thing needs >>>>> to be said about this patch. I am not exposing managedBy in either the >>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>> expose this similar to owner or as a relationship? >>>> >>>> I would expose it, as a relationship. (Note that ipatokenowner should >>>> ideally be represented as a relationship too, but the framework does >>>> not support 1-to-many relationships ATM.) >>>> >>>> >>>> Just curious, why are the ACIs divided like this: >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl >>>> "Users/managers can read basic token info"; allow (read, search, >>>> compare) userattr = "ipatokenOwner#USERDN" or userattr = >>>> "managedBy#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >>>> details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>> "Users/managers can see HOTP details"; allow (read, search, compare) >>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>> >>>> IMHO you could make them less complex by dividing them like this: >>>> >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel || ipatokenSerial || ipatokenOwner || >>>> ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token >>>> details"; allow (read, search, compare) userattr = >>>> "ipatokenOwner#USERDN";) >>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>> ipatokenModel || ipatokenSerial || ipatokenOwner || >>>> ipatokenOTPalgorithm || ipatokenOTPdigits || >>>> ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token >>>> details"; allow (read, search, compare) userattr = "managedBy#USERDN";) >>> do you mean aci: (targetfilter = >>> "(|(objectClass=ipaToken)(objectClass=ipatokenTOTP)(objectClass=ipatokenHOTP))") >>> or are the attrs like ipatokenOTPdigits also in the ipatoken objectclass ? >>>> >> >> Ludwig, >> >> objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top >> ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) >> MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore >> $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) >> X-ORIGIN 'IPA OTP') >> >> objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP >> ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ >> ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ >> ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP') >> >> objectClasses: (2.16.840.1.113730.3.8.16.2.5 NAME 'ipatokenHOTP' SUP >> ipaToken STRUCTURAL DESC 'HOTP Token Type' MUST (ipatokenOTPkey $ >> ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenHOTPcounter) X-ORIGIN >> 'IPA OTP') > > Ludwig / Jan, > > I'd like to propose that we move ahead and merge this patch since the > only outstanding item is the question of performance for the ACIs. > > Nathaniel > I'm fine with that. -- Jan Cholasta From pviktori at redhat.com Mon Jun 16 07:53:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 09:53:52 +0200 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402690825.22737.84.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> Message-ID: <539EA290.5020604@redhat.com> On 06/13/2014 10:20 PM, Simo Sorce wrote: [...] > 2) and I think this is a MUCH bigger issue, the Admin users are > unbounded and pass any Access Control Check and this means they can now > retrieve any key for users or machines. > It is already bad enough that admins can unconditionally set any key, > but this at least leaves back a pretty big trail (the original client > password/key fails to work), and is a necessary evil (password resets, > hosts creation/recovery). > But I am not very comfortable with the idea an admin can retrieve any > key without actually ending up changing it. Petr do we have any short > term plan to address the Admin's super ACI ? No, nothing in the short term. -- Petr? From mkosek at redhat.com Mon Jun 16 08:16:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jun 2014 10:16:13 +0200 Subject: [Freeipa-devel] [PATCH 0049] Add support for protected tokens In-Reply-To: <539E99F5.4020506@redhat.com> References: <1399308160.3102.6.camel@ipa.example.com> <1399384186.2416.13.camel@ipa.example.com> <1399388939.9864.2.camel@ipa.example.com> <536A0005.7090101@redhat.com> <1399467936.3786.5.camel@ipa.example.com> <536A3AFF.5050105@redhat.com> <1399475839.26263.192.camel@willson.li.ssimo.org> <1399566394.2482.27.camel@ipa.example.com> <1399571481.2708.2.camel@willson.li.ssimo.org> <1399921364.3005.9.camel@ipa.example.com> <53722D35.1060901@redhat.com> <53982B8C.1060206@redhat.com> <1402504980.2955.16.camel@ipa.example.com> <1402689553.4273.8.camel@ipa.example.com> <539E99F5.4020506@redhat.com> Message-ID: <539EA7CD.9000602@redhat.com> On 06/16/2014 09:17 AM, Jan Cholasta wrote: > On 13.6.2014 21:59, Nathaniel McCallum wrote: >> On Wed, 2014-06-11 at 12:43 -0400, Nathaniel McCallum wrote: >>> On Wed, 2014-06-11 at 12:12 +0200, Ludwig Krispenz wrote: >>>> On 05/13/2014 04:33 PM, Jan Cholasta wrote: >>>>> On 12.5.2014 21:02, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-05-08 at 13:51 -0400, Simo Sorce wrote: >>>>>>> On Thu, 2014-05-08 at 12:26 -0400, Nathaniel McCallum wrote: >>>>>>>> On Wed, 2014-05-07 at 11:17 -0400, Simo Sorce wrote: >>>>>>>>> On Wed, 2014-05-07 at 09:54 -0400, Dmitri Pal wrote: >>>>>>>>>> On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: >>>>>>>>>>> On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 6.5.2014 17:08, Nathaniel McCallum wrote: >>>>>>>>>>>>> On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>> On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: >>>>>>>>>>>>>>> This also constitutes a rethinking of the token ACIs after the >>>>>>>>>>>>>>> introduction of SELFDN support. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Admins, as before, have full access to all token permissions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Normal users have read/search/compare access to all of the >>>>>>>>>>>>>>> non-secret >>>>>>>>>>>>>>> data for tokens assigned to them, whether protected or >>>>>>>>>>>>>>> non-protected. >>>>>>>>>>>>>>> Users can add or delete non-protected tokens and modify most >>>>>>>>>>>>>>> of their >>>>>>>>>>>>>>> metadata. However they cannot create, delete or modify >>>>>>>>>>>>>>> protected tokens. >>>>>>>>>>>>>>> Regardless of whether the token is protected or not, users >>>>>>>>>>>>>>> cannot change >>>>>>>>>>>>>>> a token's ownership or unique identity. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In contrast, admins can create protected tokens. This >>>>>>>>>>>>>>> protects the token >>>>>>>>>>>>>>> from deletion or modification when assigned to users. >>>>>>>>>>>>>>> Additionally, when >>>>>>>>>>>>>>> a user account is deleted, the assigned non-protected tokens >>>>>>>>>>>>>>> are deleted >>>>>>>>>>>>>>> but the protected tokens are merely orphaned. This permits >>>>>>>>>>>>>>> the token to >>>>>>>>>>>>>>> be reassigned without having to recreate it. This last point is >>>>>>>>>>>>>>> particularly useful in the case of hardware tokens. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4228 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NOTE: This patch depends on my patch 0048. >>>>>>>>>>>>>> This new version makes ipatokenDisabled visible for token >>>>>>>>>>>>>> owners. It is >>>>>>>>>>>>>> also writable if the token is non-protected. This >>>>>>>>>>>>>> additionally fixes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4259 >>>>>>>>>>>>> This new version changes the way the default value of >>>>>>>>>>>>> protected is setup >>>>>>>>>>>>> in accordance with the changes made for the review of my patch >>>>>>>>>>>>> 0048.2. >>>>>>>>>>>>> >>>>>>>>>>>>> Nathaniel >>>>>>>>>>>> Is using the ipatokenprotected attribute the final design? >>>>>>>>>>> No. Alternate designs are welcome. The code is easy enough to >>>>>>>>>>> modify. >>>>>>>>>>> >>>>>>>>>>>> I did not dig too deep into this, but I think it might be >>>>>>>>>>>> better to >>>>>>>>>>>> instead use the managedby attribute on a token to limit who can >>>>>>>>>>>> delete >>>>>>>>>>>> (or administer in other way) the token. On otptoken-add, >>>>>>>>>>>> managedby would >>>>>>>>>>>> be set to the "whoami" user DN, unless run with --protected, in >>>>>>>>>>>> which >>>>>>>>>>>> case managedby would be left empty. Then, when deleting a user, >>>>>>>>>>>> the >>>>>>>>>>>> token would be deleted only if the user manages the token. >>>>>>>>>>> It seems to me that the mechanics of this are roughly the same as >>>>>>>>>>> protected, just with a different syntax. The cost of this is more >>>>>>>>>>> complex ACIs. In particular, we'd have to use two userdn clauses >>>>>>>>>>> (is >>>>>>>>>>> this possible?) instead of a simple filter. If there is a clear >>>>>>>>>>> benefit, >>>>>>>>>>> we can justify the more obtuse syntax. >>>>>>>>>> >>>>>>>>>> We usually try not to create new attributes until it is fully >>>>>>>>>> justified. >>>>>>>>>> I would like Simo to chime in on this. >>>>>>>>> >>>>>>>>> I would also prefer to reuse existing attributes and mechanism if >>>>>>>>> possible and if it will not preclude future work. >>>>>>>>> >>>>>>>>> In this case, it "sounds" like managed-by has the appropriate >>>>>>>>> meaning: >>>>>>>>> "who manages the token ?" -> myself, admin, other, none ? >>>>>>>>> >>>>>>>>> Nathaniel can you send 2 lines showing the difference in ACIs between >>>>>>>>> using managed-by vs a new attribute ? >>>>>>>> >>>>>>>> These are the ACIs using the protected mechanism: >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>>> ipatokenModel >>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>> userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>>> "Users can >>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>> "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = >>>>>>>> "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE)))")(targetattrs = >>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>> ipatokenSerial")(version 3.0; acl "Users can write basic token info"; >>>>>>>> allow (write) userattr = "ipatokenOwner#USERDN";) >>>>>>>> >>>>>>>> aci: (target = >>>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>> = "(&(objectClass=ipaToken)(!(ipatokenProtected=TRUE))))")(version >>>>>>>> 3.0; >>>>>>>> acl "Users can create and delete tokens"; allow (add, delete) >>>>>>>> userattr = >>>>>>>> "ipatokenOwner#SELFDN";) >>>>>>>> >>>>>>>> This is what they look like using managedBy (I have not tested this): >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>>>>> ipatokenModel >>>>>>>> || ipatokenSerial || ipatokenOwner || ipatokenProtected")(version 3.0; >>>>>>>> acl "Users can read basic token info"; allow (read, search, compare) >>>>>>>> userattr = "ipatokenOwner#USERDN"; allow (read, search, compare) >>>>>>>> userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users can see TOTP details"; >>>>>>>> allow (read, search, compare) userattr = "ipatokenOwner#USERDN"; allow >>>>>>>> (read, search, compare) userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>>>>> "Users can >>>>>>>> see HOTP details"; allow (read, search, compare) userattr = >>>>>>>> "ipatokenOwner#USERDN"; allow (read, search, compare) userattr = >>>>>>>> "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>>>>> "description || ipatokenDisabled || ipatokenNotBefore || >>>>>>>> ipatokenNotAfter || ipatokenVendor || ipatokenModel || >>>>>>>> ipatokenSerial")(version 3.0; acl "Managers can write basic token >>>>>>>> info"; >>>>>>>> allow (write) userattr = "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (targetfilter = "(objectClass=ipaToken)")(version 3.0; acl >>>>>>>> "Managers can delete tokens"; allow (delete) userattr = >>>>>>>> "managedBy#USERDN";) >>>>>>>> >>>>>>>> aci: (target = >>>>>>>> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter >>>>>>>> = "(objectClass=ipaToken)")(version 3.0; acl "Users can create >>>>>>>> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" >>>>>>>> and >>>>>>>> userattr = "managedBy#SELFDN";) >>>>>>>> >>>>>>>> In short: >>>>>>>> 1. Owner and manager get read, search and compare. >>>>>>>> 2. Manager gets write (to select attributes) and delete. >>>>>>>> 3. Users can create self-managed tokens for themselves only. >>>>>>>> >>>>>>>> The otptoken-add command should gain the following defaults: >>>>>>>> 1. The owner defaults to the user adding the token. >>>>>>>> 2. If owner == user adding token, managedBy defaults to owner. >>>>>>>> 3. Otherwise, managedBy defaults to None. >>>>>>>> >>>>>>>> This means that if neither owner nor managedBy are specified, the >>>>>>>> default is a self-owned, self-managed token. Likewise, if a different >>>>>>>> owner is specified, no manager is assumed. >>>>>>>> >>>>>>>> rcrit expresses worry that ipalib's ACI parser may not handle the >>>>>>>> above >>>>>>>> syntax. This will become clear during testing if we want this >>>>>>>> approach. >>>>>>>> >>>>>>>> Does this look sane? >>>>>>> >>>>>>> I am not entirely sure your ACI syntax is always right for the second >>>>>>> set. and perhaps we want to duplicate ACIs in some cases (once for >>>>>>> owner >>>>>>> once for manager). >>>>>>> >>>>>>> I think the read ACIs do not need to list managedby ? Do we plan to >>>>>>> have >>>>>>> a manager that is another regular user but not the owner nor an admin ? >>>>>>> >>>>>>> In any case I prefer the sytnax that uses managedby, as it has more >>>>>>> potential. >>>>>> >>>>>> Attached is a new version of the patch which implements the feature >>>>>> using managedBy instead of ipatokenProtected. One important thing needs >>>>>> to be said about this patch. I am not exposing managedBy in either the >>>>>> UI, the CLI or LDAP (ACI). Do we care about this? If yes, should I >>>>>> expose this similar to owner or as a relationship? >>>>> >>>>> I would expose it, as a relationship. (Note that ipatokenowner should >>>>> ideally be represented as a relationship too, but the framework does >>>>> not support 1-to-many relationships ATM.) >>>>> >>>>> >>>>> Just curious, why are the ACIs divided like this: >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>> ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl >>>>> "Users/managers can read basic token info"; allow (read, search, >>>>> compare) userattr = "ipatokenOwner#USERDN" or userattr = >>>>> "managedBy#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipatokenTOTP)")(targetattrs = >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Users/managers can see TOTP >>>>> details"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipatokenHOTP)")(targetattrs = >>>>> "ipatokenOTPalgorithm || ipatokenOTPdigits")(version 3.0; acl >>>>> "Users/managers can see HOTP details"; allow (read, search, compare) >>>>> userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";) >>>>> >>>>> IMHO you could make them less complex by dividing them like this: >>>>> >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>> ipatokenModel || ipatokenSerial || ipatokenOwner || >>>>> ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Owner can read token >>>>> details"; allow (read, search, compare) userattr = >>>>> "ipatokenOwner#USERDN";) >>>>> aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = >>>>> "objectclass || description || ipatokenUniqueID || ipatokenDisabled || >>>>> ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || >>>>> ipatokenModel || ipatokenSerial || ipatokenOwner || >>>>> ipatokenOTPalgorithm || ipatokenOTPdigits || >>>>> ipatokenTOTPtimeStep")(version 3.0; acl "Managers can read token >>>>> details"; allow (read, search, compare) userattr = "managedBy#USERDN";) >>>> do you mean aci: (targetfilter = >>>> "(|(objectClass=ipaToken)(objectClass=ipatokenTOTP)(objectClass=ipatokenHOTP))") >>>> >>>> or are the attrs like ipatokenOTPdigits also in the ipatoken objectclass ? >>>>> >>> >>> Ludwig, >>> >>> objectClasses: (2.16.840.1.113730.3.8.16.2.1 NAME 'ipaToken' SUP top >>> ABSTRACT DESC 'Abstract token class for tokens' MUST (ipatokenUniqueID) >>> MAY (description $ ipatokenOwner $ ipatokenDisabled $ ipatokenNotBefore >>> $ ipatokenNotAfter $ ipatokenVendor $ ipatokenModel $ ipatokenSerial) >>> X-ORIGIN 'IPA OTP') >>> >>> objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP >>> ipaToken STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ >>> ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenTOTPclockOffset $ >>> ipatokenTOTPtimeStep) X-ORIGIN 'IPA OTP') >>> >>> objectClasses: (2.16.840.1.113730.3.8.16.2.5 NAME 'ipatokenHOTP' SUP >>> ipaToken STRUCTURAL DESC 'HOTP Token Type' MUST (ipatokenOTPkey $ >>> ipatokenOTPalgorithm $ ipatokenOTPdigits $ ipatokenHOTPcounter) X-ORIGIN >>> 'IPA OTP') >> >> Ludwig / Jan, >> >> I'd like to propose that we move ahead and merge this patch since the >> only outstanding item is the question of performance for the ACIs. >> >> Nathaniel >> > > I'm fine with that. > Ok, good. Pushed 0049a.2 to master: 98851256f94efe55b873f01aa46b2cdcda4a3efb Martin From abokovoy at redhat.com Mon Jun 16 08:53:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Jun 2014 11:53:36 +0300 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402697149.22737.85.camel@willson.usersys.redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> <1402697149.22737.85.camel@willson.usersys.redhat.com> Message-ID: <20140616085336.GB6321@redhat.com> On Fri, 13 Jun 2014, Simo Sorce wrote: >On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: >> I am CC'ing Simo because he wants to review my PBKDF2 implementation. > >Thank you. >I am a bit concerned you are using etree.parse(self.args[0]) directly >with the default parser configuration. > >I think we should, at least, do something like this: >parser = etree.XMLParser(resolve_entities=False) >parser.parse(self.args[0]) > >We wouldn't want to inadvertently hit the network when reading this xml >file, would we ? > > >Reading the PBKDF2KeyDerivation code I see no particular issue, although >I found it a bit hard to decod what it was doing as there are no >comments, nor a direct reference to the algorithm you are implementing. > >It would be nice to have comments either before the function or within >the function that gives an explanation of the algorithm being >implemented so that whoever needs to read this in the future can readily >understand what is going on. >I've used this as reference to refresh my memory on the algorithm: >http://en.wikipedia.org/wiki/PBKDF2 > >Btw for the final join, wouldn't it be more compact to use: >dk += ''.join(map(chr,u)) ? > >Actually this creates a new string at each iteration... >if you declare dk = [] before the loop and dk.append(''.join(map(chr, >u))) in the loop. >Then you can return ''.join(dk)[:self.klen] and build the final string >only once. > >Or given you already use lambdas in there perhaps simplify even to: > >dk = [] >for i ... > ... > dk.append(u) > >return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] > > >In general the flow is a bit hard to follow due to the clever use of >map(), maybe a few comments sprinkled before functions about who/how is >meant to use them would help the casual observer. > >Other than the first point though, anything else looks good to me. I read through the patch and apart from the points Simo made, I don't have much complaints. One additional thing to do is how to test it -- how to create the payload? Since this code doesn't require anything specific, it could be well tested through a CI infrastructure. Additionally, man page is missing. -- / Alexander Bokovoy From pviktori at redhat.com Mon Jun 16 09:17:20 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 11:17:20 +0200 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402697149.22737.85.camel@willson.usersys.redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> <1402697149.22737.85.camel@willson.usersys.redhat.com> Message-ID: <539EB620.5040905@redhat.com> On 06/14/2014 12:05 AM, Simo Sorce wrote: > On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: >> I am CC'ing Simo because he wants to review my PBKDF2 implementation. > > Thank you. > I am a bit concerned you are using etree.parse(self.args[0]) directly > with the default parser configuration. > > I think we should, at least, do something like this: > parser = etree.XMLParser(resolve_entities=False) > parser.parse(self.args[0]) > > We wouldn't want to inadvertently hit the network when reading this xml > file, would we ? > > > Reading the PBKDF2KeyDerivation code I see no particular issue, although > I found it a bit hard to decod what it was doing as there are no > comments, nor a direct reference to the algorithm you are implementing. > > It would be nice to have comments either before the function or within > the function that gives an explanation of the algorithm being > implemented so that whoever needs to read this in the future can readily > understand what is going on. > I've used this as reference to refresh my memory on the algorithm: > http://en.wikipedia.org/wiki/PBKDF2 > > Btw for the final join, wouldn't it be more compact to use: > dk += ''.join(map(chr,u)) ? > > Actually this creates a new string at each iteration... > if you declare dk = [] before the loop and dk.append(''.join(map(chr, > u))) in the loop. > Then you can return ''.join(dk)[:self.klen] and build the final string > only once. > > Or given you already use lambdas in there perhaps simplify even to: > > dk = [] > for i ... > ... > dk.append(u) > > return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] If you want to use idiomatic Python, starmap(lambda a, b: a ^ b, izip(u, [ord(c) for c in l])) can be rewritten as [a ^ ord(b) for a, b in zip(u, l)] (izip is overkill if the list isn't too long) then you can use dk.extend(u) to keep a single list of ints in dk, and at the end, return ''.join(chr(c) for c in dk[:self.klen]) to turn part you need into a string. It would be nice to have some tests for this. > > In general the flow is a bit hard to follow due to the clever use of > map(), maybe a few comments sprinkled before functions about who/how is > meant to use them would help the casual observer. > > Other than the first point though, anything else looks good to me. > > Simo. I see the patch contains lots of classes with no state and a single method. I believe it would simplify the code greatly if functions were used instead. -- Petr? From mkosek at redhat.com Mon Jun 16 11:31:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jun 2014 13:31:11 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <539852A2.6040109@redhat.com> References: <52A0817E.2080002@redhat.com> <1389223583.26102.187.camel@willson.li.ssimo.org> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> Message-ID: <539ED57F.4070402@redhat.com> On 06/11/2014 02:59 PM, Jan Cholasta wrote: > On 11.6.2014 13:29, Martin Kosek wrote: >> On 06/11/2014 10:58 AM, Jan Cholasta wrote: >>> On 10.6.2014 09:55, Martin Kosek wrote: >>>> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>>>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>>>> managedby_host >>>>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>>>> why that >>>>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>>>> original >>>>>>>>>>> check is not right anymore ? >>>>>>>>>> >>>>>>>>>> The original check is wrong, see >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>>>> handled by ACIs. >>>>>>>>> >>>>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>>>> write the usercertificate. >>>>>>>>> >>>>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>>>> >>>>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>>>> Certificates and kerberos keys". >>>>>>>> >>>>>>>> I think the check can be extended to users as well, so that requesting >>>>>>>> certificate with SAN is allowed only to users which have write access to >>>>>>>> the SAN services. >>>>>> >>>>>> I have done the modification, see attached patches. >>>>>> >>>>>>> >>>>>>> Sounds good to me then, thanks for explaining. >>>>>>> >>>>>>> The patches also look good, but I would like someone to give them a try >>>>>>> for a formal ack. >>>>>> >>>>>> OK, thanks. >>>>>> >>>>> >>>>> Bump. >>>>> >>>>> I have added stricter validation of subject alt names as well as certificate >>>>> extensions in general to the second patch. >>>> >>>> Thanks! >>>> >>>>> Updated patches attached. >>>>> >>>>> Note that you will need python-nss 0.15 in order to test, you can get a >>>>> RPM for >>>>> Fedora here: . >>>> >>>> John, do you think we could build python-nss 0.15 also for Fedora 20? The fix >>>> incorporated in it is pretty important to warrant bugfix update in bodhi. It >>>> would also allow FreeIPA 4.0 to be installed on Fedora 20. >>>> >>>>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not >>>>> work, >>>>> because . >>>> >>>> This worked for me, I suspect this is a DS bug. More info in the ticket. >>>> >>>> Now back to review of the patch: >>>> >>>> 210.4: looks ok >>>> 234.4: >>>> >>>> 1) Virtual operation "request certificate with subjectaltname" should be a >>>> member of Certificate Administrators privilege >>> >>> OK. >>> >>>> >>>> >>>> 2) I would write "Request Certificate With SubjectAltName" with "with" instead >>>> of "With". I.e.: >>>> Request Certificate with SubjectAltName >>> >>> OK. >>> >>>> >>>> >>>> 3) Why is the extension check only enforced for non-hosts? >>>> >>>> + if not bind_principal.startswith('host/'): >>>> + for ext in extensions: >>>> + operation = self._allowed_extensions.get(ext) >>>> + if operation: >>>> + self.check_access(operation) >>>> >>>> My tricky certmonger request passed: >>>> >>>> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g >>>> 2048 -r >>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>> test2.example.com >>>> -E mkosek at redhat.com >>>> >>>> while when I posted the same CSR as privileged user, it was rejected: >>>> >>>> $ klist >>>> Ticket cache: KEYRING:persistent:962000003:962000003 >>>> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >>>> >>>> $ ipa cert-request --principal test/`hostname` certmonger.csr >>>> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden >>> >>> Right, I meant to NACK myself, but you were faster. Fixed. >>> >>>> >>>> >>>> 4) Regular users cannot read Virtual Operations, so even if I assign them a >>>> permission, command is refused: >>>> >>>> $ ipa cert-request --principal test/`hostname` openssl.csr >>>> ipa: ERROR: Insufficient access: No such virtual command >>>> >>>> I think we will need to create new managed permission "Read Virtual >>>> Operations" >>>> and assign it to "Certificate Administrators" privilege by default as this >>>> privilege has the virtual operation permissions assigned. Petr3, what is your >>>> take on this? >>>> >>>> Otherwise the patch worked well for me, the authorization part looked OK. My >>>> biggest concern was just the host/user differentiation wrt unknown >>>> subjectaltname types. >>>> >>>> Martin >>>> >>> >>> Updated patches attached. >>> >> >> 1) I could not compile the patch set: >> >> $ make rpms >> ... >> if [ "" != "yes" ]; then \ >> ./makeapi --validate; \ >> ./makeaci --validate; \ >> fi >> Traceback (most recent call last): >> File "./makeapi", line 457, in >> sys.exit(main()) >> File "./makeapi", line 428, in main >> api.finalize() >> File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize >> self.__do_if_not_done('load_plugins') >> File "/root/freeipa-master/ipalib/plugable.py", line 482, in __do_if_not_done >> getattr(self, name)() >> File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins >> self.import_plugins('ipalib') >> File "/root/freeipa-master/ipalib/plugable.py", line 689, in import_plugins >> __import__(fullname) >> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >> from ipalib import pkcs10 >> File "/root/freeipa-master/ipalib/pkcs10.py", line 77 >> .replace('@', '\\@') >> ... >> >> The rest of the notes are thus only from reading. > > Sorry, last minute change gone wrong. > >> >> 2) There are lines like >> >> + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': >> >> >> or >> >> + if name_type not in ('DNS name', >> + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >> + 'Other Name (OID.1.3.6.1.5.2.2)'): >> >> or >> >> + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >> + 'Other Name (OID.1.3.6.1.5.2.2)'): >> >> Can we do something better? Getting the extension type based on it's >> description seems extremely unstable to me. > > These are SAN types, not extension types. Unfortunately the textual > descriptions are the only SAN type representation available in python-nss which > includes OIDs of other names. > >> >> Can we for example modify get_subjectaltname to get the type based on >> CertificateExtension object's oid or oid_tag attributes? > > No, see above. > >> >> I would rather see get_subjectaltname return solid type like >> CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing >> descriptions. It would be more readable, too. > > Done. > >> >> Martin >> > > Updated patches attached. 1) We still miss the managed permission allowing Certificate Administrators to read Virtual Commands 2) Extension check Wouldn't if any(ext not in self._allowed_extensions for ext in extensions) be more readable than + for ext in extensions: + if ext not in self._allowed_extensions: + raise errors.ValidationError( + name='csr', error=_("extension %s is forbidden") % ext) ? 3) I find this part still not ideal: + for name_type, name in subjectaltname: + if name_type not in (pkcs10.SAN_DNSNAME, + pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, + pkcs10.SAN_OTHERNAME_UPN): + raise errors.ValidationError( + name='csr', + error=_("subject alt name type %s is forbidden") % + name_type) I still think we should instead: - change get_subjectaltname's return value to tuples of: - numeric type, i.e. SAN_DNSNAME,SAN_OTHERNAME_UPN or SAN_OTHERNAME_KRB5PRINCIPALNAME - content - raise error when an unknown SAN type is detected This would: a) Allow us to be sure that we do not miss any yet unknown SAN types or allow us to catch the situation when name_type string changes b) Allow more natural comparison of the SAN type "name_type == pkcs10.SAN_DNSNAME" instead of "name_type in pkcs10.SAN_DNSNAME" 3) I am thinking why do we need to introduce all the ASN parsing? I am talking about _decode_krb5principalname and others. If we do not use the result anywhere, why should we include this part at all? 4) I get crash in the certmonger request: ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com -E mkosek at redhat.com # ipa-getcert list -i test-san-1 Number of certificates and requests being tracked: 8. Request ID 'test-san-1': status: CA_UNREACHABLE ca-error: Server failed request, will retry: -504 (HTTP response code is 500, not 200). stuck: yes HTTPD traceback [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote 10.34.47.236:12] Traceback (most recent call last): [Mon Jun 16 13:06:14.528844 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/share/ipa/wsgi.py", line 49, in application [Mon Jun 16 13:06:14.529466 2014] [:error] [pid 12941] [remote 10.34.47.236:12] return api.Backend.wsgi_dispatch(environ, start_response) [Mon Jun 16 13:06:14.529614 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 251, in __call__ [Mon Jun 16 13:06:14.553116 2014] [:error] [pid 12941] [remote 10.34.47.236:12] return self.route(environ, start_response) [Mon Jun 16 13:06:14.553261 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 263, in route [Mon Jun 16 13:06:14.553410 2014] [:error] [pid 12941] [remote 10.34.47.236:12] return app(environ, start_response) [Mon Jun 16 13:06:14.553604 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 637, in __call__ [Mon Jun 16 13:06:14.553749 2014] [:error] [pid 12941] [remote 10.34.47.236:12] environ, start_response) [Mon Jun 16 13:06:14.553895 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 397, in __call__ [Mon Jun 16 13:06:14.554023 2014] [:error] [pid 12941] [remote 10.34.47.236:12] response = self.wsgi_execute(environ) [Mon Jun 16 13:06:14.554138 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in wsgi_execute [Mon Jun 16 13:06:14.554276 2014] [:error] [pid 12941] [remote 10.34.47.236:12] result = self.Command[name](*args, **options) [Mon Jun 16 13:06:14.554413 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ [Mon Jun 16 13:06:14.585933 2014] [:error] [pid 12941] [remote 10.34.47.236:12] ret = self.run(*args, **options) [Mon Jun 16 13:06:14.586170 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run [Mon Jun 16 13:06:14.586305 2014] [:error] [pid 12941] [remote 10.34.47.236:12] return self.execute(*args, **options) [Mon Jun 16 13:06:14.586490 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 316, in execute [Mon Jun 16 13:06:14.592390 2014] [:error] [pid 12941] [remote 10.34.47.236:12] subjectaltname = pkcs10.get_subjectaltname(csr) or () [Mon Jun 16 13:06:14.592565 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/ipalib/pkcs10.py", line 129, in get_subjectaltname [Mon Jun 16 13:06:14.596411 2014] [:error] [pid 12941] [remote 10.34.47.236:12] san = decoder.decode(san, asn1Spec=_SubjectAltName())[0] [Mon Jun 16 13:06:14.596555 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line 792, in __call__ [Mon Jun 16 13:06:14.598268 2014] [:error] [pid 12941] [remote 10.34.47.236:12] stGetValueDecoder, self, substrateFun [Mon Jun 16 13:06:14.598404 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line 367, in valueDecoder [Mon Jun 16 13:06:14.598534 2014] [:error] [pid 12941] [remote 10.34.47.236:12] component, head = decodeFun(head, asn1Spec) [Mon Jun 16 13:06:14.598633 2014] [:error] [pid 12941] [remote 10.34.47.236:12] File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line 798, in __call__ [Mon Jun 16 13:06:14.598746 2014] [:error] [pid 12941] [remote 10.34.47.236:12] '%r not in asn1Spec: %r' % (tagSet, asn1Spec) [Mon Jun 16 13:06:14.598954 2014] [:error] [pid 12941] [remote 10.34.47.236:12] PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: _GeneralName() Martin From pviktori at redhat.com Mon Jun 16 11:39:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 13:39:39 +0200 Subject: [Freeipa-devel] [PATCHES] 0581-0582 ipalib.config: Only convert numeric values to float In-Reply-To: <20140616050457.GF11349@dhcp-40-8.bne.redhat.com> References: <539AEAB9.3050507@redhat.com> <20140616050457.GF11349@dhcp-40-8.bne.redhat.com> Message-ID: <539ED77B.1010408@redhat.com> On 06/16/2014 07:04 AM, Fraser Tweedale wrote: > On Fri, Jun 13, 2014 at 02:12:41PM +0200, Petr Viktorin wrote: >> First patch: minor fix in env loading >> >> Second patch: >> >> When api.env is loaded, strings that "look like" floats get auto-converted >> to floats. This is wrong, as the conversion can lose precision, which >> matters for the new api_version. >> >> Here's a patch that disables this conversion, and fixes places that the >> disabling might break. >> >> -- >> Petr? > > Changes look fine, apply fine, and ipalib tests pass. ACK to both. Thanks for the review! Pushed to master: 521df77744233f424ec68caa68548bede6e575fb -- Petr? From tbabej at redhat.com Mon Jun 16 12:53:10 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 16 Jun 2014 14:53:10 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53971F35.5090006@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> Message-ID: <539EE8B6.7010003@redhat.com> On 06/10/2014 05:07 PM, Petr Viktorin wrote: > On 06/10/2014 10:13 AM, Tomas Babej wrote: >> Thank you for the detailed review. Responses to all the issues found are >> inline: > > I'm calling it a day now, but here are initial comments from reading > the patches. > >> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> the following set of patches implements the ticket: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>> > [...] >>>> >>>> 0202: OK > >>>> 0203: >>>> >>>> It would be nice to have the Services' __init__s take an optional >>>> `api` >>>> argument, and then use `self.api` everywhere. I'm certain we'd >>>> appreciate it in the future. >>>> >> >> Added. > > Nice! Just one more thing. > I don't think it's good practice to pass additional *args to > superclasses, unless it's really some sequence of items. > In this case you should use always name the arguments to prevent > surprises, so **kwargs is enough. Done! > > >>>> 0204: >>>> When commenting what a function does, use a docstring. >>>> >> Will be documented in a later patch. > > You mean an upcoming patchset, right? Yep, documentation patch is attached. > >>>> 0205: OK >>>> 0206: OK >>>> 0207: OK > >>>> 0208: >>>> check_selinux_status, in the RuntimeError message, assumes that it's >>>> called from an installation. This should at least be pointed out in >>>> the >>>> docstring. > >>>> 0209: >>>> ipa-client-install, --noac help: "Red Hat" has two words. Also it's a >>>> company; I don't think "Red Hat based distributions" is a correct >>>> use of >>>> the trademark. In comments/class names it doesn't really matter but in >>>> user-facing text we should try to be professional. >>>> We can either go with "Fedora-based" here and sort this out in a RHEL >>>> patch if needed, or better, adjust the help text (or visibility of the >>>> option) based on if the platform uses authconfig. >>>> >> I'm thinking we could go as far as to provide a way in the installers to >> define >> platform dependent options. What do you think? > > See Martin's mail. This patchset is already too long for a general > solution here. > You could file a ticket for a better fix so it's not forgotten. Fixed and I filed https://fedorahosted.org/freeipa/ticket/4377 . > >>>> base.tasks: These need docstrings. Will those included in the >>>> documentation that you want to provide later? > > 0210: OK > 0211: OK > 0212: OK > 0213: OK > 0214: OK > > 0215: > > You could rename the commit now > > 0216: > [...] >> As we discussed, to avoid cyclical imports, separate modules for paths >> and tasks are needed. >> Calling the paths_namespace object by its descriptive name is rather >> cumbersome, so I changed that to: >> >> from ipaplatform.paths import paths >> from ipaplatform.tasks import tasks > > OK > > > I looked over the paths again, and saw this: > > SLAPD_INSTANCE_CONFIG = "/etc/dirsrv/slapd-" > ETC_DIRSRV_SLAPD_INSTANCE = "/etc/dirsrv/slapd-%s" > > SLAPD_INSTANCE_CONFIG should be removed. > > ETC_PKI_TOMCAT_ALIAS = "/etc/pki/pki-tomcat/alias" > PKI_TOMCAT_ALIAS_DIR = "/etc/pki/pki-tomcat/alias/" > > We only need one of these. I replaced both, it required some addtional refactoring though. > >>> ipatests/test_xmlrpc/test_automount_plugin.py: this change is >>> unnecessary > > I was talking about this one: > - keyname = u'/home' > + keyname = u'/home/' > It's not only unnecessary, it also breaks a test. Fixed. > > 0217: OK > 0218: OK > 0219: Ok > 0220: OK > 0221: OK > 0222: OK > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4284 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0202-3-ipaplatform-Create-separate-module-for-platform-file.patch Type: text/x-patch Size: 6513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0203-3-ipaplatform-Move-service-base-platfrom-related-funct.patch Type: text/x-patch Size: 32999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0204-3-ipaplatform-Move-default-implementations-of-tasks-fr.patch Type: text/x-patch Size: 3636 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0205-3-ipaplatform-Create-default-implementations-for-tasks.patch Type: text/x-patch Size: 870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0206-3-ipaplatform-Add-base-fedora-platform-module.patch Type: text/x-patch Size: 5314 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0207-3-ipaplatform-Moved-Fedora-16-service-implementations-.patch Type: text/x-patch Size: 20311 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0208-3-ipaplatform-Move-restore_context-and-check_selinux_s.patch Type: text/x-patch Size: 5549 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0209-3-ipaplatform-Do-not-require-custom-Authconfig-impleme.patch Type: text/x-patch Size: 19704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0210-3-ipaplatform-Remove-legacy-redhat-platform-module.patch Type: text/x-patch Size: 12402 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0211-3-ipaplatform-Move-Fedora-specific-implementations-of-.patch Type: text/x-patch Size: 11775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0212-3-ipaplatform-Change-platform-dependant-code-in-freeip.patch Type: text/x-patch Size: 18012 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0213-3-ipaplatform-Change-service-code-in-freeipa-to-use-ip.patch Type: text/x-patch Size: 45332 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0214-3-ipaplatform-Change-paths-dependant-on-ipaservices-to.patch Type: text/x-patch Size: 3705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0215-3-ipaplatform-Remove-redundant-imports-of-ipaservices.patch Type: text/x-patch Size: 16471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0216-3-ipaplatform-Move-all-filesystem-paths-to-ipaplatform.patch Type: text/x-patch Size: 158799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0217-3-ipaplatform-Remove-remnants-of-the-ipapython-platfor.patch Type: text/x-patch Size: 16172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0218-3-ipaplatform-Change-makefiles-to-accomodate-for-new-p.patch Type: text/x-patch Size: 9090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0219-3-ipaplatform-Let-fedora-path-module-use-PathNamespace.patch Type: text/x-patch Size: 882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0220-3-ipaplatform-Link-to-platform-module-during-build-tim.patch Type: text/x-patch Size: 1994 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0221-3-ipaplatform-Pylint-fixes.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0222-3-ipaplatform-Contain-all-the-tasks-in-the-TaskNamespa.patch Type: text/x-patch Size: 20846 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0223-2-ipaplatform-Move-hardcoded-paths-from-Fedora-platfor.patch Type: text/x-patch Size: 15736 bytes Desc: not available URL: From tbordaz at redhat.com Mon Jun 16 12:54:23 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 16 Jun 2014 14:54:23 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server Message-ID: <539EE8FF.2060000@redhat.com> Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Jun 16 12:57:00 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jun 2014 14:57:00 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <539ED57F.4070402@redhat.com> References: <52A0817E.2080002@redhat.com> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> Message-ID: <539EE99C.5010909@redhat.com> On 16.6.2014 13:31, Martin Kosek wrote: > On 06/11/2014 02:59 PM, Jan Cholasta wrote: >> On 11.6.2014 13:29, Martin Kosek wrote: >>> On 06/11/2014 10:58 AM, Jan Cholasta wrote: >>>> On 10.6.2014 09:55, Martin Kosek wrote: >>>>> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>>>>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>>>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>>>>> managedby_host >>>>>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>>>>> why that >>>>>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>>>>> original >>>>>>>>>>>> check is not right anymore ? >>>>>>>>>>> >>>>>>>>>>> The original check is wrong, see >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>>>>> handled by ACIs. >>>>>>>>>> >>>>>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>>>>> write the usercertificate. >>>>>>>>>> >>>>>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>>>>> >>>>>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>>>>> Certificates and kerberos keys". >>>>>>>>> >>>>>>>>> I think the check can be extended to users as well, so that requesting >>>>>>>>> certificate with SAN is allowed only to users which have write access to >>>>>>>>> the SAN services. >>>>>>> >>>>>>> I have done the modification, see attached patches. >>>>>>> >>>>>>>> >>>>>>>> Sounds good to me then, thanks for explaining. >>>>>>>> >>>>>>>> The patches also look good, but I would like someone to give them a try >>>>>>>> for a formal ack. >>>>>>> >>>>>>> OK, thanks. >>>>>>> >>>>>> >>>>>> Bump. >>>>>> >>>>>> I have added stricter validation of subject alt names as well as certificate >>>>>> extensions in general to the second patch. >>>>> >>>>> Thanks! >>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> Note that you will need python-nss 0.15 in order to test, you can get a >>>>>> RPM for >>>>>> Fedora here: . >>>>> >>>>> John, do you think we could build python-nss 0.15 also for Fedora 20? The fix >>>>> incorporated in it is pretty important to warrant bugfix update in bodhi. It >>>>> would also allow FreeIPA 4.0 to be installed on Fedora 20. >>>>> >>>>>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not >>>>>> work, >>>>>> because . >>>>> >>>>> This worked for me, I suspect this is a DS bug. More info in the ticket. >>>>> >>>>> Now back to review of the patch: >>>>> >>>>> 210.4: looks ok >>>>> 234.4: >>>>> >>>>> 1) Virtual operation "request certificate with subjectaltname" should be a >>>>> member of Certificate Administrators privilege >>>> >>>> OK. >>>> >>>>> >>>>> >>>>> 2) I would write "Request Certificate With SubjectAltName" with "with" instead >>>>> of "With". I.e.: >>>>> Request Certificate with SubjectAltName >>>> >>>> OK. >>>> >>>>> >>>>> >>>>> 3) Why is the extension check only enforced for non-hosts? >>>>> >>>>> + if not bind_principal.startswith('host/'): >>>>> + for ext in extensions: >>>>> + operation = self._allowed_extensions.get(ext) >>>>> + if operation: >>>>> + self.check_access(operation) >>>>> >>>>> My tricky certmonger request passed: >>>>> >>>>> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g >>>>> 2048 -r >>>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>>> test2.example.com >>>>> -E mkosek at redhat.com >>>>> >>>>> while when I posted the same CSR as privileged user, it was rejected: >>>>> >>>>> $ klist >>>>> Ticket cache: KEYRING:persistent:962000003:962000003 >>>>> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >>>>> >>>>> $ ipa cert-request --principal test/`hostname` certmonger.csr >>>>> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden >>>> >>>> Right, I meant to NACK myself, but you were faster. Fixed. >>>> >>>>> >>>>> >>>>> 4) Regular users cannot read Virtual Operations, so even if I assign them a >>>>> permission, command is refused: >>>>> >>>>> $ ipa cert-request --principal test/`hostname` openssl.csr >>>>> ipa: ERROR: Insufficient access: No such virtual command >>>>> >>>>> I think we will need to create new managed permission "Read Virtual >>>>> Operations" >>>>> and assign it to "Certificate Administrators" privilege by default as this >>>>> privilege has the virtual operation permissions assigned. Petr3, what is your >>>>> take on this? >>>>> >>>>> Otherwise the patch worked well for me, the authorization part looked OK. My >>>>> biggest concern was just the host/user differentiation wrt unknown >>>>> subjectaltname types. >>>>> >>>>> Martin >>>>> >>>> >>>> Updated patches attached. >>>> >>> >>> 1) I could not compile the patch set: >>> >>> $ make rpms >>> ... >>> if [ "" != "yes" ]; then \ >>> ./makeapi --validate; \ >>> ./makeaci --validate; \ >>> fi >>> Traceback (most recent call last): >>> File "./makeapi", line 457, in >>> sys.exit(main()) >>> File "./makeapi", line 428, in main >>> api.finalize() >>> File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize >>> self.__do_if_not_done('load_plugins') >>> File "/root/freeipa-master/ipalib/plugable.py", line 482, in __do_if_not_done >>> getattr(self, name)() >>> File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins >>> self.import_plugins('ipalib') >>> File "/root/freeipa-master/ipalib/plugable.py", line 689, in import_plugins >>> __import__(fullname) >>> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >>> from ipalib import pkcs10 >>> File "/root/freeipa-master/ipalib/pkcs10.py", line 77 >>> .replace('@', '\\@') >>> ... >>> >>> The rest of the notes are thus only from reading. >> >> Sorry, last minute change gone wrong. >> >>> >>> 2) There are lines like >>> >>> + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': >>> >>> >>> or >>> >>> + if name_type not in ('DNS name', >>> + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>> >>> or >>> >>> + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>> >>> Can we do something better? Getting the extension type based on it's >>> description seems extremely unstable to me. >> >> These are SAN types, not extension types. Unfortunately the textual >> descriptions are the only SAN type representation available in python-nss which >> includes OIDs of other names. >> >>> >>> Can we for example modify get_subjectaltname to get the type based on >>> CertificateExtension object's oid or oid_tag attributes? >> >> No, see above. >> >>> >>> I would rather see get_subjectaltname return solid type like >>> CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing >>> descriptions. It would be more readable, too. >> >> Done. >> >>> >>> Martin >>> >> >> Updated patches attached. > > 1) We still miss the managed permission allowing Certificate Administrators to > read Virtual Commands I was under the impression that Petr would fix this. > > > 2) Extension check > > Wouldn't > > if any(ext not in self._allowed_extensions for ext in extensions) > > be more readable than > > + for ext in extensions: > + if ext not in self._allowed_extensions: > + raise errors.ValidationError( > + name='csr', error=_("extension %s is forbidden") % ext) > > ? I don't think so. I don't see how cramming everything into one line makes anything more readable. > > 3) I find this part still not ideal: > > + for name_type, name in subjectaltname: > + if name_type not in (pkcs10.SAN_DNSNAME, > + pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, > + pkcs10.SAN_OTHERNAME_UPN): > + raise errors.ValidationError( > + name='csr', > + error=_("subject alt name type %s is forbidden") % > + name_type) > > > I still think we should instead: > - change get_subjectaltname's return value to tuples of: > - numeric type, i.e. SAN_DNSNAME,SAN_OTHERNAME_UPN or > SAN_OTHERNAME_KRB5PRINCIPALNAME > - content It already returns tuples like this. Using a numeric type instead of string for named constants does not improve anything. > - raise error when an unknown SAN type is detected This doesn't really fit with the rest of the pkcs10 module. > > This would: > a) Allow us to be sure that we do not miss any yet unknown SAN types or allow > us to catch the situation when name_type string changes > b) Allow more natural comparison of the SAN type "name_type == > pkcs10.SAN_DNSNAME" instead of "name_type in pkcs10.SAN_DNSNAME" The code already does all of this. There is no "name_type in pkcs10.SAN_DNSNAME". > > > 3) I am thinking why do we need to introduce all the ASN parsing? I am talking > about _decode_krb5principalname and others. If we do not use the result > anywhere, why should we include this part at all? To work around shortcomings of NSS/python-nss. In particular, _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. This is necessary because certmonger puts such SANs in certificate requests it generates. > > > 4) I get crash in the certmonger request: > > ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r > -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com > -E mkosek at redhat.com > > # ipa-getcert list -i test-san-1 > Number of certificates and requests being tracked: 8. > Request ID 'test-san-1': > status: CA_UNREACHABLE > ca-error: Server failed request, will retry: -504 (HTTP response code is 500, > not 200). > stuck: yes > > > HTTPD traceback > [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > Traceback (most recent call last): > [Mon Jun 16 13:06:14.528844 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/share/ipa/wsgi.py", line 49, in application > [Mon Jun 16 13:06:14.529466 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > return api.Backend.wsgi_dispatch(environ, start_response) > [Mon Jun 16 13:06:14.529614 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 251, in > __call__ > [Mon Jun 16 13:06:14.553116 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > return self.route(environ, start_response) > [Mon Jun 16 13:06:14.553261 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 263, in > route > [Mon Jun 16 13:06:14.553410 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > return app(environ, start_response) > [Mon Jun 16 13:06:14.553604 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 637, in > __call__ > [Mon Jun 16 13:06:14.553749 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > environ, start_response) > [Mon Jun 16 13:06:14.553895 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 397, in > __call__ > [Mon Jun 16 13:06:14.554023 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > response = self.wsgi_execute(environ) > [Mon Jun 16 13:06:14.554138 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in > wsgi_execute > [Mon Jun 16 13:06:14.554276 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > result = self.Command[name](*args, **options) > [Mon Jun 16 13:06:14.554413 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ > [Mon Jun 16 13:06:14.585933 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > ret = self.run(*args, **options) > [Mon Jun 16 13:06:14.586170 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run > [Mon Jun 16 13:06:14.586305 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > return self.execute(*args, **options) > [Mon Jun 16 13:06:14.586490 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 316, in > execute > [Mon Jun 16 13:06:14.592390 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > subjectaltname = pkcs10.get_subjectaltname(csr) or () > [Mon Jun 16 13:06:14.592565 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/ipalib/pkcs10.py", line 129, in > get_subjectaltname > [Mon Jun 16 13:06:14.596411 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > san = decoder.decode(san, asn1Spec=_SubjectAltName())[0] > [Mon Jun 16 13:06:14.596555 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line > 792, in __call__ > [Mon Jun 16 13:06:14.598268 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > stGetValueDecoder, self, substrateFun > [Mon Jun 16 13:06:14.598404 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line > 367, in valueDecoder > [Mon Jun 16 13:06:14.598534 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > component, head = decodeFun(head, asn1Spec) > [Mon Jun 16 13:06:14.598633 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line > 798, in __call__ > [Mon Jun 16 13:06:14.598746 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > '%r not in asn1Spec: %r' % (tagSet, asn1Spec) > [Mon Jun 16 13:06:14.598954 2014] [:error] [pid 12941] [remote 10.34.47.236:12] > PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: > _GeneralName() What version of certmonger are you using? > > > Martin > -- Jan Cholasta From rcritten at redhat.com Mon Jun 16 13:04:07 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jun 2014 09:04:07 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <539EE8FF.2060000@redhat.com> References: <539EE8FF.2060000@redhat.com> Message-ID: <539EEB47.3030901@redhat.com> thierry bordaz wrote: > Hello, > > When a stage user is activate (ipa stageuse-activate), UUID plugin > (DS) checks that the ipaUniqueID value of the new active user is > 'autogenerate'. > This is useful to prevent a provisioning systems to create Active > user with invalid ipaUniqueID. > Now one of the workflow step is to move a Delete user into the Stage > container. In that case the Stage entry contains a ipaUniqueID and > can not activate. > > A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' > during that step but I wonder it it is valid to reset it. > Also, is it valid to reset it and keep others values like > uidNumber/gidNumber ? I guess to walk through the logic, the unique id is there so we can uniquely address an entry without worrying about the value changing (like uid, name, etc). So if it is a brand new entry from the provisioning system, yeah, we want to always set it to autogenerate. If a user is deleted I think we agreed that all links to that user would be broken (memberships, hbac rules, etc) which means that it doesn't matter if the unique id is changed I suppose. IMHO uidnumber/gidnumber should always be maintained. rob From jcholast at redhat.com Mon Jun 16 13:35:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 16 Jun 2014 15:35:29 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate Message-ID: <539EF2A1.6060706@redhat.com> Hi, the attached patches implement . My patches 241-253 and 262-294 are required for this (, ). The installation/testing guidelines from apply here as well. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 6249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3067 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 14111 bytes Desc: not available URL: From simo at redhat.com Mon Jun 16 13:34:50 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Jun 2014 09:34:50 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <539EA290.5020604@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539EA290.5020604@redhat.com> Message-ID: <1402925690.22737.107.camel@willson.usersys.redhat.com> On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote: > On 06/13/2014 10:20 PM, Simo Sorce wrote: > [...] > > 2) and I think this is a MUCH bigger issue, the Admin users are > > unbounded and pass any Access Control Check and this means they can now > > retrieve any key for users or machines. > > It is already bad enough that admins can unconditionally set any key, > > but this at least leaves back a pretty big trail (the original client > > password/key fails to work), and is a necessary evil (password resets, > > hosts creation/recovery). > > But I am not very comfortable with the idea an admin can retrieve any > > key without actually ending up changing it. Petr do we have any short > > term plan to address the Admin's super ACI ? > > No, nothing in the short term. Ok, then I think attached is the patch 0003 we want. This changes admins superpowers to not allow ipaProtectedOperation by default and instead adds a specific right in cn=accounts so admin can keep fetching keytabs for any principal. We may want to turn this into a permission with a future patch. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 32176 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 16 13:44:32 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 16 Jun 2014 15:44:32 +0200 Subject: [Freeipa-devel] [PATCH] 655 webui: move RPC result extraction logic to Adapter In-Reply-To: <53999FD6.6060600@redhat.com> References: <53985418.9050700@redhat.com> <53999FD6.6060600@redhat.com> Message-ID: <539EF4C0.4030104@redhat.com> On 12.6.2014 14:40, Endi Sukma Dewata wrote: > On 6/11/2014 8:05 AM, Petr Vobornik wrote: >> It enables declarative extraction of values from partial >> results of a batch commands and also further extensibility >> in custom adapters. >> >> The default adapter has detection logic for this extraction so >> it can use bare record or extract data from normal or batch RPC >> command. >> >> Minor change of user plugin fixed: >> https://fedorahosted.org/freeipa/ticket/4355 > > ACK. > Pushed to master: 5a428608beb3752b111b558ba2355ef112a057f1 -- Petr Vobornik From pvoborni at redhat.com Mon Jun 16 13:51:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 16 Jun 2014 15:51:03 +0200 Subject: [Freeipa-devel] [PATCH] 546 webui: expose krbprincipalexpiration In-Reply-To: <53999FA2.8020209@redhat.com> References: <530CCDCB.6000009@redhat.com> <53999FA2.8020209@redhat.com> Message-ID: <539EF647.2000404@redhat.com> On 12.6.2014 14:40, Endi Sukma Dewata wrote: > On 2/25/2014 11:07 AM, Petr Vobornik wrote: >> Depends on tbabej's patches # 137, 138 and my 546. >> >> https://fedorahosted.org/freeipa/ticket/3306 > > ACK on #547. > Pushed to master: 4de9c5fc51c1e9a07a23b430ba531eb096960732 -- Petr Vobornik From mkosek at redhat.com Mon Jun 16 14:08:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Jun 2014 16:08:36 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <539EE99C.5010909@redhat.com> References: <52A0817E.2080002@redhat.com> <52CE6310.6030009@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> <539EE99C.5010909@redhat.com> Message-ID: <539EFA64.3020005@redhat.com> On 06/16/2014 02:57 PM, Jan Cholasta wrote: > On 16.6.2014 13:31, Martin Kosek wrote: >> On 06/11/2014 02:59 PM, Jan Cholasta wrote: >>> On 11.6.2014 13:29, Martin Kosek wrote: >>>> On 06/11/2014 10:58 AM, Jan Cholasta wrote: >>>>> On 10.6.2014 09:55, Martin Kosek wrote: >>>>>> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>>>>>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>>>>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>>>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>>>>>> managedby_host >>>>>>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>>>>>> why that >>>>>>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>>>>>> original >>>>>>>>>>>>> check is not right anymore ? >>>>>>>>>>>> >>>>>>>>>>>> The original check is wrong, see >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>>>>>> handled by ACIs. >>>>>>>>>>> >>>>>>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>>>>>> write the usercertificate. >>>>>>>>>>> >>>>>>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>>>>>> >>>>>>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>>>>>> Certificates and kerberos keys". >>>>>>>>>> >>>>>>>>>> I think the check can be extended to users as well, so that requesting >>>>>>>>>> certificate with SAN is allowed only to users which have write access to >>>>>>>>>> the SAN services. >>>>>>>> >>>>>>>> I have done the modification, see attached patches. >>>>>>>> >>>>>>>>> >>>>>>>>> Sounds good to me then, thanks for explaining. >>>>>>>>> >>>>>>>>> The patches also look good, but I would like someone to give them a try >>>>>>>>> for a formal ack. >>>>>>>> >>>>>>>> OK, thanks. >>>>>>>> >>>>>>> >>>>>>> Bump. >>>>>>> >>>>>>> I have added stricter validation of subject alt names as well as >>>>>>> certificate >>>>>>> extensions in general to the second patch. >>>>>> >>>>>> Thanks! >>>>>> >>>>>>> Updated patches attached. >>>>>>> >>>>>>> Note that you will need python-nss 0.15 in order to test, you can get a >>>>>>> RPM for >>>>>>> Fedora here: . >>>>>> >>>>>> John, do you think we could build python-nss 0.15 also for Fedora 20? The >>>>>> fix >>>>>> incorporated in it is pretty important to warrant bugfix update in bodhi. It >>>>>> would also allow FreeIPA 4.0 to be installed on Fedora 20. >>>>>> >>>>>>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not >>>>>>> work, >>>>>>> because . >>>>>> >>>>>> This worked for me, I suspect this is a DS bug. More info in the ticket. >>>>>> >>>>>> Now back to review of the patch: >>>>>> >>>>>> 210.4: looks ok >>>>>> 234.4: >>>>>> >>>>>> 1) Virtual operation "request certificate with subjectaltname" should be a >>>>>> member of Certificate Administrators privilege >>>>> >>>>> OK. >>>>> >>>>>> >>>>>> >>>>>> 2) I would write "Request Certificate With SubjectAltName" with "with" >>>>>> instead >>>>>> of "With". I.e.: >>>>>> Request Certificate with SubjectAltName >>>>> >>>>> OK. >>>>> >>>>>> >>>>>> >>>>>> 3) Why is the extension check only enforced for non-hosts? >>>>>> >>>>>> + if not bind_principal.startswith('host/'): >>>>>> + for ext in extensions: >>>>>> + operation = self._allowed_extensions.get(ext) >>>>>> + if operation: >>>>>> + self.check_access(operation) >>>>>> >>>>>> My tricky certmonger request passed: >>>>>> >>>>>> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g >>>>>> 2048 -r >>>>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>>>> test2.example.com >>>>>> -E mkosek at redhat.com >>>>>> >>>>>> while when I posted the same CSR as privileged user, it was rejected: >>>>>> >>>>>> $ klist >>>>>> Ticket cache: KEYRING:persistent:962000003:962000003 >>>>>> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>> >>>>>> $ ipa cert-request --principal test/`hostname` certmonger.csr >>>>>> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden >>>>> >>>>> Right, I meant to NACK myself, but you were faster. Fixed. >>>>> >>>>>> >>>>>> >>>>>> 4) Regular users cannot read Virtual Operations, so even if I assign them a >>>>>> permission, command is refused: >>>>>> >>>>>> $ ipa cert-request --principal test/`hostname` openssl.csr >>>>>> ipa: ERROR: Insufficient access: No such virtual command >>>>>> >>>>>> I think we will need to create new managed permission "Read Virtual >>>>>> Operations" >>>>>> and assign it to "Certificate Administrators" privilege by default as this >>>>>> privilege has the virtual operation permissions assigned. Petr3, what is >>>>>> your >>>>>> take on this? >>>>>> >>>>>> Otherwise the patch worked well for me, the authorization part looked OK. My >>>>>> biggest concern was just the host/user differentiation wrt unknown >>>>>> subjectaltname types. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> Updated patches attached. >>>>> >>>> >>>> 1) I could not compile the patch set: >>>> >>>> $ make rpms >>>> ... >>>> if [ "" != "yes" ]; then \ >>>> ./makeapi --validate; \ >>>> ./makeaci --validate; \ >>>> fi >>>> Traceback (most recent call last): >>>> File "./makeapi", line 457, in >>>> sys.exit(main()) >>>> File "./makeapi", line 428, in main >>>> api.finalize() >>>> File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize >>>> self.__do_if_not_done('load_plugins') >>>> File "/root/freeipa-master/ipalib/plugable.py", line 482, in >>>> __do_if_not_done >>>> getattr(self, name)() >>>> File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins >>>> self.import_plugins('ipalib') >>>> File "/root/freeipa-master/ipalib/plugable.py", line 689, in >>>> import_plugins >>>> __import__(fullname) >>>> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >>>> from ipalib import pkcs10 >>>> File "/root/freeipa-master/ipalib/pkcs10.py", line 77 >>>> .replace('@', '\\@') >>>> ... >>>> >>>> The rest of the notes are thus only from reading. >>> >>> Sorry, last minute change gone wrong. >>> >>>> >>>> 2) There are lines like >>>> >>>> + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': >>>> >>>> >>>> or >>>> >>>> + if name_type not in ('DNS name', >>>> + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>>> >>>> or >>>> >>>> + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>>> >>>> Can we do something better? Getting the extension type based on it's >>>> description seems extremely unstable to me. >>> >>> These are SAN types, not extension types. Unfortunately the textual >>> descriptions are the only SAN type representation available in python-nss which >>> includes OIDs of other names. >>> >>>> >>>> Can we for example modify get_subjectaltname to get the type based on >>>> CertificateExtension object's oid or oid_tag attributes? >>> >>> No, see above. >>> >>>> >>>> I would rather see get_subjectaltname return solid type like >>>> CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing >>>> descriptions. It would be more readable, too. >>> >>> Done. >>> >>>> >>>> Martin >>>> >>> >>> Updated patches attached. >> >> 1) We still miss the managed permission allowing Certificate Administrators to >> read Virtual Commands > > I was under the impression that Petr would fix this. Previously I was asking for consultancy, new managed permissions should make it much easier to add new ACIs, so I think you should be able to do it. If not, you can ask Petr for help. ... >> 3) I am thinking why do we need to introduce all the ASN parsing? I am talking >> about _decode_krb5principalname and others. If we do not use the result >> anywhere, why should we include this part at all? > > To work around shortcomings of NSS/python-nss. In particular, > _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. > This is necessary because certmonger puts such SANs in certificate requests it > generates. I know, but we do not use the values besides DNS SAN type, right? I was just afraid that a decode error in a decoding of an unused SAN type would cause the entire CSR processing to crash. >> 4) I get crash in the certmonger request: >> >> ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com >> -E mkosek at redhat.com >> >> # ipa-getcert list -i test-san-1 >> Number of certificates and requests being tracked: 8. >> Request ID 'test-san-1': >> status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: -504 (HTTP response code is >> 500, >> not 200). >> stuck: yes >> >> >> HTTPD traceback >> [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> Traceback (most recent call last): >> [Mon Jun 16 13:06:14.528844 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/share/ipa/wsgi.py", line 49, in application >> [Mon Jun 16 13:06:14.529466 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> return api.Backend.wsgi_dispatch(environ, start_response) >> [Mon Jun 16 13:06:14.529614 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 251, in >> __call__ >> [Mon Jun 16 13:06:14.553116 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> return self.route(environ, start_response) >> [Mon Jun 16 13:06:14.553261 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 263, in >> route >> [Mon Jun 16 13:06:14.553410 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> return app(environ, start_response) >> [Mon Jun 16 13:06:14.553604 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 637, in >> __call__ >> [Mon Jun 16 13:06:14.553749 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> environ, start_response) >> [Mon Jun 16 13:06:14.553895 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 397, in >> __call__ >> [Mon Jun 16 13:06:14.554023 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> response = self.wsgi_execute(environ) >> [Mon Jun 16 13:06:14.554138 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in >> wsgi_execute >> [Mon Jun 16 13:06:14.554276 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> result = self.Command[name](*args, **options) >> [Mon Jun 16 13:06:14.554413 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in >> __call__ >> [Mon Jun 16 13:06:14.585933 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> ret = self.run(*args, **options) >> [Mon Jun 16 13:06:14.586170 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run >> [Mon Jun 16 13:06:14.586305 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> return self.execute(*args, **options) >> [Mon Jun 16 13:06:14.586490 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 316, in >> execute >> [Mon Jun 16 13:06:14.592390 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> subjectaltname = pkcs10.get_subjectaltname(csr) or () >> [Mon Jun 16 13:06:14.592565 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/ipalib/pkcs10.py", line 129, in >> get_subjectaltname >> [Mon Jun 16 13:06:14.596411 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> san = decoder.decode(san, asn1Spec=_SubjectAltName())[0] >> [Mon Jun 16 13:06:14.596555 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >> 792, in __call__ >> [Mon Jun 16 13:06:14.598268 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> stGetValueDecoder, self, substrateFun >> [Mon Jun 16 13:06:14.598404 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >> 367, in valueDecoder >> [Mon Jun 16 13:06:14.598534 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> component, head = decodeFun(head, asn1Spec) >> [Mon Jun 16 13:06:14.598633 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >> 798, in __call__ >> [Mon Jun 16 13:06:14.598746 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> '%r not in asn1Spec: %r' % (tagSet, asn1Spec) >> [Mon Jun 16 13:06:14.598954 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >> PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: >> _GeneralName() > > What version of certmonger are you using? Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access to my VM atm). Is this a bug in certmonger? I would like FreeIPA 4.0 to run on vanilla Fedora 20, so far it does, the required python-nss 0.15 is already on it's way to stable updates. Thanks, Martin From rcritten at redhat.com Mon Jun 16 14:56:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jun 2014 10:56:19 -0400 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <5399E749.6070806@redhat.com> References: <5399E749.6070806@redhat.com> Message-ID: <539F0593.9060007@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patches implement > and > . > > This work depends on my patches 241-253 and 262-266 > (). > > Note that automatic distribution of CA certificates to IPA systems is > not implemented yet (it's planned for IPA 4.2, see > ), so /etc/ipa/ca.crt, > /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated > *only* during client/server install. 267 What is the purpose of this change? Won't this cause no certificates to be exported in the default case? diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py index 61a954f..3cd7a53 100644 --- a/ipaserver/install/certs.py +++ b/ipaserver/install/certs.py @@ -463,7 +463,7 @@ class CertDB(object): do that step.""" # export the CA cert for use with other apps ipautil.backup_file(self.cacert_fname) - root_nicknames = self.find_root_cert(nickname) + root_nicknames = self.find_root_cert(nickname)[:-1] fd = open(self.cacert_fname, "w") for root in root_nicknames: (cert, stderr, returncode) = self.run_certutil(["-L", "-n", root, "-a"]) Or are you separating out issuing CA from the rest of the chain? 268 ACK 269 ACK 270 If a user has their own CA installed, such as the case where they used ipa-server-certinstall, this will break it. What can be in the other set? Docs are needed. You potentially add a bunch of certs with no trust, what is the purpose? 271 ipaSecretKey isn't mentioned on http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and does it need to be added now? 272 ACK 273 ACK 274 ACK 275 ACK 276 There isn't any error handling around the ASN.1 decoder. Is that wise? There should be unit tests 277 There should be unit tests 278 When the certificate must be passed in as DER can you use dercert as the argument name so it's clear what is needed? In update_ca_cert() and get_ca_certs() should the values for trust be case insensitive? This breaks the convention where attribute names are always lower-case. I can't really grok add_ca_cert(). You are adding certs but removing values? Is this un-setting the list of trusted CA's maybe? There isn't a single comment in this file beyond the header. 279 Looks ok 280 Why add the chain with no trust? 281 / 282 What is the difference between add_cert and import_cert other than passing in trust and not having the db password? Do we even need add_single_pem_cert anymore? 283 / 284 In __import_ca_certs() I assume the pass is there for NotFound for the case of creating a replica with an older master that doesn't have these? How is SSL trust setup then? This code looks awfully similar. 285 ACK 286 It looks ok, just one wild thought. If writing the certificate fails and you go to clean up by removing ca_file, what if that removal fails, for the same reason the write failed, SELinux for example? 287 If this weren't addressed in a later patch I've have dinged you on the: + return [cert] There are some places where you pluralize the variables (certs) and others where you do not (ca_cert, existing_ca_cert). 288 Is a rawcert a dercert? I'd use that name instead for consistency. normalize_certificate() can raise exceptions. Those should be handled in write_certificate_list() 289 ACK 290 This can be dangerous because if another database is opened in the process things may fail. Additional warnings and red flags should be provided, or the context should be compared to known places this will blow up (e.g server). 291 You use a temporary database to make cleanup easier I suppose? Did you test this in enforcing? 292 Need unit tests 293 Why the fixme for the x509 import? Isn't this changing already published API for [insert|remove]_ca_cert_into_systemwide_ca_store? 294 Can you change the old occurances of cafile = config.dir + "/ca.crt" to use CACERT instead? Bad case in exception, "Ca cert file is not available". Is there any additional information we can provide, like what to do about it and where we looked? You actually remove one occurrence of CACERT and replace it with a hardcoded path, is that on purpose? --- I still need to do functional testing and will probably take another pass the changes through but this patchset generally looks ok. rob From simo at redhat.com Mon Jun 16 15:34:30 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Jun 2014 11:34:30 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval Message-ID: <1402932870.22737.113.camel@willson.usersys.redhat.com> Although the code is all done it would be nice to have a review of the feature, to see if it has all been captured: http://www.freeipa.org/page/V4/Keytab_Retrieval Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Jun 16 15:43:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 17:43:50 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <539B17D6.6040908@redhat.com> References: <539B17D6.6040908@redhat.com> Message-ID: <539F10B6.80507@redhat.com> On 06/13/2014 05:25 PM, Petr Viktorin wrote: > > With the first patch, old SYSTEM permissions can be replaced. The "Read > DNS Entries" did not have an associated ACI, but was rather rolled into > a single ACI with the managedBy rule used for per-zone access. > (and before that it was part of a deny rule.) > We can't remove this permission in an update file, because we need to > check that it is indeed an old SYSTEM perm and not a new one with the > same name. > > > The second patch converts DNS permissions to managed. > > The ACIs are put directly in $SUFFIX, because the cn=dns subtree does > not exist in all installations. > > I hope to change this for https://fedorahosted.org/freeipa/ticket/4058, > when I've thought more about relationships between plugins, packages, > install options, and the updater. Testing more, I found a benign bug: the updater complained if the cn=dns container was missing. Fixed here. Also, the update_dns_permissions plugin is now now obsolete, the third patch removes it. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0583.2-managed-permission-updater-Add-mechanism-to-replace-.patch Type: text/x-patch Size: 2880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0584.2-Convert-DNS-default-permissions-to-managed.patch Type: text/x-patch Size: 30371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0588.2-Remove-the-update_dns_permissions-plugin.patch Type: text/x-patch Size: 4219 bytes Desc: not available URL: From npmccallum at redhat.com Mon Jun 16 16:23:07 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 16 Jun 2014 12:23:07 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402697149.22737.85.camel@willson.usersys.redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> <1402697149.22737.85.camel@willson.usersys.redhat.com> Message-ID: <1402935787.4273.18.camel@ipa.example.com> On Fri, 2014-06-13 at 18:05 -0400, Simo Sorce wrote: > On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: > > I am CC'ing Simo because he wants to review my PBKDF2 implementation. > > Thank you. > I am a bit concerned you are using etree.parse(self.args[0]) directly > with the default parser configuration. > > I think we should, at least, do something like this: > parser = etree.XMLParser(resolve_entities=False) > parser.parse(self.args[0]) > > We wouldn't want to inadvertently hit the network when reading this xml > file, would we ? Argh. Yes. Thanks for this. > Reading the PBKDF2KeyDerivation code I see no particular issue, although > I found it a bit hard to decod what it was doing as there are no > comments, nor a direct reference to the algorithm you are implementing. > > It would be nice to have comments either before the function or within > the function that gives an explanation of the algorithm being > implemented so that whoever needs to read this in the future can readily > understand what is going on. > I've used this as reference to refresh my memory on the algorithm: > http://en.wikipedia.org/wiki/PBKDF2 There is only one PBKDF2 with differing PRFs. This is precisely what is implemented. However, I'm still working with jdennis to see if I can coax python-nss to do this for me. I'm happy to delete my own implementation. > Btw for the final join, wouldn't it be more compact to use: > dk += ''.join(map(chr,u)) ? My understanding is that comprehensions are now preferred. I know reduce() has been removed in Python 3.x. However, map() still appears to be there. Does anyone have the official word on the preferred style? > Actually this creates a new string at each iteration... > if you declare dk = [] before the loop and dk.append(''.join(map(chr, > u))) in the loop. > Then you can return ''.join(dk)[:self.klen] and build the final string > only once. > > Or given you already use lambdas in there perhaps simplify even to: > > dk = [] > for i ... > ... > dk.append(u) > > return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] Sounds good. Let's see if nss can do this. If not, I'll clean this up. > In general the flow is a bit hard to follow due to the clever use of > map(), maybe a few comments sprinkled before functions about who/how is > meant to use them would help the casual observer. In general, this kind of complexity is reduced somewhat in Python 3.x's new bytes/str division. I have a bytes subclass for Py3k that I like to use which implements the bitwise operators. I've even had ideas about submitting this as an upstream Python patch for the bytes class. > Other than the first point though, anything else looks good to me. Thanks for looking at this! Nathaniel From pviktori at redhat.com Mon Jun 16 17:39:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 19:39:13 +0200 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1402935787.4273.18.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> <1402697149.22737.85.camel@willson.usersys.redhat.com> <1402935787.4273.18.camel@ipa.example.com> Message-ID: <539F2BC1.8090804@redhat.com> On 06/16/2014 06:23 PM, Nathaniel McCallum wrote: > On Fri, 2014-06-13 at 18:05 -0400, Simo Sorce wrote: >> On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: >>> I am CC'ing Simo because he wants to review my PBKDF2 implementation. >> >> Thank you. >> I am a bit concerned you are using etree.parse(self.args[0]) directly >> with the default parser configuration. >> >> I think we should, at least, do something like this: >> parser = etree.XMLParser(resolve_entities=False) >> parser.parse(self.args[0]) >> >> We wouldn't want to inadvertently hit the network when reading this xml >> file, would we ? > > Argh. Yes. Thanks for this. lxml.etree.XMLParser has a separate option for this, no_network, which is True by default. >> Reading the PBKDF2KeyDerivation code I see no particular issue, although >> I found it a bit hard to decod what it was doing as there are no >> comments, nor a direct reference to the algorithm you are implementing. >> >> It would be nice to have comments either before the function or within >> the function that gives an explanation of the algorithm being >> implemented so that whoever needs to read this in the future can readily >> understand what is going on. >> I've used this as reference to refresh my memory on the algorithm: >> http://en.wikipedia.org/wiki/PBKDF2 > > There is only one PBKDF2 with differing PRFs. This is precisely what is > implemented. However, I'm still working with jdennis to see if I can > coax python-nss to do this for me. I'm happy to delete my own > implementation. > >> Btw for the final join, wouldn't it be more compact to use: >> dk += ''.join(map(chr,u)) ? > > My understanding is that comprehensions are now preferred. I know > reduce() has been removed in Python 3.x. However, map() still appears to > be there. Does anyone have the official word on the preferred style? Here's my view, strictly unofficial: Comprehensions are better in almost all cases. This (converting each value) is just about the only one where map is more concise, and roughly equally readable. So, for consistency, it's better to use comprehensions everywhere. >> Actually this creates a new string at each iteration... >> if you declare dk = [] before the loop and dk.append(''.join(map(chr, >> u))) in the loop. >> Then you can return ''.join(dk)[:self.klen] and build the final string >> only once. >> >> Or given you already use lambdas in there perhaps simplify even to: >> >> dk = [] >> for i ... >> ... >> dk.append(u) >> >> return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] > > Sounds good. Let's see if nss can do this. If not, I'll clean this up. > >> In general the flow is a bit hard to follow due to the clever use of >> map(), maybe a few comments sprinkled before functions about who/how is >> meant to use them would help the casual observer. > > In general, this kind of complexity is reduced somewhat in Python 3.x's > new bytes/str division. I have a bytes subclass for Py3k that I like to > use which implements the bitwise operators. I've even had ideas about > submitting this as an upstream Python patch for the bytes class. Try the python-ideas list first. There's a recent thread there from Nick Coghlan on a similar topic, you might want to read it. -- Petr? From npmccallum at redhat.com Mon Jun 16 17:50:28 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 16 Jun 2014 13:50:28 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <20140616085336.GB6321@redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1399999226.2512.10.camel@ipa.example.com> <53984A8D.9070508@redhat.com> <1402522909.2955.26.camel@ipa.example.com> <1402688360.4273.6.camel@ipa.example.com> <1402697149.22737.85.camel@willson.usersys.redhat.com> <20140616085336.GB6321@redhat.com> Message-ID: <1402941028.4273.24.camel@ipa.example.com> On Mon, 2014-06-16 at 11:53 +0300, Alexander Bokovoy wrote: > On Fri, 13 Jun 2014, Simo Sorce wrote: > >On Fri, 2014-06-13 at 15:39 -0400, Nathaniel McCallum wrote: > >> I am CC'ing Simo because he wants to review my PBKDF2 implementation. > > > >Thank you. > >I am a bit concerned you are using etree.parse(self.args[0]) directly > >with the default parser configuration. > > > >I think we should, at least, do something like this: > >parser = etree.XMLParser(resolve_entities=False) > >parser.parse(self.args[0]) > > > >We wouldn't want to inadvertently hit the network when reading this xml > >file, would we ? > > > > > >Reading the PBKDF2KeyDerivation code I see no particular issue, although > >I found it a bit hard to decod what it was doing as there are no > >comments, nor a direct reference to the algorithm you are implementing. > > > >It would be nice to have comments either before the function or within > >the function that gives an explanation of the algorithm being > >implemented so that whoever needs to read this in the future can readily > >understand what is going on. > >I've used this as reference to refresh my memory on the algorithm: > >http://en.wikipedia.org/wiki/PBKDF2 > > > >Btw for the final join, wouldn't it be more compact to use: > >dk += ''.join(map(chr,u)) ? > > > >Actually this creates a new string at each iteration... > >if you declare dk = [] before the loop and dk.append(''.join(map(chr, > >u))) in the loop. > >Then you can return ''.join(dk)[:self.klen] and build the final string > >only once. > > > >Or given you already use lambdas in there perhaps simplify even to: > > > >dk = [] > >for i ... > > ... > > dk.append(u) > > > >return ''.join(map(lambda x: ''.join(map(chr, x)), dk))[:self.klen] > > > > > >In general the flow is a bit hard to follow due to the clever use of > >map(), maybe a few comments sprinkled before functions about who/how is > >meant to use them would help the casual observer. > > > >Other than the first point though, anything else looks good to me. > I read through the patch and apart from the points Simo made, I don't > have much complaints. One additional thing to do is how to test it -- > how to create the payload? Since this code doesn't require anything > specific, it could be well tested through a CI infrastructure. I don't see why we can't use the samples that jcholast dug up as test data since they come from the RFC. The noted fix for Figure 7 should be included so that the test works. > Additionally, man page is missing. The man page should be in 0053.2. From pviktori at redhat.com Mon Jun 16 17:50:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Jun 2014 19:50:55 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <539EE8B6.7010003@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> Message-ID: <539F2E7F.2010600@redhat.com> On 06/16/2014 02:53 PM, Tomas Babej wrote: > On 06/10/2014 05:07 PM, Petr Viktorin wrote: >> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> the following set of patches implements the ticket: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>> >> [...] >>>>> 0202: OK 0203: OK 0204: OK 0205: OK 0206: OK 0207: OK (sorry for the conflict!) 0208: OK 0209: OK 0210: OK 0211: OK 0212: OK 0213: OK 0214: OK 0215: OK 0216: OK 0217: OK 0218: OK 0219: OK 0220: OK 0221: OK 0222: OK modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` argument. Rebasing this all the time must be painful, so to avoid another review round-trip I've had Tom?? ACK the attached four-liner on IRC. 0223: OK ACK to the above with my fix, but see more comments below. Pushed to master: d868fc5566da547d2060ef4a42eb5a0d0e0a72d6 0224: insert_ca_cert_into_systemwide_ca_store remove_ca_cert_from_systemwide_ca_store typo: certificated restore_pre_ipa_client_configuration mentions obsolete tasks Additional: Is tasks.get_svc_list_file necessary? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0588-Fix-self-argument-in-tasks.patch Type: text/x-patch Size: 1948 bytes Desc: not available URL: From rcritten at redhat.com Mon Jun 16 20:36:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jun 2014 16:36:34 -0400 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <539F0593.9060007@redhat.com> References: <5399E749.6070806@redhat.com> <539F0593.9060007@redhat.com> Message-ID: <539F5552.9070005@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> the attached patches implement >> and >> . >> >> This work depends on my patches 241-253 and 262-266 >> (). >> >> Note that automatic distribution of CA certificates to IPA systems is >> not implemented yet (it's planned for IPA 4.2, see >> ), so /etc/ipa/ca.crt, >> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated >> *only* during client/server install. > > 267 > > What is the purpose of this change? Won't this cause no certificates to > be exported in the default case? > > diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py > index 61a954f..3cd7a53 100644 > --- a/ipaserver/install/certs.py > +++ b/ipaserver/install/certs.py > @@ -463,7 +463,7 @@ class CertDB(object): > do that step.""" > # export the CA cert for use with other apps > ipautil.backup_file(self.cacert_fname) > - root_nicknames = self.find_root_cert(nickname) > + root_nicknames = self.find_root_cert(nickname)[:-1] > fd = open(self.cacert_fname, "w") > for root in root_nicknames: > (cert, stderr, returncode) = self.run_certutil(["-L", "-n", > root, "-a"]) > > Or are you separating out issuing CA from the rest of the chain? > > 268 ACK > > 269 ACK > > 270 > > If a user has their own CA installed, such as the case where they used > ipa-server-certinstall, this will break it. > > What can be in the other set? Docs are needed. > > You potentially add a bunch of certs with no trust, what is the purpose? > > 271 > > ipaSecretKey isn't mentioned on > http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and > does it need to be added now? > > 272 ACK > > 273 ACK > > 274 ACK > > 275 ACK > > 276 > > There isn't any error handling around the ASN.1 decoder. Is that wise? > > There should be unit tests > > 277 > > There should be unit tests > > 278 > > When the certificate must be passed in as DER can you use dercert as the > argument name so it's clear what is needed? > > In update_ca_cert() and get_ca_certs() should the values for trust be > case insensitive? > > This breaks the convention where attribute names are always lower-case. > > I can't really grok add_ca_cert(). You are adding certs but removing > values? Is this un-setting the list of trusted CA's maybe? > > There isn't a single comment in this file beyond the header. > > 279 > > Looks ok > > 280 > > Why add the chain with no trust? > > 281 / 282 > > What is the difference between add_cert and import_cert other than > passing in trust and not having the db password? Do we even need > add_single_pem_cert anymore? > > 283 / 284 > > In __import_ca_certs() I assume the pass is there for NotFound for the > case of creating a replica with an older master that doesn't have these? > How is SSL trust setup then? > > This code looks awfully similar. > > 285 > > ACK > > 286 > > It looks ok, just one wild thought. If writing the certificate fails and > you go to clean up by removing ca_file, what if that removal fails, for > the same reason the write failed, SELinux for example? > > 287 > > If this weren't addressed in a later patch I've have dinged you on the: > > + return [cert] > > There are some places where you pluralize the variables (certs) and > others where you do not (ca_cert, existing_ca_cert). > > 288 > > Is a rawcert a dercert? I'd use that name instead for consistency. > > normalize_certificate() can raise exceptions. Those should be handled in > write_certificate_list() > > 289 > > ACK > > 290 > > This can be dangerous because if another database is opened in the > process things may fail. Additional warnings and red flags should be > provided, or the context should be compared to known places this will > blow up (e.g server). > > 291 > > You use a temporary database to make cleanup easier I suppose? Did you > test this in enforcing? > > 292 > > Need unit tests > > 293 > > Why the fixme for the x509 import? > > Isn't this changing already published API for > [insert|remove]_ca_cert_into_systemwide_ca_store? > > 294 > > Can you change the old occurances of > > cafile = config.dir + "/ca.crt" > > to use CACERT instead? > > Bad case in exception, "Ca cert file is not available". Is there any > additional information we can provide, like what to do about it and > where we looked? > > You actually remove one occurrence of CACERT and replace it with a > hardcoded path, is that on purpose? > > --- > > I still need to do functional testing and will probably take another > pass the changes through but this patchset generally looks ok. Several issues found during testing: 1. Enrollment from RHEL-5 fails because the entire cert chain is not retrieved, only the issuing CA cert. Joining realm failed: libcurl failed to execute the HTTP POST transaction. SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Installation failed. Rolling back changes. 2. Not quite sure the cause, but this is on a replica: # ldapsearch -x -Z p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension ldap_start_tls: Operations error (1) additional info: SSL connection already established. # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: (objectclass=*) Same command on initial master doesn't spit out the p11-kit errors. Get similar errors out of certutil: # certutil -L -d /etc/httpd/alias p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension p11-kit: invalid basic constraints certificate extension Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI GREYOAK.COM IPA CA CT,C,C Server-Cert u,u,u CN=External Authority ,, ipaCert u,u,u Same version of p11-kit on both machines. p11-kit-trust-0.20.2-1.fc20.x86_64 p11-kit-0.20.2-1.fc20.x86_64 3. On uninstall the CA's are not removed from /etc/pki/nssdb and /etc/httpd/alias in one of my tests (the first one, so I no longer have the logs). 4. This one isn't your issue AFAICT, not sure if you've seen this one: # ipa-ca-install ... [snip] 2014-06-16T18:07:44Z DEBUG stdout=Loading deployment configuration from /tmp/tmprI2isq. 2014-06-16T18:07:44Z DEBUG stderr=Traceback (most recent call last): File "/usr/sbin/pkispawn", line 530, in main(sys.argv) File "/usr/sbin/pkispawn", line 439, in main info = parser.sd_get_info() File "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", line 442, in sd_get_info info = sd.getSecurityDomainInfo() File "/usr/lib/python2.7/site-packages/pki/system.py", line 40, in getSecurityDomainInfo info.name = j['DomainInfo']['@id'] KeyError: 'DomainInfo' 2014-06-16T18:07:44Z CRITICAL failed to configure ca instance Command ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmprI2isq'' returned non-zero exit status 1 2014-06-16T18:07:44Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 639, in run_script return_value = main_function() 5. This one may be for Tomas, but: 2014-06-16T19:01:28Z INFO Deleting schedule 2358-2359 0 from agreement cn=meTogrindle.greyoak.com,cn=replica,cn=dc\=greyoak\,dc\=com,cn=mapping tree,cn=config 2014-06-16T19:01:29Z ERROR unable to convert the attribute u'nsds5replicalastupdateend' value '0' to type 2014-06-16T19:01:29Z INFO Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2014-06-16T19:01:30Z ERROR unable to convert the attribute u'nsds5replicalastupdateend' value '0' to type 2014-06-16T19:01:30Z INFO Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2014-06-16T19:01:31Z ERROR unable to convert the attribute u'nsds5replicalastupdateend' value '0' to type 2014-06-16T19:01:31Z INFO Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2014-06-16T19:01:32Z ERROR unable to convert the attribute u'nsds5replicalastupdateend' value '0' to type 2014-06-16T19:01:32Z INFO Replication Update in progress: TRUE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 6. With an external CA install of F-20 vanilla, upgraded to this patch, the external CA is not added to /etc/pki/nssdb. On a pure install of this patch, it is added. Not sure if we care since the cert is in the global cert store. 7. Something for the future, but I wonder if test test_0002_find_CA in ipatests/test_xmlrpc/test_cert_plugin.py should be able to handle external CAs. rob From mkosek at redhat.com Tue Jun 17 07:18:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jun 2014 09:18:19 +0200 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1402932870.22737.113.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> Message-ID: <539FEBBB.3010104@redhat.com> On 06/16/2014 05:34 PM, Simo Sorce wrote: > Although the code is all done it would be nice to have a review of the > feature, to see if it has all been captured: > http://www.freeipa.org/page/V4/Keytab_Retrieval > > Simo. > Thanks! I was not deeply involved in the review, but from the high level it looks good to me. I at least fixed typos and improved formatting. Martin From thozza at redhat.com Tue Jun 17 07:33:06 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 03:33:06 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading In-Reply-To: <53864D88.6030400@redhat.com> References: <538498FA.7070609@redhat.com> <53849A57.4040106@redhat.com> <5385C7C8.3060102@redhat.com> <53864D88.6030400@redhat.com> Message-ID: <1509097894.11927028.1402990386038.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 28.5.2014 13:26, Tomas Hozza wrote: > > On 05/27/2014 03:59 PM, Petr Spacek wrote: > >> On 27.5.2014 15:54, Petr Spacek wrote: > >>> Fix race condition during zone loading. > >>> > >>> DNS zone has to be added to DNS view before dns_zone_load() is called. > >>> It is necessary to prevent dns_zone_load() from racing with > >>> dns_zone_setview(). > >>> > >>> This race condition sometimes prevents zone from being signed. > >>> Now the unsigned zone is visible until signing process is complete. This > >>> mimics BIND behavior for in-line signed zones. > >>> > >>> https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > >> > >> And here is the patch... > >> > > > > Hi. > > > > When I use bind-dyndb-ldap plugin with this patch, named > > does not start due to: > > > > rbt.c:1379: REQUIRE(name->buffer != ((void *)0)) failed, back trace > > > > (gdb) bt > > #0 0x00007f3963924c39 in raise () from /lib64/libc.so.6 > > #1 0x00007f3963926348 in abort () from /lib64/libc.so.6 > > #2 0x00007f3966979aee in assertion_failed () > > #3 0x00007f3964b6917a in isc_assertion_failed () from /lib64/libisc.so.95 > > #4 0x00007f39661ca9da in dns_rbt_fullnamefromnode () from > > /lib64/libdns.so.100 > > #5 0x00007f396011824b in rbt_iter_getnodename (iter=, > > nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:46 > > #6 0x00007f396011839b in rbt_iter_next > > (iterp=iterp at entry=0x7f39625f8b90, > > nodename=nodename at entry=0x7f39625f8bf0) at rbt_helper.c:144 > > #7 0x00007f3960112d32 in activate_zones > > (task=task at entry=0x7f39668f5790, inst=0x7f39668e4160) at ldap_helper.c:1164 > > #8 0x00007f396011a20d in barrier_decrement (task=0x7f39668f5790, > > event=0x7f396005b010) at syncrepl.c:138 > > #9 0x00007f3964b8b836 in run () from /lib64/libisc.so.95 > > #10 0x00007f396473ff33 in start_thread () from /lib64/libpthread.so.0 > > #11 0x00007f39639e3ded in clone () from /lib64/libc.so.6 > > > > > > It looks like you should use INIT_BUFFERED_NAME(name); used in the > > original code instead of dns_name_init(&name, NULL). The macro > > initializes the buffer in "name", which is missing in the new code. > > Oh yes, it didn't happened on my machine because I have had only single zone > defined in LDAP at the time of testing. Thank you for catching this! > > I'm attaching fixed patch. dns_name_reset() is good enough in this case. > > -- > Petr^2 Spacek > Now it works. ACK Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From mkosek at redhat.com Tue Jun 17 08:16:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Jun 2014 10:16:28 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <539F2E7F.2010600@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> Message-ID: <539FF95C.2060702@redhat.com> On 06/16/2014 07:50 PM, Petr Viktorin wrote: > On 06/16/2014 02:53 PM, Tomas Babej wrote: >> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>> On 06/10/2014 10:13 AM, Tomas Babej wrote: > >>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the following set of patches implements the ticket: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>> >>> [...] >>>>>> > > 0202: OK > 0203: OK > 0204: OK > 0205: OK > 0206: OK > 0207: OK > (sorry for the conflict!) > > 0208: OK > 0209: OK > 0210: OK > 0211: OK > 0212: OK > 0213: OK > 0214: OK > 0215: OK > 0216: OK > 0217: OK > 0218: OK > 0219: OK > 0220: OK > 0221: OK > 0222: OK > > modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` > argument. > > Rebasing this all the time must be painful, so to avoid another review > round-trip I've had Tom?? ACK the attached four-liner on IRC. Thanks guys! I looked at the changes and have couple questions: 1) What is the motivation for keeping AuthConfig infrastructure around? I thought it is replaced by the tasks concept that are easier to customize in other platforms. IMO, it just obfuscates the process. How is def modify_pam_to_use_krb5(self, statestore): auth_config = FedoraAuthConfig() statestore.backup_state('authconfig', 'krb5', True) auth_config.enable("krb5") auth_config.add_option("nostart") auth_config.execute() more readable than def modify_pam_to_use_krb5(self, statestore): statestore.backup_state('authconfig', 'krb5', True) ipautil.run("authconfig --enablekrb5 --nostart") ? And this was just the easy example. Also, documentation in AuthConfig base class refers to nonexistent paths. 2) There are still many non-converted paths in ipa-client installers: $ git grep "bin/" ipa-client/ ... ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = '/usr/bin/sss_ssh_authorizedkeys' ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = '/usr/bin/sss_ssh_knownhostsproxy' ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", nickname], raiseonerr=False) ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) ... We should convert at least those as ipa-client will be the most platformized module (more than the server, IMO). Martin From pspacek at redhat.com Tue Jun 17 08:16:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Jun 2014 10:16:43 +0200 Subject: [Freeipa-devel] [PATCH 0266] (aka 257.5) Fix zone reloading for in-line signed zones Message-ID: <539FF96B.1020504@redhat.com> Hello, I forgot to send one patch between no. 257 and 258, so here it is :-) Fix zone reloading for in-line signed zones. A invalid secure zone (e.g. without NS records) is now automatically reloaded when data inside the zone are changed. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0266-Fix-zone-reloading-for-in-line-signed-zones.patch Type: text/x-patch Size: 5404 bytes Desc: not available URL: From thozza at redhat.com Tue Jun 17 08:35:21 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 04:35:21 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0266] (aka 257.5) Fix zone reloading for in-line signed zones In-Reply-To: <539FF96B.1020504@redhat.com> References: <539FF96B.1020504@redhat.com> Message-ID: <121537395.11936747.1402994121379.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > I forgot to send one patch between no. 257 and 258, so here it is :-) > > Fix zone reloading for in-line signed zones. > > A invalid secure zone (e.g. without NS records) is now automatically > reloaded when data inside the zone are changed. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > -- > Petr^2 Spacek > ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue Jun 17 08:36:09 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 04:36:09 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for secure zones In-Reply-To: <539FF3FE.3030404@redhat.com> References: <538F3C85.20507@redhat.com> <539FF3FE.3030404@redhat.com> Message-ID: <1073701430.11937064.1402994169486.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Subject: Re: [Freeipa-devel] [PATCH 0258] Fix run-time zone addition for > secure zones > Date: Wed, 04 Jun 2014 17:34:29 +0200 > From: Petr Spacek > Organization: Red Hat > To: freeipa-devel at redhat.com > > On 3.6.2014 10:53, Petr Spacek wrote: > > Hello, > > > > Fix run-time zone addition for secure zones. > > Here comes fix for the fix ... > > We really need a test-suite for bind-dyndb-ldap. > > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > -- > Petr^2 Spacek > > > > ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From tjaalton at ubuntu.com Tue Jun 17 10:03:09 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 17 Jun 2014 13:03:09 +0300 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <539FF95C.2060702@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> Message-ID: <53A0125D.1030407@ubuntu.com> On 17.06.2014 11:16, Martin Kosek wrote: > On 06/16/2014 07:50 PM, Petr Viktorin wrote: >> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >> >>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> the following set of patches implements the ticket: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>> >>>> [...] >>>>>>> >> >> 0202: OK >> 0203: OK >> 0204: OK >> 0205: OK >> 0206: OK >> 0207: OK >> (sorry for the conflict!) >> >> 0208: OK >> 0209: OK >> 0210: OK >> 0211: OK >> 0212: OK >> 0213: OK >> 0214: OK >> 0215: OK >> 0216: OK >> 0217: OK >> 0218: OK >> 0219: OK >> 0220: OK >> 0221: OK >> 0222: OK >> >> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` >> argument. >> >> Rebasing this all the time must be painful, so to avoid another review >> round-trip I've had Tom?? ACK the attached four-liner on IRC. > > Thanks guys! > > I looked at the changes and have couple questions: > > 1) What is the motivation for keeping AuthConfig infrastructure around? I > thought it is replaced by the tasks concept that are easier to customize in > other platforms. IMO, it just obfuscates the process. > > How is > def modify_pam_to_use_krb5(self, statestore): > auth_config = FedoraAuthConfig() > statestore.backup_state('authconfig', 'krb5', True) > auth_config.enable("krb5") > auth_config.add_option("nostart") > auth_config.execute() > more readable than > def modify_pam_to_use_krb5(self, statestore): > statestore.backup_state('authconfig', 'krb5', True) > ipautil.run("authconfig --enablekrb5 --nostart") > ? And this was just the easy example. Also, documentation in AuthConfig base > class refers to nonexistent paths. > > 2) There are still many non-converted paths in ipa-client installers: > > $ git grep "bin/" ipa-client/ > ... > ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = > '/usr/bin/sss_ssh_authorizedkeys' > ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = > '/usr/bin/sss_ssh_knownhostsproxy' > ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = > run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", nickname], > raiseonerr=False) > ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", > "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) > ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", > "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) > ... > > We should convert at least those as ipa-client will be the most platformized > module (more than the server, IMO). and many others all over the place, just 'git grep /etc/' working on the debian client patches now.. -- t From tbabej at redhat.com Tue Jun 17 10:25:44 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Jun 2014 12:25:44 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <538369E1.5020300@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> Message-ID: <53A017A8.8080105@redhat.com> On 05/26/2014 06:20 PM, Petr Viktorin wrote: > On 05/20/2014 06:15 PM, Tomas Babej wrote: >> Hi, >> >> the following set of patches fixes: >> >> https://fedorahosted.org/freeipa/ticket/4274 >> https://fedorahosted.org/freeipa/ticket/4263 >> https://fedorahosted.org/freeipa/ticket/4324 >> https://fedorahosted.org/freeipa/ticket/4340 >> https://fedorahosted.org/freeipa/ticket/4341 >> >> and additional minor issues. >> >> The improvemed CI test coverage for the sudorule plugin is added as a >> bonus. > > Thanks! > I haven't tested yet; here are my comments on the code. > > > 0187 - sudorule: PEP8 fixes in sudorule.py > > This change: > >> @@ -527,11 +551,15 @@ def pre_callback(self, ldap, dn, found, >> not_found, *keys, **options): >> _entry_attrs = ldap.get_entry(dn, >> self.obj.default_attributes) >> except errors.NotFound: >> self.obj.handle_not_found(*keys) >> - if is_all(_entry_attrs, 'hostcategory'): >> - raise errors.MutuallyExclusiveError(reason=_("hosts >> cannot be added when host category='all'")) >> + >> + if is_all(self._entry_attrs, 'hostcategory'): >> + raise errors.MutuallyExclusiveError( >> + reason=_("hosts cannot be added when host >> category='all'")) >> + >> return add_external_pre_callback('host', ldap, dn, keys, >> options) > > adds `self` to `self._entry_attrs`. That should be a part of the next > patch. > Git tip: `git log --word-diff` helps a lot when you play with whitespace Right, it's gone. > > (Speaking of PEP8, if you could remove the baseldap star import from > sudorule.py, it would be great...) > > This one did hurt, but the star disappeared. > > General thoughts: > > Would it be possible to merge schema_compat.uldif and > install/updates/10-schema_compat.update into one file? Is the uldif > special somehow? I guess this is a question for Rob. > It would be nice to add a link to some schema-compat-entry-attribute > documentation to these files. > I added Rob to cc. Rob, can you elaborate on this? > > > 0188 - sudorule: Allow using hostmasks for setting allowed hosts > > Here: > >> --- a/install/updates/40-delegation.update >> +++ b/install/updates/40-delegation.update >> @@ -174,7 +174,7 @@ default:member: cn=Sudo >> Administrator,cn=privileges,cn=pbac,$SUFFIX >> dn: $SUFFIX >> add:aci: '(target = >> "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Add Sudo rule";allow (add) groupdn = "ldap:///cn=Add Sudo >> rule,cn=permissions,cn=pbac,$SUFFIX";)' >> add:aci: '(target = >> "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Delete Sudo rule";allow (delete) groupdn = >> "ldap:///cn=Delete Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' >> -add:aci: '(targetattr = "description || ipaenabledflag || >> usercategory || hostcategory || cmdcategory || >> ipasudorunasusercategory || ipasudorunasgroupcategory || externaluser >> || ipasudorunasextuser || ipasudorunasextgroup || memberdenycmd || >> memberallowcmd || memberuser")(target = >> "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Modify Sudo rule";allow (write) groupdn = >> "ldap:///cn=Modify Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' >> +add:aci: '(targetattr = "description || ipaenabledflag || >> usercategory || hostcategory || cmdcategory || >> ipasudorunasusercategory || ipasudorunasgroupcategory || externaluser >> || ipasudorunasextuser || ipasudorunasextgroup || memberdenycmd || >> memberallowcmd || memberuser || hostmask")(target = >> "ldap:///ipauniqueid=*,cn=sudorules,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Modify Sudo rule";allow (write) groupdn = >> "ldap:///cn=Modify Sudo rule,cn=permissions,cn=pbac,$SUFFIX";)' >> >> remove:aci: '(targetattr = "description")(target = >> "ldap:///sudocmd=*,cn=sudocmds,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Modify Sudo command";allow (write) groupdn = >> "ldap:///cn=Modify Sudo command,cn=permissions,cn=pbac,$SUFFIX";)' >> remove:aci: '(target = >> "ldap:///sudocmd=*,cn=sudocmds,cn=sudo,$SUFFIX")(version 3.0;acl >> "permission:Delete Sudo command";allow (delete) groupdn = >> "ldap:///cn=Delete Sudo command,cn=permissions,cn=pbac,$SUFFIX";)' > > you'll want to remove the old ACI before adding the new version. > This is irrelevant since we're rebased on top of your ACI refactoring now. > In get_options of sudorule_add_host and sudorule_remove_host, it would > be DRY-er to put the hostmask in a shared variable. > > You write: >> - _entry_attrs = ldap.get_entry(dn, >> self.obj.default_attributes) >> + self._entry_attrs = ldap.get_entry(dn, >> self.obj.default_attributes) > > Never store anything on the Command object. They're currently > singletons. Another thread could change _entry_attrs to a different > value. > This affects all the other uses of self._entry_attrs, of course. Fixed. > > In: >> + num_added = len(new_masks.difference(old_masks)) > and: >> + entry_attrs['hostmask'] = >> list(old_masks.union(new_masks)) > and: >> + num_added = len(removed_masks.intersection(old_masks)) > etc.: with two sets, you can use the `-`, `|`, and `&` operators. > Cool tip, replaced! > > Since you're touching this: >> + return add_external_post_callback('memberhost', 'host', >> 'externalhost', >> + ldap, completed, failed, dn, >> + entry_attrs, keys, options) > it would be nice to pass the arguments by name, for clarity and to > avoid mistakes. I guess this should be in the PEP8 patch, too. > Done, part of patch 225. > > > > 0189 sudorule: Allow using external groups as groups of runAsUsers > > In sudorule_add_runasuser and sudorule_remove_runasuser, could you > again pass the arguments by name? > I'd welcome comment explaining why completed=0. If you could throw in > a comment for add_external_post_callback explaining the inputs and > outputs, it would be great -- I'm getting quite lost in this code. > (I'd even go as far as changing the signature of > *_external_post_callback -- AFAICS, in all the places we call it, we > do `*keys, **options` wrong, and the `completed` argument is not > useful at all. Most of the calls are from sudorule so it would make > sense to do it in this patchset.) > This is done in the new attached patch 225. > And a heads-up: the change to "permission:Modify Sudo rule" conflicts > with my ACI work. Let me know if there are problems. > > > > > 0190 sudorule: Make sure sudoRunAsGroup is dereferencing the correct > attribute > > Looks good > > > > > 0191 sudorule: Include externalhost and ipasudorunasextgroup in the > list of default attributes > > Looks good > > > > > 0192 sudorule: Allow adding deny commands when command category set to > ALL > > Looks good > > > > > 0193 sudorule: Make sure all the relevant attributes are checked when > setting category to ALL > > Wow, haven't seen a copyright year change in some time. We are sloppy > with those. Portions of the file are still from 2010 so you should > definitely leave that year in, though. Actually I think the proper > year field would read "2010,2011,2012,2013,2014". > I am not a lawyer. > > You're missing the `_` for the hostcategory error message. > Did you think about using something like _("%s cannot be set to 'all' > while there are %s")? > Fixed. Initially, I changed the message as you suggested, but then I realized, that this might pose a problem for translations that do not follow the word order in the sentence as it is defined in English language. > > > 0194 sudorule: Fix the order of the parameters to have less chaotic > output > > Looks fine > > > > > 0195-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch > > Looks fine > > > > > 0196-0198 (Add tests) > > Looks fine. Just remind me, why is this all in integration tests? > Couldn't it at least some of it be in the main test suite? It looks to > me like most of it doesn't need multiple machines. > > We need to check that the rules are actually enforced on the client setup to look them up on the IPA server. This tests compat tree entry generation, SSSD-sudo integration and the actual rule enforcement. All sudo commands are executed on the client machine. > > > 0199-0201 (test fixes) > > OK > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0225-sudorule-Refactor-add-and-remove-external_post_callb.patch Type: text/x-patch Size: 21184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0187-3-sudorule-PEP8-fixes-in-sudorule.py.patch Type: text/x-patch Size: 18390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0188-3-sudorule-Allow-using-hostmasks-for-setting-allowed-h.patch Type: text/x-patch Size: 11076 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0189-3-sudorule-Allow-using-external-groups-as-groups-of-ru.patch Type: text/x-patch Size: 13876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0190-3-sudorule-Make-sure-sudoRunAsGroup-is-dereferencing-t.patch Type: text/x-patch Size: 2736 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0191-3-sudorule-Include-externalhost-and-ipasudorunasextgro.patch Type: text/x-patch Size: 1079 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0192-3-sudorule-Allow-adding-deny-commands-when-command-cat.patch Type: text/x-patch Size: 1092 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0193-3-sudorule-Make-sure-all-the-relevant-attributes-are-c.patch Type: text/x-patch Size: 4336 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0194-3-sudorule-Fix-the-order-of-the-parameters-to-have-les.patch Type: text/x-patch Size: 2984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0195-3-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch Type: text/x-patch Size: 4898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0196-3-ipatests-test_sudo-Add-tests-for-allowing-hosts-via-.patch Type: text/x-patch Size: 2625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0197-3-ipatests-test_sudo-Add-coverage-for-external-entries.patch Type: text/x-patch Size: 6890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0198-3-ipatests-test_sudo-Add-coverage-for-category-ALL-val.patch Type: text/x-patch Size: 15765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0199-3-ipatests-test_sudo-Fix-assertions-not-assuming-runas.patch Type: text/x-patch Size: 4708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0200-3-ipatests-test_sudo-Do-not-expect-enumeration-of-runa.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0201-3-ipatests-test_sudo-Expect-root-listed-out-if-no-RunA.patch Type: text/x-patch Size: 1544 bytes Desc: not available URL: From tbabej at redhat.com Tue Jun 17 10:27:12 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Jun 2014 12:27:12 +0200 Subject: [Freeipa-devel] [PATCH 0227] sudorule: Allow unsetting sudoorder Message-ID: <53A01800.7000005@redhat.com> Hi, After setting sudoorder, you are unable to unset it, since the check for uniqueness of order of sudorules is applied incorrectly. Fix the behaviour and cover it in the test suite. https://fedorahosted.org/freeipa/ticket/4360 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0227-sudorule-Allow-unsetting-sudoorder.patch Type: text/x-patch Size: 2009 bytes Desc: not available URL: From tbabej at redhat.com Tue Jun 17 12:15:14 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Jun 2014 14:15:14 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A0125D.1030407@ubuntu.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> Message-ID: <53A03152.4010204@redhat.com> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: > On 17.06.2014 11:16, Martin Kosek wrote: >> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the following set of patches implements the ticket: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>> >>>>> [...] >>> 0202: OK >>> 0203: OK >>> 0204: OK >>> 0205: OK >>> 0206: OK >>> 0207: OK >>> (sorry for the conflict!) >>> >>> 0208: OK >>> 0209: OK >>> 0210: OK >>> 0211: OK >>> 0212: OK >>> 0213: OK >>> 0214: OK >>> 0215: OK >>> 0216: OK >>> 0217: OK >>> 0218: OK >>> 0219: OK >>> 0220: OK >>> 0221: OK >>> 0222: OK >>> >>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` >>> argument. >>> >>> Rebasing this all the time must be painful, so to avoid another review >>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >> Thanks guys! >> >> I looked at the changes and have couple questions: >> >> 1) What is the motivation for keeping AuthConfig infrastructure around? I >> thought it is replaced by the tasks concept that are easier to customize in >> other platforms. IMO, it just obfuscates the process. >> >> How is >> def modify_pam_to_use_krb5(self, statestore): >> auth_config = FedoraAuthConfig() >> statestore.backup_state('authconfig', 'krb5', True) >> auth_config.enable("krb5") >> auth_config.add_option("nostart") >> auth_config.execute() >> more readable than >> def modify_pam_to_use_krb5(self, statestore): >> statestore.backup_state('authconfig', 'krb5', True) >> ipautil.run("authconfig --enablekrb5 --nostart") >> ? And this was just the easy example. Also, documentation in AuthConfig base >> class refers to nonexistent paths. >> >> 2) There are still many non-converted paths in ipa-client installers: >> >> $ git grep "bin/" ipa-client/ >> ... >> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = >> '/usr/bin/sss_ssh_authorizedkeys' >> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >> '/usr/bin/sss_ssh_knownhostsproxy' >> ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = >> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", nickname], >> raiseonerr=False) >> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >> ... >> >> We should convert at least those as ipa-client will be the most platformized >> module (more than the server, IMO). > and many others all over the place, just 'git grep /etc/' > > working on the debian client patches now.. > > Attached is a new version of patch 226, and a new patch 228, which moves the paths from installers to the paths module. I greped the repository, and I do not see many paths lurking around any more, there are only some in the error messages (as these can't be reliably replaced automatically, and will need some manual love). If you see any forgotten paths, which should be added to the module, let me know. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-ipaplatform-Move-paths-from-installers-to-paths-modu.patch Type: text/x-patch Size: 61142 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-2-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4756 bytes Desc: not available URL: From jhrozek at redhat.com Tue Jun 17 12:38:24 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Jun 2014 14:38:24 +0200 Subject: [Freeipa-devel] [RFC] Sending group-memberships to SSSD clients In-Reply-To: <20140602130319.GY30381@localhost.localdomain> References: <20140602130319.GY30381@localhost.localdomain> Message-ID: <20140617123824.GL9692@hendrix.brq.redhat.com> On Mon, Jun 02, 2014 at 03:03:19PM +0200, Sumit Bose wrote: > Hi, > > I'm preparing a design page for > https://fedorahosted.org/freeipa/ticket/4031 "[RFE] Support initgroups > for unauthenticated AD users". > > Since we are using SSSD in ipa-server-mode in the server, the IPA server > is able to resolve group memberships even if the user is not > authenticated. To make the information available to the client the > extdom plugin should be enhanced to send the information from the server > to the clients. > > My question is, what would be the best type of data to send to the > clients. The obvious first answer is a list if GIDs. But since we have > views this would require additional processing and LDAP lookups on the > server side. As an alternative we can send a list of fully qualified > group names or a list of SIDs (as long as we are only looking at trust > to AD). Both are independent of the view, but would require additional > lookups from the client for the GID if the group with the given fully > qualified name or SID is not already in the cache. But this will > basically only happen if the cache is empty, which the additional > processing due to user-views on the server would happen on every request > if we only send the list of GIDs. > > So, I'm tending to the list of fully qualified names. Does anyone has > concerns or other suggestions? As an additional suggestion, I also think in server mode you can ignore that the FQDN format is technically configurable and just use user at domain, IIRC the SSSD in server mode should even disallow any other format. From pspacek at redhat.com Tue Jun 17 12:44:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Jun 2014 14:44:48 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A03152.4010204@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> Message-ID: <53A03840.1010209@redhat.com> On 17.6.2014 14:15, Tomas Babej wrote: > > On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >> On 17.06.2014 11:16, Martin Kosek wrote: >>> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> the following set of patches implements the ticket: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>>> >>>>>> [...] >>>> 0202: OK >>>> 0203: OK >>>> 0204: OK >>>> 0205: OK >>>> 0206: OK >>>> 0207: OK >>>> (sorry for the conflict!) >>>> >>>> 0208: OK >>>> 0209: OK >>>> 0210: OK >>>> 0211: OK >>>> 0212: OK >>>> 0213: OK >>>> 0214: OK >>>> 0215: OK >>>> 0216: OK >>>> 0217: OK >>>> 0218: OK >>>> 0219: OK >>>> 0220: OK >>>> 0221: OK >>>> 0222: OK >>>> >>>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` >>>> argument. >>>> >>>> Rebasing this all the time must be painful, so to avoid another review >>>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >>> Thanks guys! >>> >>> I looked at the changes and have couple questions: >>> >>> 1) What is the motivation for keeping AuthConfig infrastructure around? I >>> thought it is replaced by the tasks concept that are easier to customize in >>> other platforms. IMO, it just obfuscates the process. >>> >>> How is >>> def modify_pam_to_use_krb5(self, statestore): >>> auth_config = FedoraAuthConfig() >>> statestore.backup_state('authconfig', 'krb5', True) >>> auth_config.enable("krb5") >>> auth_config.add_option("nostart") >>> auth_config.execute() >>> more readable than >>> def modify_pam_to_use_krb5(self, statestore): >>> statestore.backup_state('authconfig', 'krb5', True) >>> ipautil.run("authconfig --enablekrb5 --nostart") >>> ? And this was just the easy example. Also, documentation in AuthConfig base >>> class refers to nonexistent paths. >>> >>> 2) There are still many non-converted paths in ipa-client installers: >>> >>> $ git grep "bin/" ipa-client/ >>> ... >>> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = >>> '/usr/bin/sss_ssh_authorizedkeys' >>> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >>> '/usr/bin/sss_ssh_knownhostsproxy' >>> ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = >>> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", nickname], >>> raiseonerr=False) >>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >>> ... >>> >>> We should convert at least those as ipa-client will be the most platformized >>> module (more than the server, IMO). >> and many others all over the place, just 'git grep /etc/' >> >> working on the debian client patches now.. >> >> > > Attached is a new version of patch 226, and a new patch 228, which moves > the paths from installers to the paths module. > > I greped the repository, and I do not see many paths lurking around any > more, there are only some in the error messages (as these can't be > reliably replaced automatically, and will need some manual love). I don't know the code but why it is not possible to use "%s" % (paths.blahblah) ? IMHO paths should never be hardcoded in strings/messages shown to user. Petr^2 Spacek > If you see any forgotten paths, which should be added to the module, let > me know. From jhrozek at redhat.com Tue Jun 17 12:50:16 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Jun 2014 14:50:16 +0200 Subject: [Freeipa-devel] [RFC] Extdom plugin enhancement: grouplist In-Reply-To: <20140606172414.GQ5752@localhost.localdomain> References: <20140606172414.GQ5752@localhost.localdomain> Message-ID: <20140617125016.GM9692@hendrix.brq.redhat.com> On Fri, Jun 06, 2014 at 07:24:14PM +0200, Sumit Bose wrote: > Hi, > > I've created a design page about enhancing the extdom plugin to send the > list of groups of a user together with the POSIX data to IPA clients > with SSSD at > > http://www.freeipa.org/page/V4/Extdom_plugin_enhancement_grouplist > > For your convenience the text can be found below as well. > > Comments and suggestions are welcome. > > bye, > Sumit I'm in favor of detecting the OID as well. If we can't detect the presence of the OID (maybe because the admin messed up with permissions to read the rootDSE), too bad, but you'd still get the full group memberships on login through the PAC responder. The LDAP error codes seem fragile and moreover we will run into the same issue later when/if we decide to extend the plugin further. As said earlier in a different thread, I don't think you need to worry about the FQDN format. I haven't tested that myself today, but I think we even disallow other formats in the server mode, because the slapi-nis plugin for legacy clients looks for "@" unconditionally. We should only warn and fail if the admin configured a custom FQDN in sssd.conf, I think. From tbabej at redhat.com Tue Jun 17 12:50:19 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Jun 2014 14:50:19 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A03840.1010209@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A03840.1010209@redhat.com> Message-ID: <53A0398B.2090508@redhat.com> On 06/17/2014 02:44 PM, Petr Spacek wrote: > On 17.6.2014 14:15, Tomas Babej wrote: >> >> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>> On 17.06.2014 11:16, Martin Kosek wrote: >>>> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>>>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> the following set of patches implements the ticket: >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>>>> >>>>>>> [...] >>>>> 0202: OK >>>>> 0203: OK >>>>> 0204: OK >>>>> 0205: OK >>>>> 0206: OK >>>>> 0207: OK >>>>> (sorry for the conflict!) >>>>> >>>>> 0208: OK >>>>> 0209: OK >>>>> 0210: OK >>>>> 0211: OK >>>>> 0212: OK >>>>> 0213: OK >>>>> 0214: OK >>>>> 0215: OK >>>>> 0216: OK >>>>> 0217: OK >>>>> 0218: OK >>>>> 0219: OK >>>>> 0220: OK >>>>> 0221: OK >>>>> 0222: OK >>>>> >>>>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing >>>>> the `self` >>>>> argument. >>>>> >>>>> Rebasing this all the time must be painful, so to avoid another >>>>> review >>>>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >>>> Thanks guys! >>>> >>>> I looked at the changes and have couple questions: >>>> >>>> 1) What is the motivation for keeping AuthConfig infrastructure >>>> around? I >>>> thought it is replaced by the tasks concept that are easier to >>>> customize in >>>> other platforms. IMO, it just obfuscates the process. >>>> >>>> How is >>>> def modify_pam_to_use_krb5(self, statestore): >>>> auth_config = FedoraAuthConfig() >>>> statestore.backup_state('authconfig', 'krb5', True) >>>> auth_config.enable("krb5") >>>> auth_config.add_option("nostart") >>>> auth_config.execute() >>>> more readable than >>>> def modify_pam_to_use_krb5(self, statestore): >>>> statestore.backup_state('authconfig', 'krb5', True) >>>> ipautil.run("authconfig --enablekrb5 --nostart") >>>> ? And this was just the easy example. Also, documentation in >>>> AuthConfig base >>>> class refers to nonexistent paths. >>>> >>>> 2) There are still many non-converted paths in ipa-client installers: >>>> >>>> $ git grep "bin/" ipa-client/ >>>> ... >>>> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = >>>> '/usr/bin/sss_ssh_authorizedkeys' >>>> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >>>> '/usr/bin/sss_ssh_knownhostsproxy' >>>> ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = >>>> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", >>>> nickname], >>>> raiseonerr=False) >>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >>>> ... >>>> >>>> We should convert at least those as ipa-client will be the most >>>> platformized >>>> module (more than the server, IMO). >>> and many others all over the place, just 'git grep /etc/' >>> >>> working on the debian client patches now.. >>> >>> >> >> Attached is a new version of patch 226, and a new patch 228, which moves >> the paths from installers to the paths module. >> >> I greped the repository, and I do not see many paths lurking around any >> more, there are only some in the error messages (as these can't be >> reliably replaced automatically, and will need some manual love). > I don't know the code but why it is not possible to use > "%s" % (paths.blahblah) ? > > IMHO paths should never be hardcoded in strings/messages shown to user. > > Petr^2 Spacek Of course they can, they just cannot be replaced by the tool I developed for this refactoring, and need to be replaced manually, as the tool lacks the capability. They need to be replaced manually. > >> If you see any forgotten paths, which should be added to the module, let >> me know. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tjaalton at ubuntu.com Tue Jun 17 12:53:46 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 17 Jun 2014 15:53:46 +0300 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A03152.4010204@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> Message-ID: <53A03A5A.90902@ubuntu.com> On 17.06.2014 15:15, Tomas Babej wrote: > > On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >> On 17.06.2014 11:16, Martin Kosek wrote: >>> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> the following set of patches implements the ticket: >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>>> >>>>>> [...] >>>> 0202: OK >>>> 0203: OK >>>> 0204: OK >>>> 0205: OK >>>> 0206: OK >>>> 0207: OK >>>> (sorry for the conflict!) >>>> >>>> 0208: OK >>>> 0209: OK >>>> 0210: OK >>>> 0211: OK >>>> 0212: OK >>>> 0213: OK >>>> 0214: OK >>>> 0215: OK >>>> 0216: OK >>>> 0217: OK >>>> 0218: OK >>>> 0219: OK >>>> 0220: OK >>>> 0221: OK >>>> 0222: OK >>>> >>>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing the `self` >>>> argument. >>>> >>>> Rebasing this all the time must be painful, so to avoid another review >>>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >>> Thanks guys! >>> >>> I looked at the changes and have couple questions: >>> >>> 1) What is the motivation for keeping AuthConfig infrastructure around? I >>> thought it is replaced by the tasks concept that are easier to customize in >>> other platforms. IMO, it just obfuscates the process. >>> >>> How is >>> def modify_pam_to_use_krb5(self, statestore): >>> auth_config = FedoraAuthConfig() >>> statestore.backup_state('authconfig', 'krb5', True) >>> auth_config.enable("krb5") >>> auth_config.add_option("nostart") >>> auth_config.execute() >>> more readable than >>> def modify_pam_to_use_krb5(self, statestore): >>> statestore.backup_state('authconfig', 'krb5', True) >>> ipautil.run("authconfig --enablekrb5 --nostart") >>> ? And this was just the easy example. Also, documentation in AuthConfig base >>> class refers to nonexistent paths. >>> >>> 2) There are still many non-converted paths in ipa-client installers: >>> >>> $ git grep "bin/" ipa-client/ >>> ... >>> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = >>> '/usr/bin/sss_ssh_authorizedkeys' >>> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >>> '/usr/bin/sss_ssh_knownhostsproxy' >>> ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = >>> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", nickname], >>> raiseonerr=False) >>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >>> ... >>> >>> We should convert at least those as ipa-client will be the most platformized >>> module (more than the server, IMO). >> and many others all over the place, just 'git grep /etc/' >> >> working on the debian client patches now.. >> >> > > Attached is a new version of patch 226, and a new patch 228, which moves > the paths from installers to the paths module. > > I greped the repository, and I do not see many paths lurking around any > more, there are only some in the error messages (as these can't be > reliably replaced automatically, and will need some manual love). > > If you see any forgotten paths, which should be added to the module, let > me know. Sure thing! Looks more complete now, and at least the paths I was patching before (in ipa-client-automount) are fixed. -- t From pspacek at redhat.com Tue Jun 17 13:12:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Jun 2014 15:12:32 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A0398B.2090508@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A03840.1010209@redhat.com> <53A0398B.2090508@redhat.com> Message-ID: <53A03EC0.6010604@redhat.com> On 17.6.2014 14:50, Tomas Babej wrote: > > On 06/17/2014 02:44 PM, Petr Spacek wrote: >> On 17.6.2014 14:15, Tomas Babej wrote: >>> >>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>>>>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>>>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> the following set of patches implements the ticket: >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>>>>> >>>>>>>> [...] >>>>>> 0202: OK >>>>>> 0203: OK >>>>>> 0204: OK >>>>>> 0205: OK >>>>>> 0206: OK >>>>>> 0207: OK >>>>>> (sorry for the conflict!) >>>>>> >>>>>> 0208: OK >>>>>> 0209: OK >>>>>> 0210: OK >>>>>> 0211: OK >>>>>> 0212: OK >>>>>> 0213: OK >>>>>> 0214: OK >>>>>> 0215: OK >>>>>> 0216: OK >>>>>> 0217: OK >>>>>> 0218: OK >>>>>> 0219: OK >>>>>> 0220: OK >>>>>> 0221: OK >>>>>> 0222: OK >>>>>> >>>>>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing >>>>>> the `self` >>>>>> argument. >>>>>> >>>>>> Rebasing this all the time must be painful, so to avoid another >>>>>> review >>>>>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >>>>> Thanks guys! >>>>> >>>>> I looked at the changes and have couple questions: >>>>> >>>>> 1) What is the motivation for keeping AuthConfig infrastructure >>>>> around? I >>>>> thought it is replaced by the tasks concept that are easier to >>>>> customize in >>>>> other platforms. IMO, it just obfuscates the process. >>>>> >>>>> How is >>>>> def modify_pam_to_use_krb5(self, statestore): >>>>> auth_config = FedoraAuthConfig() >>>>> statestore.backup_state('authconfig', 'krb5', True) >>>>> auth_config.enable("krb5") >>>>> auth_config.add_option("nostart") >>>>> auth_config.execute() >>>>> more readable than >>>>> def modify_pam_to_use_krb5(self, statestore): >>>>> statestore.backup_state('authconfig', 'krb5', True) >>>>> ipautil.run("authconfig --enablekrb5 --nostart") >>>>> ? And this was just the easy example. Also, documentation in >>>>> AuthConfig base >>>>> class refers to nonexistent paths. >>>>> >>>>> 2) There are still many non-converted paths in ipa-client installers: >>>>> >>>>> $ git grep "bin/" ipa-client/ >>>>> ... >>>>> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND = >>>>> '/usr/bin/sss_ssh_authorizedkeys' >>>>> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >>>>> '/usr/bin/sss_ssh_knownhostsproxy' >>>>> ipa-client/ipa-install/ipa-client-install: (sout, serr, returncode) = >>>>> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", >>>>> nickname], >>>>> raiseonerr=False) >>>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>>> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >>>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>>> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >>>>> ... >>>>> >>>>> We should convert at least those as ipa-client will be the most >>>>> platformized >>>>> module (more than the server, IMO). >>>> and many others all over the place, just 'git grep /etc/' >>>> >>>> working on the debian client patches now.. >>>> >>>> >>> >>> Attached is a new version of patch 226, and a new patch 228, which moves >>> the paths from installers to the paths module. >>> >>> I greped the repository, and I do not see many paths lurking around any >>> more, there are only some in the error messages (as these can't be >>> reliably replaced automatically, and will need some manual love). >> I don't know the code but why it is not possible to use >> "%s" % (paths.blahblah) ? >> >> IMHO paths should never be hardcoded in strings/messages shown to user. >> >> Petr^2 Spacek > > Of course they can, they just cannot be replaced by the tool I developed > for this refactoring, and need to be replaced manually, as the tool > lacks the capability. > > They need to be replaced manually. Ah, sure. I didn't notice you were speaking about automatic replacement. I'm sorry! Petr^2 Spacek > >> >>> If you see any forgotten paths, which should be added to the module, let >>> me know. From tbabej at redhat.com Tue Jun 17 13:19:59 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Jun 2014 15:19:59 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A03EC0.6010604@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A03840.1010209@redhat.com> <53A0398B.2090508@redhat.com> <53A03EC0.6010604@redhat.com> Message-ID: <53A0407F.9070303@redhat.com> On 06/17/2014 03:12 PM, Petr Spacek wrote: > On 17.6.2014 14:50, Tomas Babej wrote: >> >> On 06/17/2014 02:44 PM, Petr Spacek wrote: >>> On 17.6.2014 14:15, Tomas Babej wrote: >>>> >>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>> On 06/16/2014 07:50 PM, Petr Viktorin wrote: >>>>>>> On 06/16/2014 02:53 PM, Tomas Babej wrote: >>>>>>>> On 06/10/2014 05:07 PM, Petr Viktorin wrote: >>>>>>>>> On 06/10/2014 10:13 AM, Tomas Babej wrote: >>>>>>>>>> On 06/06/2014 01:04 PM, Petr Viktorin wrote: >>>>>>>>>>> On 06/05/2014 03:14 PM, Petr Viktorin wrote: >>>>>>>>>>>> On 06/04/2014 11:42 AM, Tomas Babej wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> the following set of patches implements the ticket: >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4052 >>>>>>>>>>>>> >>>>>>>>> [...] >>>>>>> 0202: OK >>>>>>> 0203: OK >>>>>>> 0204: OK >>>>>>> 0205: OK >>>>>>> 0206: OK >>>>>>> 0207: OK >>>>>>> (sorry for the conflict!) >>>>>>> >>>>>>> 0208: OK >>>>>>> 0209: OK >>>>>>> 0210: OK >>>>>>> 0211: OK >>>>>>> 0212: OK >>>>>>> 0213: OK >>>>>>> 0214: OK >>>>>>> 0215: OK >>>>>>> 0216: OK >>>>>>> 0217: OK >>>>>>> 0218: OK >>>>>>> 0219: OK >>>>>>> 0220: OK >>>>>>> 0221: OK >>>>>>> 0222: OK >>>>>>> >>>>>>> modify_nsswitch_pam_stack and modify_pam_to_use_krb5 are missing >>>>>>> the `self` >>>>>>> argument. >>>>>>> >>>>>>> Rebasing this all the time must be painful, so to avoid another >>>>>>> review >>>>>>> round-trip I've had Tom?? ACK the attached four-liner on IRC. >>>>>> Thanks guys! >>>>>> >>>>>> I looked at the changes and have couple questions: >>>>>> >>>>>> 1) What is the motivation for keeping AuthConfig infrastructure >>>>>> around? I >>>>>> thought it is replaced by the tasks concept that are easier to >>>>>> customize in >>>>>> other platforms. IMO, it just obfuscates the process. >>>>>> >>>>>> How is >>>>>> def modify_pam_to_use_krb5(self, statestore): >>>>>> auth_config = FedoraAuthConfig() >>>>>> statestore.backup_state('authconfig', 'krb5', True) >>>>>> auth_config.enable("krb5") >>>>>> auth_config.add_option("nostart") >>>>>> auth_config.execute() >>>>>> more readable than >>>>>> def modify_pam_to_use_krb5(self, statestore): >>>>>> statestore.backup_state('authconfig', 'krb5', True) >>>>>> ipautil.run("authconfig --enablekrb5 --nostart") >>>>>> ? And this was just the easy example. Also, documentation in >>>>>> AuthConfig base >>>>>> class refers to nonexistent paths. >>>>>> Also, regarding the Authconfig class, attached is a diff that refactors a more complex method (than the one Martin used) to not use Authconfig class. I can see some value in keeping it, as it makes the code somewhat clearer (enable/disable methods as opposed to long-winded options). However, at the very least we should remove the Authconfig class from the base platform module. Please look at the diff and speak out your opinions. >>>>>> 2) There are still many non-converted paths in ipa-client >>>>>> installers: >>>>>> >>>>>> $ git grep "bin/" ipa-client/ >>>>>> ... >>>>>> ipa-client/ipa-install/ipa-client-install:SSH_AUTHORIZEDKEYSCOMMAND >>>>>> = >>>>>> '/usr/bin/sss_ssh_authorizedkeys' >>>>>> ipa-client/ipa-install/ipa-client-install:SSH_PROXYCOMMAND = >>>>>> '/usr/bin/sss_ssh_knownhostsproxy' >>>>>> ipa-client/ipa-install/ipa-client-install: (sout, serr, >>>>>> returncode) = >>>>>> run(["/usr/bin/certutil", "-L", "-d", "/etc/pki/nssdb", "-n", >>>>>> nickname], >>>>>> raiseonerr=False) >>>>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>>>> "-D", "-d", "/etc/pki/nssdb", "-n", "IPA CA"]) >>>>>> ipa-client/ipa-install/ipa-client-install: run(["/usr/bin/certutil", >>>>>> "-D", "-d", "/etc/pki/nssdb", "-n", client_nss_nickname]) >>>>>> ... >>>>>> >>>>>> We should convert at least those as ipa-client will be the most >>>>>> platformized >>>>>> module (more than the server, IMO). >>>>> and many others all over the place, just 'git grep /etc/' >>>>> >>>>> working on the debian client patches now.. >>>>> >>>>> >>>> >>>> Attached is a new version of patch 226, and a new patch 228, which >>>> moves >>>> the paths from installers to the paths module. >>>> >>>> I greped the repository, and I do not see many paths lurking around >>>> any >>>> more, there are only some in the error messages (as these can't be >>>> reliably replaced automatically, and will need some manual love). >>> I don't know the code but why it is not possible to use >>> "%s" % (paths.blahblah) ? >>> >>> IMHO paths should never be hardcoded in strings/messages shown to user. >>> >>> Petr^2 Spacek >> >> Of course they can, they just cannot be replaced by the tool I developed >> for this refactoring, and need to be replaced manually, as the tool >> lacks the capability. >> >> They need to be replaced manually. > > Ah, sure. I didn't notice you were speaking about automatic > replacement. I'm sorry! > > Petr^2 Spacek > >> >>> >>>> If you see any forgotten paths, which should be added to the >>>> module, let >>>> me know. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- diff --git a/ipaplatform/fedora/tasks.py b/ipaplatform/fedora/tasks.py index c20ecd3..54d97f1 100644 --- a/ipaplatform/fedora/tasks.py +++ b/ipaplatform/fedora/tasks.py @@ -92,7 +92,8 @@ class FedoraTaskNamespace(BaseTaskNamespace): was_sssd_installed, was_sssd_configured): - auth_config = FedoraAuthConfig() + args = [] + if statestore.has_state('authconfig'): # disable only those configurations that we enabled during install for conf in ('ldap', 'krb5', 'sssd', 'sssdauth', 'mkhomedir'): @@ -101,20 +102,20 @@ class FedoraTaskNamespace(BaseTaskNamespace): # uses. Remove it from statestore however, so that it becomes # empty at the end of uninstall process. if cnf and conf != 'sssd': - auth_config.disable(conf) + args.append('--disable%s' % conf) else: # There was no authconfig status store # It means the code was upgraded after original install # Fall back to old logic - auth_config.disable("ldap") - auth_config.disable("krb5") + args.append('--disableldap') + args.append('--disablekrb5') if not(was_sssd_installed and was_sssd_configured): # Only disable sssdauth. Disabling sssd would cause issues # with its later uses. - auth_config.disable("sssdauth") - auth_config.disable("mkhomedir") + args.append("--disablesssdauth") + args.append("--disablemkhomedir") - auth_config.execute() + ipautil.run([paths.AUTHCONFIG] + args + ['--update']) def set_nisdomain(self, nisdomain): # Let authconfig setup the permanent configuration From simo at redhat.com Tue Jun 17 13:40:10 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 09:40:10 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <539FEBBB.3010104@redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <539FEBBB.3010104@redhat.com> Message-ID: <1403012410.22737.132.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 09:18 +0200, Martin Kosek wrote: > On 06/16/2014 05:34 PM, Simo Sorce wrote: > > Although the code is all done it would be nice to have a review of the > > feature, to see if it has all been captured: > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > Simo. > > > > Thanks! I was not deeply involved in the review, but from the high level it > looks good to me. I at least fixed typos and improved formatting. Thanks a lot for the fixes and the improved links throughout the page :) Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Tue Jun 17 14:22:57 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 17 Jun 2014 16:22:57 +0200 Subject: [Freeipa-devel] [PATCH 0068] Fix ipa.service restart Message-ID: <1403014977.5043.1.camel@unused-4-145.brq.redhat.com> Patch attached. Ticket: https://fedorahosted.org/freeipa/ticket/4243 -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0068-Fix-ipa.service-restart.patch Type: text/x-patch Size: 987 bytes Desc: not available URL: From thozza at redhat.com Tue Jun 17 14:40:57 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 10:40:57 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0259] Fix run-time zone addition for invalid secure zones In-Reply-To: <538DAD5B.7090907@redhat.com> References: <538DAD5B.7090907@redhat.com> Message-ID: <1503286783.12039965.1403016057093.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Fix run-time zone addition for invalid secure zones. > > It is important *not* to delete invalid zones to prevent > ldap_parse_master_zoneentry() from entering infinite cycle. > > Zone addition in ldap_parse_master_zoneentry() enforces serial > write-back to LDAP. This write generates LDAP modify event which > again triggers ldap_parse_master_zoneentry() and so on. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/56 > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue Jun 17 14:41:18 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 10:41:18 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0260] Add wrappers for isc_task_*exclusive() In-Reply-To: <538F39D6.3080308@redhat.com> References: <538F39D6.3080308@redhat.com> Message-ID: <1745344319.12040088.1403016078674.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > Add wrappers for isc_task_*exclusive(). > > This patch replaces scattered isc_task_* calls and associated locking to one > place. It helps with debugging sometimes. > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue Jun 17 14:41:32 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 10:41:32 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0261-0262] Support run-time changes in idnsSecInlineSigning attribute In-Reply-To: <538F84AF.1060301@redhat.com> References: <538F84AF.1060301@redhat.com> Message-ID: <323995070.12040160.1403016092722.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > This patch set allows you to change DNSSEC zone configuration at run-time. > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From thozza at redhat.com Tue Jun 17 14:41:45 2014 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 17 Jun 2014 10:41:45 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0263-0265] Support root master zone in LDAP & Follow BIND semantics for forwarders In-Reply-To: <5391FE70.6030405@redhat.com> References: <5391FE70.6030405@redhat.com> Message-ID: <777925185.12040232.1403016105913.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello, > > This patch set contains necessary changes for supporting root master zone in > LDAP. I had to remove one hack so now we follow BIND semantics for > forwarders. > > Please see commit messages. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/122 > > -- > Petr^2 Spacek > Looks good. ACK. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com From tbordaz at redhat.com Tue Jun 17 15:59:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 17 Jun 2014 17:59:58 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <539EEB47.3030901@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> Message-ID: <53A065FE.7000401@redhat.com> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > thierry bordaz wrote: >> Hello, >> >> When a stage user is activate (ipa stageuse-activate), UUID plugin >> (DS) checks that the ipaUniqueID value of the new active user is >> 'autogenerate'. >> This is useful to prevent a provisioning systems to create Active >> user with invalid ipaUniqueID. >> Now one of the workflow step is to move a Delete user into the Stage >> container. In that case the Stage entry contains a ipaUniqueID and >> can not activate. >> >> A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' >> during that step but I wonder it it is valid to reset it. >> Also, is it valid to reset it and keep others values like >> uidNumber/gidNumber ? > I guess to walk through the logic, the unique id is there so we can > uniquely address an entry without worrying about the value changing > (like uid, name, etc). So if it is a brand new entry from the > provisioning system, yeah, we want to always set it to autogenerate. > > If a user is deleted I think we agreed that all links to that user would > be broken (memberships, hbac rules, etc) which means that it doesn't > matter if the unique id is changed I suppose. > > IMHO uidnumber/gidnumber should always be maintained. > > rob Hello Rob, Thanks for your precise feedback and sorry for my late answer. So if I try to consolidate my understandings, the workflow would be: 1. Staging (container: cn=staged users,cn=accounts,cn=provisioning,SUFFIX) * ipa stageuser-add It creates a stage entry with uidNumber: -1 gidNumber: -1 ipaUniqueID: autogenerate description: __no_upg__ manager: checks that the DN is an active user nsAccountLock: True * ipa stageuser-add --from-delete It moves a deleted entry to staging container where uidNumber: gidNumber: ipaUniqueID: autogenerate (reset to autogenerate) description: __no_upg__ (to show there is no managed group) nsAccountLock: True * ipa stageuser-activate It adds in the active container, a destination copy of a stage entry where uidNumber: gidNumber: ipaUniqueID: autogenerate (reset to autogenerate) description: value __no_upg__ is removed nsAccountLock: False DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) Then remove the source entry from the 'Staging' container. * ipa stageuser-find * ipa stageuser-show * ipa stageuser-mod nsAccountLock: can not be modify DN syntax attributes: checks that the DN is an active user * ipa stageuser-del 1. Active (container: cn=users,cn=accounts,SUFFIX) A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries and DNA plugins) * ipa user-add nsAccountLock:False * ipa user-find * ipa user-show * ipa user-mod nsAccountLock: can not be modify DN syntax attributes: checks that DN is an active user * ipa user-delete moves (modrdn) the entry under 'Delete' container but first do the following upates nsAccountLock: true all memberships attributes updated by plugins (managed entries/memberof) description: __no_upg__ DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary) * ipa user-undelete moves (modrdn) the entry under 'Active' containers. DS plugins will update the membership attributes. Before the modrdn, the updates are done: nsAccountLock: False description: value __no_upg__ is removed DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) 1. Delete (container is cn=deleted users,cn=accounts,SUFFIX) This container has no specific plugin, only user and stageuser are implemented. I would have an additional question. 'stageuser-add' is used both to create a stage entry or to recover a Delete entry into Staging container. In case of recover 'stageuser-add --from-delete', the options '--first' and '--last' are optional because the entry already exists. But these options are mandatory to create a new stage entry. Currently I made them optional (in take_param), and in case of creation of a stage entry, it displays an error message requesting these options. In short, if a flag is (--from-delete) I need options to be optional else to be mandatory. Does anyone know if it exists examples how to handle such situation ? thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Jun 17 17:35:59 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jun 2014 13:35:59 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A065FE.7000401@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> Message-ID: <53A07C7F.4060502@redhat.com> thierry bordaz wrote: > On 06/16/2014 03:04 PM, Rob Crittenden wrote: >> thierry bordaz wrote: >>> Hello, >>> >>> When a stage user is activate (ipa stageuse-activate), UUID plugin >>> (DS) checks that the ipaUniqueID value of the new active user is >>> 'autogenerate'. >>> This is useful to prevent a provisioning systems to create Active >>> user with invalid ipaUniqueID. >>> Now one of the workflow step is to move a Delete user into the Stage >>> container. In that case the Stage entry contains a ipaUniqueID and >>> can not activate. >>> >>> A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' >>> during that step but I wonder it it is valid to reset it. >>> Also, is it valid to reset it and keep others values like >>> uidNumber/gidNumber ? >> I guess to walk through the logic, the unique id is there so we can >> uniquely address an entry without worrying about the value changing >> (like uid, name, etc). So if it is a brand new entry from the >> provisioning system, yeah, we want to always set it to autogenerate. >> >> If a user is deleted I think we agreed that all links to that user would >> be broken (memberships, hbac rules, etc) which means that it doesn't >> matter if the unique id is changed I suppose. >> >> IMHO uidnumber/gidnumber should always be maintained. >> >> rob > Hello Rob, > > Thanks for your precise feedback and sorry for my late answer. > So if I try to consolidate my understandings, the workflow would be: > > 1. Staging (container: cn=staged > users,cn=accounts,cn=provisioning,SUFFIX) > * ipa stageuser-add > It creates a stage entry with > > uidNumber: -1 > gidNumber: -1 > ipaUniqueID: autogenerate > description: __no_upg__ > manager: checks that the DN is an active user > nsAccountLock: True > > * ipa stageuser-add --from-delete > > It moves a deleted entry to staging container where > > uidNumber: prevous active account> > gidNumber: prevous active account> > ipaUniqueID: autogenerate (reset to autogenerate) > description: __no_upg__ (to show there is no managed group) > nsAccountLock: True > > * ipa stageuser-activate > It adds in the active container, a destination copy of a > stage entry where > > uidNumber: force a uidNumber> > gidNumber: force a gidNumber> > ipaUniqueID: autogenerate (reset to autogenerate) > description: value __no_upg__ is removed > nsAccountLock: False > DN syntax attributes are cleared (but kept for schema > checking) except: manager, managedby and secretary > (those values must be active DN entries) > > Then remove the source entry from the 'Staging' container. > * ipa stageuser-find > * ipa stageuser-show > * ipa stageuser-mod > > nsAccountLock: can not be modify > DN syntax attributes: checks that the DN is an active user So your plugin is going to manage restriction access to nsAccountLock or is this going to be via an ACI? > * ipa stageuser-del > 1. Active (container: cn=users,cn=accounts,SUFFIX) > A new entry (user-add or stageuser-activate) is updated by DS > plugins (UUID, memberof, managed entries and DNA plugins) > > * ipa user-add > > nsAccountLock:False > > * ipa user-find > * ipa user-show > * ipa user-mod > > nsAccountLock: can not be modify > DN syntax attributes: checks that DN is an active user Why can't nsAccountLock be modified, or was this a cut-n-paste error? > * ipa user-delete > moves (modrdn) the entry under 'Delete' container but first > do the following upates > > nsAccountLock: true > all memberships attributes updated by plugins (managed > entries/memberof) Just to be clear, your plugin is going to remove all of these? > description: __no_upg__ > DN syntax attributes are cleared (but kept for schema > checking) except: manager, managedby and secretary) > > > * ipa user-undelete > > moves (modrdn) the entry under 'Active' containers. DS > plugins will update the membership attributes. Before the > modrdn, the updates are done: > > nsAccountLock: False > description: value __no_upg__ is removed > DN syntax attributes are cleared (but kept for schema > checking) except: manager, managedby and secretary > (those values must be active DN entries) > > 1. Delete (container is cn=deleted users,cn=accounts,SUFFIX) > This container has no specific plugin, only user and stageuser > are implemented. > > > > I would have an additional question. 'stageuser-add' is used both to > create a stage entry or to recover a Delete entry into Staging > container. > In case of recover 'stageuser-add --from-delete', the > options '--first' and '--last' are optional because the entry > already exists. > But these options are mandatory to create a new stage entry. > Currently I made them optional (in take_param), and in case of > creation of a stage entry, it displays an error message requesting > these options. > In short, if a flag is (--from-delete) I need options to be optional > else to be mandatory. > Does anyone know if it exists examples how to handle such situation ? There is a module-level set of options in takes_params and a command-specific set in takes_options. I think you'll need to add these into takes_options on a per-command basis. If there is a set of identical options used in several places you can define them at the top level and add them in. See _trust_type_option in trust.py for an example. rob From tbordaz at redhat.com Tue Jun 17 18:32:10 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 17 Jun 2014 20:32:10 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A07C7F.4060502@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A07C7F.4060502@redhat.com> Message-ID: <53A089AA.1030602@redhat.com> On 06/17/2014 07:35 PM, Rob Crittenden wrote: > thierry bordaz wrote: >> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >>> thierry bordaz wrote: >>>> Hello, >>>> >>>> When a stage user is activate (ipa stageuse-activate), UUID plugin >>>> (DS) checks that the ipaUniqueID value of the new active user is >>>> 'autogenerate'. >>>> This is useful to prevent a provisioning systems to create Active >>>> user with invalid ipaUniqueID. >>>> Now one of the workflow step is to move a Delete user into the Stage >>>> container. In that case the Stage entry contains a ipaUniqueID and >>>> can not activate. >>>> >>>> A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' >>>> during that step but I wonder it it is valid to reset it. >>>> Also, is it valid to reset it and keep others values like >>>> uidNumber/gidNumber ? >>> I guess to walk through the logic, the unique id is there so we can >>> uniquely address an entry without worrying about the value changing >>> (like uid, name, etc). So if it is a brand new entry from the >>> provisioning system, yeah, we want to always set it to autogenerate. >>> >>> If a user is deleted I think we agreed that all links to that user would >>> be broken (memberships, hbac rules, etc) which means that it doesn't >>> matter if the unique id is changed I suppose. >>> >>> IMHO uidnumber/gidnumber should always be maintained. >>> >>> rob >> Hello Rob, >> >> Thanks for your precise feedback and sorry for my late answer. >> So if I try to consolidate my understandings, the workflow would be: >> >> 1. Staging (container: cn=staged >> users,cn=accounts,cn=provisioning,SUFFIX) >> * ipa stageuser-add >> It creates a stage entry with >> >> uidNumber: -1 >> gidNumber: -1 >> ipaUniqueID: autogenerate >> description: __no_upg__ >> manager: checks that the DN is an active user >> nsAccountLock: True >> >> * ipa stageuser-add --from-delete >> >> It moves a deleted entry to staging container where >> >> uidNumber: > prevous active account> >> gidNumber: > prevous active account> >> ipaUniqueID: autogenerate (reset to autogenerate) >> description: __no_upg__ (to show there is no managed group) >> nsAccountLock: True >> >> * ipa stageuser-activate >> It adds in the active container, a destination copy of a >> stage entry where >> >> uidNumber: > force a uidNumber> >> gidNumber: > force a gidNumber> >> ipaUniqueID: autogenerate (reset to autogenerate) >> description: value __no_upg__ is removed >> nsAccountLock: False >> DN syntax attributes are cleared (but kept for schema >> checking) except: manager, managedby and secretary >> (those values must be active DN entries) >> >> Then remove the source entry from the 'Staging' container. >> * ipa stageuser-find >> * ipa stageuser-show >> * ipa stageuser-mod >> >> nsAccountLock: can not be modify >> DN syntax attributes: checks that the DN is an active user > So your plugin is going to manage restriction access to nsAccountLock or > is this going to be via an ACI? Hi, my first intention was to do this in the plugin. It does not protect from a ldapmodify. ACI would be a better protection but it has overhead. > >> * ipa stageuser-del >> 1. Active (container: cn=users,cn=accounts,SUFFIX) >> A new entry (user-add or stageuser-activate) is updated by DS >> plugins (UUID, memberof, managed entries and DNA plugins) >> >> * ipa user-add >> >> nsAccountLock:False >> >> * ipa user-find >> * ipa user-show >> * ipa user-mod >> >> nsAccountLock: can not be modify >> DN syntax attributes: checks that DN is an active user > Why can't nsAccountLock be modified, or was this a cut-n-paste error? Well, I was thinking to have 'nsAccountLock: False' only in Active container. And the value is set at the transition when the entry becomes active (stageuser-activate and user-undelete) > >> * ipa user-delete >> moves (modrdn) the entry under 'Delete' container but first >> do the following upates >> >> nsAccountLock: true >> all memberships attributes updated by plugins (managed >> entries/memberof) > Just to be clear, your plugin is going to remove all of these? Here I mention membership managed by the scoping of managed entries plugin and memberof plugin. So the 'user plugin' will not wipe the memberships attributes. Now if it remains membership attributes 'user plugin' will remove them when all DN syntax attributes will be cleared (except manager/managedby/secretary). > >> description: __no_upg__ >> DN syntax attributes are cleared (but kept for schema >> checking) except: manager, managedby and secretary) >> >> >> * ipa user-undelete >> >> moves (modrdn) the entry under 'Active' containers. DS >> plugins will update the membership attributes. Before the >> modrdn, the updates are done: >> >> nsAccountLock: False >> description: value __no_upg__ is removed >> DN syntax attributes are cleared (but kept for schema >> checking) except: manager, managedby and secretary >> (those values must be active DN entries) >> >> 1. Delete (container is cn=deleted users,cn=accounts,SUFFIX) >> This container has no specific plugin, only user and stageuser >> are implemented. >> >> >> >> I would have an additional question. 'stageuser-add' is used both to >> create a stage entry or to recover a Delete entry into Staging >> container. >> In case of recover 'stageuser-add --from-delete', the >> options '--first' and '--last' are optional because the entry >> already exists. >> But these options are mandatory to create a new stage entry. >> Currently I made them optional (in take_param), and in case of >> creation of a stage entry, it displays an error message requesting >> these options. >> In short, if a flag is (--from-delete) I need options to be optional >> else to be mandatory. >> Does anyone know if it exists examples how to handle such situation ? > There is a module-level set of options in takes_params and a > command-specific set in takes_options. I think you'll need to add these > into takes_options on a per-command basis. If there is a set of > identical options used in several places you can define them at the top > level and add them in. See _trust_type_option in trust.py for an example. Great !! thanks a lot I will have a look thanks thierry > > rob > From simo at redhat.com Tue Jun 17 18:39:30 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 14:39:30 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A065FE.7000401@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> Message-ID: <1403030370.12884.9.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > * ipa stageuser-add --from-delete > > It moves a deleted entry to staging container where > > uidNumber: prevous active account> > gidNumber: prevous active account> > ipaUniqueID: autogenerate (reset to autogenerate) Why are you resetting the unique id ? > description: __no_upg__ (to show there is no managed > group) > nsAccountLock: True -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Jun 17 18:43:45 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 17 Jun 2014 20:43:45 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <1403030370.12884.9.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> Message-ID: <53A08C61.4040908@redhat.com> On 06/17/2014 08:39 PM, Simo Sorce wrote: > On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: >> * ipa stageuser-add --from-delete >> >> It moves a deleted entry to staging container where >> >> uidNumber: > prevous active account> >> gidNumber: > prevous active account> >> ipaUniqueID: autogenerate (reset to autogenerate) > Why are you resetting the unique id ? I can not activate a stage user that already has ipaUniqueID. The UUID IPA plugin rejects adding such entry. It is not strictly necessary to reset this value when moving the entry Delete to Staging. But later 'Staging' to 'Active' (stageuser-activate) it is required. > >> description: __no_upg__ (to show there is no managed >> group) >> nsAccountLock: True > From rcritten at redhat.com Tue Jun 17 19:23:34 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jun 2014 15:23:34 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <1403030370.12884.9.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> Message-ID: <53A095B6.3090805@redhat.com> Simo Sorce wrote: > On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: >> * ipa stageuser-add --from-delete >> >> It moves a deleted entry to staging container where >> >> uidNumber: > prevous active account> >> gidNumber: > prevous active account> >> ipaUniqueID: autogenerate (reset to autogenerate) > > Why are you resetting the unique id ? Read back a few in the thread. I suggested, perhaps incorrectly, that given that there should be no more references to the user once they go into deleted or staged, it may be ok to reset this value. rob From simo at redhat.com Tue Jun 17 19:24:38 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 15:24:38 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A08C61.4040908@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A08C61.4040908@redhat.com> Message-ID: <1403033078.12884.12.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 20:43 +0200, thierry bordaz wrote: > On 06/17/2014 08:39 PM, Simo Sorce wrote: > > On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > >> * ipa stageuser-add --from-delete > >> > >> It moves a deleted entry to staging container where > >> > >> uidNumber: >> prevous active account> > >> gidNumber: >> prevous active account> > >> ipaUniqueID: autogenerate (reset to autogenerate) > > Why are you resetting the unique id ? > I can not activate a stage user that already has ipaUniqueID. The UUID > IPA plugin rejects adding such entry. > It is not strictly necessary to reset this value when moving the entry > Delete to Staging. But later 'Staging' to 'Active' (stageuser-activate) > it is required. If someone keys something around the ipaUniqueID you cannot lose it. I wonder if we can allow setting a ipauniqueID instead of refusing, I forgot why we refuse to set values though. Maybe we can relax and just count on uniqueness plugin to reject if there is a conflict. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Jun 17 19:29:50 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 15:29:50 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A095B6.3090805@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A095B6.3090805@redhat.com> Message-ID: <1403033390.12884.14.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > >> * ipa stageuser-add --from-delete > >> > >> It moves a deleted entry to staging container where > >> > >> uidNumber: >> prevous active account> > >> gidNumber: >> prevous active account> > >> ipaUniqueID: autogenerate (reset to autogenerate) > > > > Why are you resetting the unique id ? > > Read back a few in the thread. I suggested, perhaps incorrectly, that > given that there should be no more references to the user once they go > into deleted or staged, it may be ok to reset this value. Well, let me reiterate, the deleted bucket is for those environments where they have a mandate (regulation, law, policy, etc..) to never delete users and reinstate users if they are deleted. So all uniquely identifying information should be preserved in case the object is revived. This means we need to do our best to preserve all these attributes if we can. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jun 17 19:30:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jun 2014 15:30:20 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1402925690.22737.107.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539EA290.5020604@redhat.com> <1402925690.22737.107.camel@willson.usersys.redhat.com> Message-ID: <53A0974C.3010100@redhat.com> Simo Sorce wrote: > On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote: >> On 06/13/2014 10:20 PM, Simo Sorce wrote: >> [...] >>> 2) and I think this is a MUCH bigger issue, the Admin users are >>> unbounded and pass any Access Control Check and this means they can now >>> retrieve any key for users or machines. >>> It is already bad enough that admins can unconditionally set any key, >>> but this at least leaves back a pretty big trail (the original client >>> password/key fails to work), and is a necessary evil (password resets, >>> hosts creation/recovery). >>> But I am not very comfortable with the idea an admin can retrieve any >>> key without actually ending up changing it. Petr do we have any short >>> term plan to address the Admin's super ACI ? >> >> No, nothing in the short term. > > Ok, then I think attached is the patch 0003 we want. > This changes admins superpowers to not allow ipaProtectedOperation by > default and instead adds a specific right in cn=accounts so admin can > keep fetching keytabs for any principal. We may want to turn this into a > permission with a future patch. Upgrade in F-20 fails: Upgrade failed with ACL Syntax Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write) groupdn = \22ldap:///cn=admins: Invalid syntax. IPA upgrade failed. You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in default-aci.ldif . I think the fix is to quote the whole thing like: -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";) +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)' I don't know if this is your issue or not, but after fixing that the upgrade still fails with: Upgrade failed with unknown object class "ipaVirtualOperation": 2014-06-17T19:17:20Z DEBUG Final value after applying updates 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual operations,cn=etc,dc=greyoak,dc=com 2014-06-17T19:17:20Z DEBUG objectClass: 2014-06-17T19:17:20Z DEBUG nsContainer 2014-06-17T19:17:20Z DEBUG top 2014-06-17T19:17:20Z DEBUG ipaVirtualOperation 2014-06-17T19:17:20Z DEBUG cn: 2014-06-17T19:17:20Z DEBUG request certificate 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])] 2014-06-17T19:17:20Z DEBUG Live 1, updated 1 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class "ipaVirtualOperation" On update the global admin ACI is not changed to add ipaProtectedOperation to the list of protected attributes. rob From simo at redhat.com Tue Jun 17 19:32:43 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 15:32:43 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <53A0974C.3010100@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539EA290.5020604@redhat.com> <1402925690.22737.107.camel@willson.usersys.redhat.com> <53A0974C.3010100@redhat.com> Message-ID: <1403033563.12884.17.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 15:30 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote: > >> On 06/13/2014 10:20 PM, Simo Sorce wrote: > >> [...] > >>> 2) and I think this is a MUCH bigger issue, the Admin users are > >>> unbounded and pass any Access Control Check and this means they can now > >>> retrieve any key for users or machines. > >>> It is already bad enough that admins can unconditionally set any key, > >>> but this at least leaves back a pretty big trail (the original client > >>> password/key fails to work), and is a necessary evil (password resets, > >>> hosts creation/recovery). > >>> But I am not very comfortable with the idea an admin can retrieve any > >>> key without actually ending up changing it. Petr do we have any short > >>> term plan to address the Admin's super ACI ? > >> > >> No, nothing in the short term. > > > > Ok, then I think attached is the patch 0003 we want. > > This changes admins superpowers to not allow ipaProtectedOperation by > > default and instead adds a specific right in cn=accounts so admin can > > keep fetching keytabs for any principal. We may want to turn this into a > > permission with a future patch. > > Upgrade in F-20 fails: > > Upgrade failed with ACL Syntax > Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version > 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write) > groupdn = \22ldap:///cn=admins: Invalid syntax. > IPA upgrade failed. > > You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in > default-aci.ldif . I think the fix is to quote the whole thing like: Arghh :( Let me fix that, sorry. > -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Admins are allowed to rekey any entity"; allow(write) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";) > +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0; > acl "Admins are allowed to rekey any entity"; allow(write) groupdn = > "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)' > > I don't know if this is your issue or not, but after fixing that the > upgrade still fails with: > > Upgrade failed with unknown object class "ipaVirtualOperation": I know nothing about this. I do not touch or manipulate this in any way. > 2014-06-17T19:17:20Z DEBUG Final value after applying updates > 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual > operations,cn=etc,dc=greyoak,dc=com > 2014-06-17T19:17:20Z DEBUG objectClass: > 2014-06-17T19:17:20Z DEBUG nsContainer > 2014-06-17T19:17:20Z DEBUG top > 2014-06-17T19:17:20Z DEBUG ipaVirtualOperation > 2014-06-17T19:17:20Z DEBUG cn: > 2014-06-17T19:17:20Z DEBUG request certificate > 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])] > 2014-06-17T19:17:20Z DEBUG Live 1, updated 1 > 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class > "ipaVirtualOperation" > > On update the global admin ACI is not changed to add > ipaProtectedOperation to the list of protected attributes. uhmm can you show me exactly what your current ACI looks like ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Tue Jun 17 19:36:59 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 17 Jun 2014 21:36:59 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <1403033390.12884.14.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A095B6.3090805@redhat.com> <1403033390.12884.14.camel@willson.usersys.redhat.com> Message-ID: <53A098DB.8000700@redhat.com> On 06/17/2014 09:29 PM, Simo Sorce wrote: > On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: >>>> * ipa stageuser-add --from-delete >>>> >>>> It moves a deleted entry to staging container where >>>> >>>> uidNumber: >>> prevous active account> >>>> gidNumber: >>> prevous active account> >>>> ipaUniqueID: autogenerate (reset to autogenerate) >>> Why are you resetting the unique id ? >> Read back a few in the thread. I suggested, perhaps incorrectly, that >> given that there should be no more references to the user once they go >> into deleted or staged, it may be ok to reset this value. > Well, let me reiterate, the deleted bucket is for those environments > where they have a mandate (regulation, law, policy, etc..) to never > delete users and reinstate users if they are deleted. > So all uniquely identifying information should be preserved in case the > object is revived. This means we need to do our best to preserve all > these attributes if we can. This is what is done when an Active user is deleted. uidNumber/gidNumber/ipaUniqueID are preserved. When activating a user, currently UUID plugin prevents to set a value. Should it be relaxed.. I feel not. It is a sensitive info and provisioning system should not define it. When undelete a user (move Delete->Staging), ipaUniqueID can be preserved but as the purpose of Staging entry is to become active I thought it would be better to wipe the value also at this time. thierry > > Simo. > From simo at redhat.com Tue Jun 17 19:42:41 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 15:42:41 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A098DB.8000700@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A095B6.3090805@redhat.com> <1403033390.12884.14.camel@willson.usersys.redhat.com> <53A098DB.8000700@redhat.com> Message-ID: <1403034161.12884.20.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: > On 06/17/2014 09:29 PM, Simo Sorce wrote: > > On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > >>>> * ipa stageuser-add --from-delete > >>>> > >>>> It moves a deleted entry to staging container where > >>>> > >>>> uidNumber: >>>> prevous active account> > >>>> gidNumber: >>>> prevous active account> > >>>> ipaUniqueID: autogenerate (reset to autogenerate) > >>> Why are you resetting the unique id ? > >> Read back a few in the thread. I suggested, perhaps incorrectly, that > >> given that there should be no more references to the user once they go > >> into deleted or staged, it may be ok to reset this value. > > Well, let me reiterate, the deleted bucket is for those environments > > where they have a mandate (regulation, law, policy, etc..) to never > > delete users and reinstate users if they are deleted. > > So all uniquely identifying information should be preserved in case the > > object is revived. This means we need to do our best to preserve all > > these attributes if we can. > This is what is done when an Active user is deleted. > uidNumber/gidNumber/ipaUniqueID are preserved. > When activating a user, currently UUID plugin prevents to set a value. > Should it be relaxed.. I feel not. It is a sensitive info and > provisioning system should not define it. Why is it sensitive ? A ipaUniqueID is not really sensitive, it just needs to be unique. > When undelete a user (move Delete->Staging), ipaUniqueID can be > preserved but as the purpose of Staging entry is to become active I > thought it would be better to wipe the value also at this time. I understand that (and I noted before that I think deleted->staged is a bad idea IMO :-) ), but you are wiping it only as a workaround, because the plugin prevents you from adding it. Would have you wiped it if it were not the case ? And if so, why ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jun 17 19:49:10 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jun 2014 15:49:10 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1403033563.12884.17.camel@willson.usersys.redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539EA290.5020604@redhat.com> <1402925690.22737.107.camel@willson.usersys.redhat.com> <53A0974C.3010100@redhat.com> <1403033563.12884.17.camel@willson.usersys.redhat.com> Message-ID: <53A09BB6.5020208@redhat.com> Simo Sorce wrote: > On Tue, 2014-06-17 at 15:30 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote: >>>> On 06/13/2014 10:20 PM, Simo Sorce wrote: >>>> [...] >>>>> 2) and I think this is a MUCH bigger issue, the Admin users are >>>>> unbounded and pass any Access Control Check and this means they can now >>>>> retrieve any key for users or machines. >>>>> It is already bad enough that admins can unconditionally set any key, >>>>> but this at least leaves back a pretty big trail (the original client >>>>> password/key fails to work), and is a necessary evil (password resets, >>>>> hosts creation/recovery). >>>>> But I am not very comfortable with the idea an admin can retrieve any >>>>> key without actually ending up changing it. Petr do we have any short >>>>> term plan to address the Admin's super ACI ? >>>> >>>> No, nothing in the short term. >>> >>> Ok, then I think attached is the patch 0003 we want. >>> This changes admins superpowers to not allow ipaProtectedOperation by >>> default and instead adds a specific right in cn=accounts so admin can >>> keep fetching keytabs for any principal. We may want to turn this into a >>> permission with a future patch. >> >> Upgrade in F-20 fails: >> >> Upgrade failed with ACL Syntax >> Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version >> 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write) >> groupdn = \22ldap:///cn=admins: Invalid syntax. >> IPA upgrade failed. >> >> You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in >> default-aci.ldif . I think the fix is to quote the whole thing like: > > Arghh :( > Let me fix that, sorry. > >> -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Admins are allowed to rekey any entity"; allow(write) groupdn = >> "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";) >> +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0; >> acl "Admins are allowed to rekey any entity"; allow(write) groupdn = >> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)' >> >> I don't know if this is your issue or not, but after fixing that the >> upgrade still fails with: >> >> Upgrade failed with unknown object class "ipaVirtualOperation": > > I know nothing about this. I do not touch or manipulate this in any way. Ok, I guess we'll need someone to take a look at that, maybe it's a generic 4.0 upgrade issue. > >> 2014-06-17T19:17:20Z DEBUG Final value after applying updates >> 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual >> operations,cn=etc,dc=greyoak,dc=com >> 2014-06-17T19:17:20Z DEBUG objectClass: >> 2014-06-17T19:17:20Z DEBUG nsContainer >> 2014-06-17T19:17:20Z DEBUG top >> 2014-06-17T19:17:20Z DEBUG ipaVirtualOperation >> 2014-06-17T19:17:20Z DEBUG cn: >> 2014-06-17T19:17:20Z DEBUG request certificate >> 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])] >> 2014-06-17T19:17:20Z DEBUG Live 1, updated 1 >> 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class >> "ipaVirtualOperation" >> >> On update the global admin ACI is not changed to add >> ipaProtectedOperation to the list of protected attributes. > > uhmm can you show me exactly what your current ACI looks like ? Sorry false alarm, I misread the aci output. Functionally the patch otherwise looks ok. rob From simo at redhat.com Tue Jun 17 20:01:15 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 17 Jun 2014 16:01:15 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <53A09BB6.5020208@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <5395F160.9050701@redhat.com> <1402340549.9430.58.camel@willson.usersys.redhat.com> <1402350839.9938.33.camel@ipa.example.com> <1402361909.9430.64.camel@willson.usersys.redhat.com> <1402364985.9938.45.camel@ipa.example.com> <1402416149.9430.70.camel@willson.usersys.redhat.com> <1402424863.14226.21.camel@ipa.example.com> <1402445582.29921.7.camel@willson.usersys.redhat.com> <5398C406.6060007@redhat.com> <1402525640.22737.3.camel@willson.usersys.redhat.com> <539B2CDC.4040306@redhat.com> <539B431A.10902@redhat.com> <1402690825.22737.84.camel@willson.usersys.redhat.com> <539EA290.5020604@redhat.com> <1402925690.22737.107.camel@willson.usersys.redhat.com> <53A0974C.3010100@redhat.com> <1403033563.12884.17.camel@willson.usersys.redhat.com> <53A09BB6.5020208@redhat.com> Message-ID: <1403035275.12884.21.camel@willson.usersys.redhat.com> On Tue, 2014-06-17 at 15:49 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2014-06-17 at 15:30 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Mon, 2014-06-16 at 09:53 +0200, Petr Viktorin wrote: > >>>> On 06/13/2014 10:20 PM, Simo Sorce wrote: > >>>> [...] > >>>>> 2) and I think this is a MUCH bigger issue, the Admin users are > >>>>> unbounded and pass any Access Control Check and this means they can now > >>>>> retrieve any key for users or machines. > >>>>> It is already bad enough that admins can unconditionally set any key, > >>>>> but this at least leaves back a pretty big trail (the original client > >>>>> password/key fails to work), and is a necessary evil (password resets, > >>>>> hosts creation/recovery). > >>>>> But I am not very comfortable with the idea an admin can retrieve any > >>>>> key without actually ending up changing it. Petr do we have any short > >>>>> term plan to address the Admin's super ACI ? > >>>> > >>>> No, nothing in the short term. > >>> > >>> Ok, then I think attached is the patch 0003 we want. > >>> This changes admins superpowers to not allow ipaProtectedOperation by > >>> default and instead adds a specific right in cn=accounts so admin can > >>> keep fetching keytabs for any principal. We may want to turn this into a > >>> permission with a future patch. > >> > >> Upgrade in F-20 fails: > >> > >> Upgrade failed with ACL Syntax > >> Error(-5):(targetattr=\22ipaProtectedOperation;write_keys\22)(version > >> 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write) > >> groupdn = \22ldap:///cn=admins: Invalid syntax. > >> IPA upgrade failed. > >> > >> You also have $SUFFIX hardcoded as dc=ipa,dc=dev,dc=lan here and in > >> default-aci.ldif . I think the fix is to quote the whole thing like: > > > > Arghh :( > > Let me fix that, sorry. > > > >> -add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; > >> acl "Admins are allowed to rekey any entity"; allow(write) groupdn = > >> "ldap:///cn=admins,cn=groups,cn=accounts,dc=ipa,dc=dev,dc=lan";) > >> +add:aci: '(targetattr="ipaProtectedOperation;write_keys")(version 3.0; > >> acl "Admins are allowed to rekey any entity"; allow(write) groupdn = > >> "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)' > >> > >> I don't know if this is your issue or not, but after fixing that the > >> upgrade still fails with: > >> > >> Upgrade failed with unknown object class "ipaVirtualOperation": > > > > I know nothing about this. I do not touch or manipulate this in any way. > > Ok, I guess we'll need someone to take a look at that, maybe it's a > generic 4.0 upgrade issue. > > > > >> 2014-06-17T19:17:20Z DEBUG Final value after applying updates > >> 2014-06-17T19:17:20Z DEBUG dn: cn=request certificate,cn=virtual > >> operations,cn=etc,dc=greyoak,dc=com > >> 2014-06-17T19:17:20Z DEBUG objectClass: > >> 2014-06-17T19:17:20Z DEBUG nsContainer > >> 2014-06-17T19:17:20Z DEBUG top > >> 2014-06-17T19:17:20Z DEBUG ipaVirtualOperation > >> 2014-06-17T19:17:20Z DEBUG cn: > >> 2014-06-17T19:17:20Z DEBUG request certificate > >> 2014-06-17T19:17:20Z DEBUG [(0, u'objectClass', ['ipaVirtualOperation'])] > >> 2014-06-17T19:17:20Z DEBUG Live 1, updated 1 > >> 2014-06-17T19:17:20Z ERROR Upgrade failed with unknown object class > >> "ipaVirtualOperation" > >> > >> On update the global admin ACI is not changed to add > >> ipaProtectedOperation to the list of protected attributes. > > > > uhmm can you show me exactly what your current ACI looks like ? > > Sorry false alarm, I misread the aci output. > > Functionally the patch otherwise looks ok. > > rob Ok attached corrected patch to remove the embarrassing wrong suffix. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 32150 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 18 07:33:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 09:33:48 +0200 Subject: [Freeipa-devel] Packaging FreeIPA Foreman smartproxy Message-ID: <53A140DC.4050209@redhat.com> Hello all, As 4.0 release is slowly approaching I was more thinking about smartproxy package (freeipa-server-foreman-smartproxy). It is currently part of upstream git repo and if nothing changes, it would be part of FreeIPA 4.0 core packages. However, I do not see the Foreman smartproxy as the required part of core FreeIPA 4.0 with many installation, but rather as a glue plugin (important one!) between FreeIPA and Foreman that would be installed only on specialized deployments with Foreman. The plugin's release will be asynchronous to FreeIPA release process - we do not want to release FreeIPA core when the smartproxy adds new capability or calls that Foreman needs and vice versa. I see 2 options how to more forward: 1) Request a separate repo for foreman proxy on fedorahosted, like "freeipa-foreman.git" move the plugin there and build&branch&tag it asynchronously. This is IMO the cleanest solution. 2) Keep the Foreman plugin in FreeIPA tree, update Makefile and spec to move it to separate SRPM and source somehow merge the plugin and ipa branches. Feedback or other ideas welcome. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pspacek at redhat.com Wed Jun 18 07:34:48 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 Jun 2014 09:34:48 +0200 Subject: [Freeipa-devel] Packaging FreeIPA Foreman smartproxy In-Reply-To: <53A140DC.4050209@redhat.com> References: <53A140DC.4050209@redhat.com> Message-ID: <53A14118.10207@redhat.com> On 18.6.2014 09:33, Martin Kosek wrote: > 1) Request a separate repo for foreman proxy on fedorahosted, like > "freeipa-foreman.git" move the plugin there and build&branch&tag it > asynchronously. This is IMO the cleanest solution. I agree. -- Petr^2 Spacek From pviktori at redhat.com Wed Jun 18 07:54:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 09:54:53 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <53A017A8.8080105@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> <53A017A8.8080105@redhat.com> Message-ID: <53A145CD.7000500@redhat.com> On 06/17/2014 12:25 PM, Tomas Babej wrote: > > On 05/26/2014 06:20 PM, Petr Viktorin wrote: >> On 05/20/2014 06:15 PM, Tomas Babej wrote: >>> Hi, >>> >>> the following set of patches fixes: >>> >>> https://fedorahosted.org/freeipa/ticket/4274 >>> https://fedorahosted.org/freeipa/ticket/4263 >>> https://fedorahosted.org/freeipa/ticket/4324 >>> https://fedorahosted.org/freeipa/ticket/4340 >>> https://fedorahosted.org/freeipa/ticket/4341 >>> >>> and additional minor issues. >>> >>> The improvemed CI test coverage for the sudorule plugin is added as a >>> bonus. You've dropped most of the long commit messages and ticket URLs. Why? >> 0187: OK >> (Speaking of PEP8, if you could remove the baseldap star import from >> sudorule.py, it would be great...) >> >> > This one did hurt, but the star disappeared. Thank you, much appreciated. (Especially the fact that Int is no longer imported from baseldap) >> General thoughts: >> >> Would it be possible to merge schema_compat.uldif and >> install/updates/10-schema_compat.update into one file? Is the uldif >> special somehow? I guess this is a question for Rob. >> It would be nice to add a link to some schema-compat-entry-attribute >> documentation to these files. >> > I added Rob to cc. Rob, can you elaborate on this? >> 0188 - sudorule: Allow using hostmasks for setting allowed hosts If I run sudorule-add-host / sudorule-remove-host with a hostmask, but not host/hostgroup, I get prompted for host and hostgroup. I don't think that's the intended behavior. 0189: OK 0190: OK 0191: OK 0192: OK >> 0193 sudorule: Make sure all the relevant attributes are checked when >> setting category to ALL >> You're missing the `_` for the hostcategory error message. >> Did you think about using something like _("%s cannot be set to 'all' >> while there are %s")? >> > Fixed. Initially, I changed the message as you suggested, but then I > realized, that this might pose a problem for translations that do not > follow the word order in the sentence as it is defined in English language. Right, sorry for the incorrect example. You can use named substitutions for that: _("can't %(action)s while %(state)s") % {'action': 'move', 'state': 'asleep'} One more thing - the function is only called once, could you move it to the for loop? 0194: OK 0195: OK 0196-0198: OK 0199-0201: OK 0225: Looks good. Could you also document the arguments & return value in *_external_post_callback docstrings? -- Petr? From pviktori at redhat.com Wed Jun 18 08:52:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 10:52:44 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A03152.4010204@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> Message-ID: <53A1535C.2030402@redhat.com> On 06/17/2014 02:15 PM, Tomas Babej wrote: > > On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >> On 17.06.2014 11:16, Martin Kosek wrote: > Attached is a new version of patch 226, and a new patch 228, which moves > the paths from installers to the paths module. In patch 226, there's another "certificated" typo in remove_ca_cert_from_systemwide_ca_store > I greped the repository, and I do not see many paths lurking around any > more, there are only some in the error messages (as these can't be > reliably replaced automatically, and will need some manual love). > > If you see any forgotten paths, which should be added to the module, let > me know. I see another duplicate: SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = "/var/lib/sss/pubconf/krb5.include.d/" Rather than using e.g. filename = paths.VAR_KERBEROS_KRB5KDC_DIR + file It would be cleaner to use filename = os.path.join(paths.VAR_KERBEROS_KRB5KDC_DIR, file) -- Petr? From tbordaz at redhat.com Wed Jun 18 09:39:39 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 18 Jun 2014 11:39:39 +0200 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <1403034161.12884.20.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A095B6.3090805@redhat.com> <1403033390.12884.14.camel@willson.usersys.redhat.com> <53A098DB.8000700@redhat.com> <1403034161.12884.20.camel@willson.usersys.redhat.com> Message-ID: <53A15E5B.1020408@redhat.com> On 06/17/2014 09:42 PM, Simo Sorce wrote: > On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: >> On 06/17/2014 09:29 PM, Simo Sorce wrote: >>> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: >>>>>> * ipa stageuser-add --from-delete >>>>>> >>>>>> It moves a deleted entry to staging container where >>>>>> >>>>>> uidNumber: >>>>> prevous active account> >>>>>> gidNumber: >>>>> prevous active account> >>>>>> ipaUniqueID: autogenerate (reset to autogenerate) >>>>> Why are you resetting the unique id ? >>>> Read back a few in the thread. I suggested, perhaps incorrectly, that >>>> given that there should be no more references to the user once they go >>>> into deleted or staged, it may be ok to reset this value. >>> Well, let me reiterate, the deleted bucket is for those environments >>> where they have a mandate (regulation, law, policy, etc..) to never >>> delete users and reinstate users if they are deleted. >>> So all uniquely identifying information should be preserved in case the >>> object is revived. This means we need to do our best to preserve all >>> these attributes if we can. >> This is what is done when an Active user is deleted. >> uidNumber/gidNumber/ipaUniqueID are preserved. >> When activating a user, currently UUID plugin prevents to set a value. >> Should it be relaxed.. I feel not. It is a sensitive info and >> provisioning system should not define it. > Why is it sensitive ? A ipaUniqueID is not really sensitive, it just > needs to be unique. Ok. I believed it was :-) I have a concern, if a provisioning system is free to define this value, I wonder if it can create problem for replication. For example a provisioning system creates two staging entries on different servers but with the same ipaUniqueID value. If the entries are activated at the same time, the ADDs operation (activation) will not be replicated because the attribute uniqueness plugin will reject it. This case existed before if two IPA uuid plugins generated identical value on different replica. But the probability was less than if the provisioning system is free to set it. > >> When undelete a user (move Delete->Staging), ipaUniqueID can be >> preserved but as the purpose of Staging entry is to become active I >> thought it would be better to wipe the value also at this time. > I understand that (and I noted before that I think deleted->staged is a > bad idea IMO :-) ), but you are wiping it only as a workaround, because > the plugin prevents you from adding it. Would have you wiped it if it > were not the case ? And if so, why ? That is correct. I thought to wipe it because the plugin rejected values others than 'autogenerate'. To relax the control that rejects values other than 'autogenerate', I need to modify the plugin. Should it be done under an other ticket or can it be part of this RFE ? thanks thierry > > Simo. > > From mkosek at redhat.com Wed Jun 18 10:47:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 12:47:38 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A065FE.7000401@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> Message-ID: <53A16E4A.10300@redhat.com> On 06/17/2014 05:59 PM, thierry bordaz wrote: > On 06/16/2014 03:04 PM, Rob Crittenden wrote: ... > Thanks for your precise feedback and sorry for my late answer. > So if I try to consolidate my understandings, the workflow would be: > > 1. Staging (container: cn=staged > users,cn=accounts,cn=provisioning,SUFFIX) > * ipa stageuser-add > It creates a stage entry with > > uidNumber: -1 > gidNumber: -1 > ipaUniqueID: autogenerate > description: __no_upg__ > manager: checks that the DN is an active user > nsAccountLock: True I was thinking about the nsAccountLock part again. Should we really force provisioning systems to set it to True for staged users? Should we even manipulate it in stageduser plugin? The original reason why I proposed it in http://www.freeipa.org/page/V4/User_Life-Cycle_Management is to prevent LDAP BINDs on such user or Kerberos authentication on such user. Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? This would allow us to be sure that nobody can bind/authenticate to these users without having to manipulate nsAccountLock attribute. The only downside is that this would not be effective in older FreeIPA versions, but AFAIR, we specified that if User Life Cycle is enabled, all server should have at least 4.1 - otherwise for example deleted users would be put to the special container or old servers would not have the appropriate DS plugins updates. Martin From mkosek at redhat.com Wed Jun 18 11:03:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 13:03:32 +0200 Subject: [Freeipa-devel] [PATCH 0227] sudorule: Allow unsetting sudoorder In-Reply-To: <53A01800.7000005@redhat.com> References: <53A01800.7000005@redhat.com> Message-ID: <53A17204.7020607@redhat.com> On 06/17/2014 12:27 PM, Tomas Babej wrote: > Hi, > > After setting sudoorder, you are unable to unset it, since the > check for uniqueness of order of sudorules is applied incorrectly. > > Fix the behaviour and cover it in the test suite. > > https://fedorahosted.org/freeipa/ticket/4360 ACK. Pushed to master: 637ef11109600d87bfb783eadd4b6401fa58d468 Martin From pvoborni at redhat.com Wed Jun 18 11:11:07 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 Jun 2014 13:11:07 +0200 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <5399C659.30109@redhat.com> References: <538473E0.6070702@redhat.com> <5399C659.30109@redhat.com> Message-ID: <53A173CB.3060203@redhat.com> On 12.6.2014 17:25, Endi Sukma Dewata wrote: > On 5/27/2014 6:15 AM, Petr Vobornik wrote: >> This is just a first draft of implementation of >> https://fedorahosted.org/freeipa/ticket/4345 >> >> It introduces a `freeipa/extend` module which should serve as a more >> stable API for Web UI plugins. I think it requires further discussion - >> what to have there, the level of abstraction... >> >> Other patches fixes navigation/router to support custom URL path >> patterns. >> >> The usage of facet.create_hash(router) method in patch #649 is >> questionable. >> >> The WIP patch contains an example of a plugin which uses this >> functionality. > > Some comments: > > 1. As discussed on IRC, the plugin is causing an error due to missing > extend.js. This needs to be fixed. Fixed > > 2. Also discussed, a base widget class for StateWidget might help > providing a structure and simplifying the plugin code by defining the > default widget behavior (e.g. event registration). Out of scope of this ticket. > > 3. Related to inheritance, instead of conditionally calling a method > like this: > > if (facet.create_hash) return facet.create_hash(router); > // otherwise, do the default behavior > > if we use inheritance it could be simplified like this: > > return facet.create_hash(router); > > So the method will "do the default behavior" as defined in the base > class unless it's overridden by the subclass. > > 4. I agree that the facet shouldn't define the hash. The hash should be > part of the plugin declaration. Ideally, facet should be router agnostic. We need a mechanism of mapping facet's state to hash and vice versa. Originally I did not want to do it now because it requires bigger refactoring of a router. While I was designing it, I ended up with a patch - attached. It's a replacement for original patch #649. Patch #651 and example plugin are updated accordingly. Basically I refactored router's `navigate_to_*`, `_create_*_hash` and `*_route_handler` methods into separate classes which are registered and mapped to facets. All in navigation.routing module. Btw, can you think of some better name(s)/placement for the module? > > 5. Also discussed about moving away from declarative entity/facet > definitions into template-based framework. It could help reduce the code > complexity. > Out of scope of this ticket. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0718-API-browser-plugin.patch Type: text/x-patch Size: 14361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0651-1-webui-plugin-API.patch Type: text/x-patch Size: 3913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0650-1-webui-add-parent-link-to-widgets-in-ContainerMixin.patch Type: text/x-patch Size: 1860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0649-1-webui-generic-routing.patch Type: text/x-patch Size: 30274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0648-1-webui-support-standalone-facets-in-navigation-module.patch Type: text/x-patch Size: 2206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0647-1-webui-fix-excessive-registration-of-state-change-eve.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 18 11:21:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 13:21:58 +0200 Subject: [Freeipa-devel] [PATCH] 0589 Do not fail if there are multiple nsDS5ReplicaId values in cn=replication, cn=etc Message-ID: <53A17656.4020401@redhat.com> https://fedorahosted.org/freeipa/ticket/4375 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0589-Do-not-fail-if-there-are-multiple-nsDS5ReplicaId-val.patch Type: text/x-patch Size: 1905 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 18 11:22:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 Jun 2014 13:22:05 +0200 Subject: [Freeipa-devel] [PATCH] 667 webui-ci: adjust tests to dns changes Message-ID: <53A1765D.90009@redhat.com> All DNS Zone names must be fully qualified. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0667-webui-ci-adjust-tests-to-dns-changes.patch Type: text/x-patch Size: 1431 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 18 11:22:10 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 18 Jun 2014 13:22:10 +0200 Subject: [Freeipa-devel] [PATCH] 668 webui: fix field's default value Message-ID: <53A17662.107@redhat.com> Fields with default value, such as DNS Zone's idnsforwardpolicy, were marked as dirty when no value was loaded and when default value of input control was other than empty. Fixes regression in DNS Zone details facet - facet is always dirty. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0668-webui-fix-field-s-default-value.patch Type: text/x-patch Size: 989 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 18 11:42:08 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Jun 2014 13:42:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> Message-ID: <1403091728.20101.5.camel@unused-4-145.brq.redhat.com> Rebased patches with pep8 fixes attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0052-5-Separate-master-and-forward-DNS-zones.patch Type: text/x-patch Size: 21327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0053-5-Prevent-commands-to-modify-different-type-of-a-zone.patch Type: text/x-patch Size: 11522 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-5-Create-BASE-zone-class.patch Type: text/x-patch Size: 38601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0055-5-Tests-DNS-forward-zones.patch Type: text/x-patch Size: 29017 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 18 11:44:42 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Jun 2014 13:44:42 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> Message-ID: <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: > Patches attached, require patches mbasti 0052-0055. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased patches attached. PEP8 fixes. -- Martin^2 Basti From mbasti at redhat.com Wed Jun 18 11:46:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Jun 2014 13:46:10 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> Message-ID: <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: > On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: > > Patches attached, require patches mbasti 0052-0055. > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > Rebased patches attached. > PEP8 fixes. > Sorry, patches are here -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0066-2-Added-upgrade-step-executed-before-schmema-is-upgrad.patch Type: text/x-patch Size: 6683 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0067-2-Upgrade-special-master-zones-to-forward-zones.patch Type: text/x-patch Size: 8755 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 18 12:04:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Jun 2014 14:04:30 +0200 Subject: [Freeipa-devel] [PATCH 0069] Missing dependency in BUILD.txt Message-ID: <1403093070.20101.10.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0069-Missing-dependency-in-BUILD.txt.patch Type: text/x-patch Size: 1249 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 18 12:05:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 14:05:20 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <539F10B6.80507@redhat.com> References: <539B17D6.6040908@redhat.com> <539F10B6.80507@redhat.com> Message-ID: <53A18080.4030104@redhat.com> On 06/16/2014 05:43 PM, Petr Viktorin wrote: > On 06/13/2014 05:25 PM, Petr Viktorin wrote: >> >> With the first patch, old SYSTEM permissions can be replaced. The "Read >> DNS Entries" did not have an associated ACI, but was rather rolled into >> a single ACI with the managedBy rule used for per-zone access. >> (and before that it was part of a deny rule.) >> We can't remove this permission in an update file, because we need to >> check that it is indeed an old SYSTEM perm and not a new one with the >> same name. >> >> >> The second patch converts DNS permissions to managed. >> >> The ACIs are put directly in $SUFFIX, because the cn=dns subtree does >> not exist in all installations. >> >> I hope to change this for https://fedorahosted.org/freeipa/ticket/4058, >> when I've thought more about relationships between plugins, packages, >> install options, and the updater. > > Testing more, I found a benign bug: the updater complained if the cn=dns > container was missing. Fixed here. > > Also, the update_dns_permissions plugin is now now obsolete, the third patch > removes it. > 583.2: OK 584.2: 1) Typo in description: Convewrt the existing default permissions. 2) What would you like to do with per-zone permissions? # ipa dnszone-add-permission example.com ------------------------------------------------------ Added system permission "Manage DNS zone example.com." ------------------------------------------------------ Manage DNS zone example.com. # ipa permission-show 'Manage DNS zone example.com.' Permission name: Manage DNS zone example.com. Granted to Privilege: test2 Indirect Member of roles: test2 Should the command be converted to add V2 permissions? We would have to also deal with conversion from old DNS zone permissions to permissionsv2 though. 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS entries in a zone" permissions to managed? It would make their maintenance and updates much easier, we would also get rid of more updates in update files. The only problem I see is how to define 'userattr = "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be rough at the moment. Otherwise the changes worked fine, thanks! Martin From jcholast at redhat.com Wed Jun 18 12:09:23 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Jun 2014 14:09:23 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <539EFA64.3020005@redhat.com> References: <52A0817E.2080002@redhat.com> <1389276256.26102.211.camel@willson.li.ssimo.org> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> <539EE99C.5010909@redhat.com> <539EFA64.3020005@redhat.com> Message-ID: <53A18173.6060903@redhat.com> On 16.6.2014 16:08, Martin Kosek wrote: > On 06/16/2014 02:57 PM, Jan Cholasta wrote: >> On 16.6.2014 13:31, Martin Kosek wrote: >>> On 06/11/2014 02:59 PM, Jan Cholasta wrote: >>>> On 11.6.2014 13:29, Martin Kosek wrote: >>>>> On 06/11/2014 10:58 AM, Jan Cholasta wrote: >>>>>> On 10.6.2014 09:55, Martin Kosek wrote: >>>>>>> On 06/06/2014 12:50 PM, Jan Cholasta wrote: >>>>>>>> On 23.1.2014 14:34, Jan Cholasta wrote: >>>>>>>>> On 22.1.2014 16:43, Simo Sorce wrote: >>>>>>>>>> On Wed, 2014-01-22 at 16:05 +0100, Jan Cholasta wrote: >>>>>>>>>>> On 22.1.2014 15:34, Simo Sorce wrote: >>>>>>>>>>>> On Wed, 2014-01-22 at 10:40 +0100, Jan Cholasta wrote: >>>>>>>>>>>>> On 21.1.2014 17:12, Simo Sorce wrote: >>>>>>>>>>>>>> Later in the patch you seem to be changing from needing >>>>>>>>>>>>>> managedby_host >>>>>>>>>>>>>> to needing write access to an entry, I am not sure I understand >>>>>>>>>>>>>> why that >>>>>>>>>>>>>> was changed. not saying it is necessarily wrong, but why the >>>>>>>>>>>>>> original >>>>>>>>>>>>>> check is not right anymore ? >>>>>>>>>>>>> >>>>>>>>>>>>> The original check is wrong, see >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> The check in my patch allows SAN only if the requesting host has write >>>>>>>>>>>>> access to all of the SAN services. I'm not entirely sure if this is >>>>>>>>>>>>> right, but even if it is not, I think we should still check for write >>>>>>>>>>>>> access to the SAN services, so that access control can be (partially) >>>>>>>>>>>>> handled by ACIs. >>>>>>>>>>>> >>>>>>>>>>>> Right, I remembered that comment, but it just says to check the right >>>>>>>>>>>> object's managed-by, here instead you changed it to check if you can >>>>>>>>>>>> write the usercertificate. >>>>>>>>>>>> >>>>>>>>>>>> I guess it is the same *if* there is an ACI that gives write permission >>>>>>>>>>>> when the host is in the managed-by attribute, is that the reasoning ? >>>>>>>>>>> >>>>>>>>>>> Exactly. The ACIs that allow this by default are named "Hosts can manage >>>>>>>>>>> service Certificates and kerberos keys" and "Hosts can manage other host >>>>>>>>>>> Certificates and kerberos keys". >>>>>>>>>>> >>>>>>>>>>> I think the check can be extended to users as well, so that requesting >>>>>>>>>>> certificate with SAN is allowed only to users which have write access to >>>>>>>>>>> the SAN services. >>>>>>>>> >>>>>>>>> I have done the modification, see attached patches. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sounds good to me then, thanks for explaining. >>>>>>>>>> >>>>>>>>>> The patches also look good, but I would like someone to give them a try >>>>>>>>>> for a formal ack. >>>>>>>>> >>>>>>>>> OK, thanks. >>>>>>>>> >>>>>>>> >>>>>>>> Bump. >>>>>>>> >>>>>>>> I have added stricter validation of subject alt names as well as >>>>>>>> certificate >>>>>>>> extensions in general to the second patch. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>>> Updated patches attached. >>>>>>>> >>>>>>>> Note that you will need python-nss 0.15 in order to test, you can get a >>>>>>>> RPM for >>>>>>>> Fedora here: . >>>>>>> >>>>>>> John, do you think we could build python-nss 0.15 also for Fedora 20? The >>>>>>> fix >>>>>>> incorporated in it is pretty important to warrant bugfix update in bodhi. It >>>>>>> would also allow FreeIPA 4.0 to be installed on Fedora 20. >>>>>>> >>>>>>>> Also, resubmitting HTTP and LDAP Server-Cert certmonger requests does not >>>>>>>> work, >>>>>>>> because . >>>>>>> >>>>>>> This worked for me, I suspect this is a DS bug. More info in the ticket. >>>>>>> >>>>>>> Now back to review of the patch: >>>>>>> >>>>>>> 210.4: looks ok >>>>>>> 234.4: >>>>>>> >>>>>>> 1) Virtual operation "request certificate with subjectaltname" should be a >>>>>>> member of Certificate Administrators privilege >>>>>> >>>>>> OK. >>>>>> >>>>>>> >>>>>>> >>>>>>> 2) I would write "Request Certificate With SubjectAltName" with "with" >>>>>>> instead >>>>>>> of "With". I.e.: >>>>>>> Request Certificate with SubjectAltName >>>>>> >>>>>> OK. >>>>>> >>>>>>> >>>>>>> >>>>>>> 3) Why is the extension check only enforced for non-hosts? >>>>>>> >>>>>>> + if not bind_principal.startswith('host/'): >>>>>>> + for ext in extensions: >>>>>>> + operation = self._allowed_extensions.get(ext) >>>>>>> + if operation: >>>>>>> + self.check_access(operation) >>>>>>> >>>>>>> My tricky certmonger request passed: >>>>>>> >>>>>>> # ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g >>>>>>> 2048 -r >>>>>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>>>>> test2.example.com >>>>>>> -E mkosek at redhat.com >>>>>>> >>>>>>> while when I posted the same CSR as privileged user, it was rejected: >>>>>>> >>>>>>> $ klist >>>>>>> Ticket cache: KEYRING:persistent:962000003:962000003 >>>>>>> Default principal: fbar at IDM.LAB.ENG.BRQ.REDHAT.COM >>>>>>> >>>>>>> $ ipa cert-request --principal test/`hostname` certmonger.csr >>>>>>> ipa: ERROR: invalid 'csr': subject alt name type RFC822 Name is forbidden >>>>>> >>>>>> Right, I meant to NACK myself, but you were faster. Fixed. >>>>>> >>>>>>> >>>>>>> >>>>>>> 4) Regular users cannot read Virtual Operations, so even if I assign them a >>>>>>> permission, command is refused: >>>>>>> >>>>>>> $ ipa cert-request --principal test/`hostname` openssl.csr >>>>>>> ipa: ERROR: Insufficient access: No such virtual command >>>>>>> >>>>>>> I think we will need to create new managed permission "Read Virtual >>>>>>> Operations" >>>>>>> and assign it to "Certificate Administrators" privilege by default as this >>>>>>> privilege has the virtual operation permissions assigned. Petr3, what is >>>>>>> your >>>>>>> take on this? >>>>>>> >>>>>>> Otherwise the patch worked well for me, the authorization part looked OK. My >>>>>>> biggest concern was just the host/user differentiation wrt unknown >>>>>>> subjectaltname types. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> Updated patches attached. >>>>>> >>>>> >>>>> 1) I could not compile the patch set: >>>>> >>>>> $ make rpms >>>>> ... >>>>> if [ "" != "yes" ]; then \ >>>>> ./makeapi --validate; \ >>>>> ./makeaci --validate; \ >>>>> fi >>>>> Traceback (most recent call last): >>>>> File "./makeapi", line 457, in >>>>> sys.exit(main()) >>>>> File "./makeapi", line 428, in main >>>>> api.finalize() >>>>> File "/root/freeipa-master/ipalib/plugable.py", line 708, in finalize >>>>> self.__do_if_not_done('load_plugins') >>>>> File "/root/freeipa-master/ipalib/plugable.py", line 482, in >>>>> __do_if_not_done >>>>> getattr(self, name)() >>>>> File "/root/freeipa-master/ipalib/plugable.py", line 645, in load_plugins >>>>> self.import_plugins('ipalib') >>>>> File "/root/freeipa-master/ipalib/plugable.py", line 689, in >>>>> import_plugins >>>>> __import__(fullname) >>>>> File "/root/freeipa-master/ipalib/plugins/cert.py", line 30, in >>>>> from ipalib import pkcs10 >>>>> File "/root/freeipa-master/ipalib/pkcs10.py", line 77 >>>>> .replace('@', '\\@') >>>>> ... >>>>> >>>>> The rest of the notes are thus only from reading. >>>> >>>> Sorry, last minute change gone wrong. >>>> >>>>> >>>>> 2) There are lines like >>>>> >>>>> + if name_type == 'Other Name (OID.1.3.6.1.5.2.2)': >>>>> >>>>> >>>>> or >>>>> >>>>> + if name_type not in ('DNS name', >>>>> + 'Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>>>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>>>> >>>>> or >>>>> >>>>> + elif name_type in ('Other Name (OID.1.3.6.1.4.1.311.20.2.3)', >>>>> + 'Other Name (OID.1.3.6.1.5.2.2)'): >>>>> >>>>> Can we do something better? Getting the extension type based on it's >>>>> description seems extremely unstable to me. >>>> >>>> These are SAN types, not extension types. Unfortunately the textual >>>> descriptions are the only SAN type representation available in python-nss which >>>> includes OIDs of other names. >>>> >>>>> >>>>> Can we for example modify get_subjectaltname to get the type based on >>>>> CertificateExtension object's oid or oid_tag attributes? >>>> >>>> No, see above. >>>> >>>>> >>>>> I would rather see get_subjectaltname return solid type like >>>>> CERT_EXTENSION_DNS_NAME defined in pkcs10.py than consumers comparing >>>>> descriptions. It would be more readable, too. >>>> >>>> Done. >>>> >>>>> >>>>> Martin >>>>> >>>> >>>> Updated patches attached. >>> >>> 1) We still miss the managed permission allowing Certificate Administrators to >>> read Virtual Commands >> >> I was under the impression that Petr would fix this. > > Previously I was asking for consultancy, new managed permissions should make it > much easier to add new ACIs, so I think you should be able to do it. If not, > you can ask Petr for help. Added, see patch 300. > > ... >>> 3) I am thinking why do we need to introduce all the ASN parsing? I am talking >>> about _decode_krb5principalname and others. If we do not use the result >>> anywhere, why should we include this part at all? >> >> To work around shortcomings of NSS/python-nss. In particular, >> _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. >> This is necessary because certmonger puts such SANs in certificate requests it >> generates. > > I know, but we do not use the values besides DNS SAN type, right? I was just > afraid that a decode error in a decoding of an unused SAN type would cause the > entire CSR processing to crash. If we do not allow principal name SANs, requests from certmonger will fail. If we allow them, but ignore them, you could request a certificate for an arbitrary unrelated principal. Thus, the only thing we can do is allow them and validate them, which is what the patch does and why decoding KRB5PrincipalName is necessary. > > >>> 4) I get crash in the certmonger request: >>> >>> ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D test2.example.com >>> -E mkosek at redhat.com >>> >>> # ipa-getcert list -i test-san-1 >>> Number of certificates and requests being tracked: 8. >>> Request ID 'test-san-1': >>> status: CA_UNREACHABLE >>> ca-error: Server failed request, will retry: -504 (HTTP response code is >>> 500, >>> not 200). >>> stuck: yes >>> >>> >>> HTTPD traceback >>> [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> Traceback (most recent call last): >>> [Mon Jun 16 13:06:14.528844 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/share/ipa/wsgi.py", line 49, in application >>> [Mon Jun 16 13:06:14.529466 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> return api.Backend.wsgi_dispatch(environ, start_response) >>> [Mon Jun 16 13:06:14.529614 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 251, in >>> __call__ >>> [Mon Jun 16 13:06:14.553116 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> return self.route(environ, start_response) >>> [Mon Jun 16 13:06:14.553261 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 263, in >>> route >>> [Mon Jun 16 13:06:14.553410 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> return app(environ, start_response) >>> [Mon Jun 16 13:06:14.553604 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 637, in >>> __call__ >>> [Mon Jun 16 13:06:14.553749 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> environ, start_response) >>> [Mon Jun 16 13:06:14.553895 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 397, in >>> __call__ >>> [Mon Jun 16 13:06:14.554023 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> response = self.wsgi_execute(environ) >>> [Mon Jun 16 13:06:14.554138 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 343, in >>> wsgi_execute >>> [Mon Jun 16 13:06:14.554276 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> result = self.Command[name](*args, **options) >>> [Mon Jun 16 13:06:14.554413 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in >>> __call__ >>> [Mon Jun 16 13:06:14.585933 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> ret = self.run(*args, **options) >>> [Mon Jun 16 13:06:14.586170 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run >>> [Mon Jun 16 13:06:14.586305 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> return self.execute(*args, **options) >>> [Mon Jun 16 13:06:14.586490 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 316, in >>> execute >>> [Mon Jun 16 13:06:14.592390 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> subjectaltname = pkcs10.get_subjectaltname(csr) or () >>> [Mon Jun 16 13:06:14.592565 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/ipalib/pkcs10.py", line 129, in >>> get_subjectaltname >>> [Mon Jun 16 13:06:14.596411 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> san = decoder.decode(san, asn1Spec=_SubjectAltName())[0] >>> [Mon Jun 16 13:06:14.596555 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >>> 792, in __call__ >>> [Mon Jun 16 13:06:14.598268 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> stGetValueDecoder, self, substrateFun >>> [Mon Jun 16 13:06:14.598404 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >>> 367, in valueDecoder >>> [Mon Jun 16 13:06:14.598534 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> component, head = decodeFun(head, asn1Spec) >>> [Mon Jun 16 13:06:14.598633 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> File "/usr/lib/python2.7/site-packages/pyasn1/codec/ber/decoder.py", line >>> 798, in __call__ >>> [Mon Jun 16 13:06:14.598746 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> '%r not in asn1Spec: %r' % (tagSet, asn1Spec) >>> [Mon Jun 16 13:06:14.598954 2014] [:error] [pid 12941] [remote 10.34.47.236:12] >>> PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: >>> _GeneralName() >> >> What version of certmonger are you using? > > Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access > to my VM atm). Is this a bug in certmonger? No, it's bug in my code. Fixed. > > I would like FreeIPA 4.0 to run on vanilla Fedora 20, so far it does, the > required python-nss 0.15 is already on it's way to stable updates. > > Thanks, > Martin > Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was hitting with patch 234. Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.7-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.7-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 16019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-300-Add-virtual-operations-read-permission.patch Type: text/x-patch Size: 4537 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-301-Remove-GetEffectiveRights-control-when-ldap2.get_eff.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 18 12:20:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 14:20:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <53A18080.4030104@redhat.com> References: <539B17D6.6040908@redhat.com> <539F10B6.80507@redhat.com> <53A18080.4030104@redhat.com> Message-ID: <53A1840D.9050009@redhat.com> On 06/18/2014 02:05 PM, Martin Kosek wrote: > On 06/16/2014 05:43 PM, Petr Viktorin wrote: >> On 06/13/2014 05:25 PM, Petr Viktorin wrote: >>> >>> With the first patch, old SYSTEM permissions can be replaced. The "Read >>> DNS Entries" did not have an associated ACI, but was rather rolled into >>> a single ACI with the managedBy rule used for per-zone access. >>> (and before that it was part of a deny rule.) >>> We can't remove this permission in an update file, because we need to >>> check that it is indeed an old SYSTEM perm and not a new one with the >>> same name. >>> >>> >>> The second patch converts DNS permissions to managed. >>> >>> The ACIs are put directly in $SUFFIX, because the cn=dns subtree does >>> not exist in all installations. >>> >>> I hope to change this for https://fedorahosted.org/freeipa/ticket/4058, >>> when I've thought more about relationships between plugins, packages, >>> install options, and the updater. >> >> Testing more, I found a benign bug: the updater complained if the cn=dns >> container was missing. Fixed here. >> >> Also, the update_dns_permissions plugin is now now obsolete, the third patch >> removes it. >> > > 583.2: OK > > 584.2: > > 1) Typo in description: > Convewrt the existing default permissions. Thanks for the catch, I'll fix it before pushing. > > 2) What would you like to do with per-zone permissions? > > # ipa dnszone-add-permission example.com > ------------------------------------------------------ > Added system permission "Manage DNS zone example.com." > ------------------------------------------------------ > Manage DNS zone example.com. > > # ipa permission-show 'Manage DNS zone example.com.' > Permission name: Manage DNS zone example.com. > Granted to Privilege: test2 > Indirect Member of roles: test2 > > Should the command be converted to add V2 permissions? We would have to also > deal with conversion from old DNS zone permissions to permissionsv2 though. > > 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS > entries in a zone" permissions to managed? It would make their maintenance and > updates much easier, we would also get rid of more updates in update files. > > The only problem I see is how to define 'userattr = > "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be > rough at the moment. I'd like to leave these two cases until after the "regular" default permissions are done. The regular permissions must be converted now because when you "touch" them with 4.0 permission-mod, they get converted to V2 and the updater will no longer count them as old default permissions. So we need to convert all of them right now. The SYSTEM ones can't be modified so they could theoretically wait till 4.1+. There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'. For the second case, yes, adding more bind rule types will need some work (and a new permission flag). I'd like to combine that work with the selfservice/delegation, which also need special bind rules. > > Otherwise the changes worked fine, thanks! > > Martin > -- Petr? From mkosek at redhat.com Wed Jun 18 12:23:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 14:23:26 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <53A1840D.9050009@redhat.com> References: <539B17D6.6040908@redhat.com> <539F10B6.80507@redhat.com> <53A18080.4030104@redhat.com> <53A1840D.9050009@redhat.com> Message-ID: <53A184BE.6000107@redhat.com> On 06/18/2014 02:20 PM, Petr Viktorin wrote: > On 06/18/2014 02:05 PM, Martin Kosek wrote: >> On 06/16/2014 05:43 PM, Petr Viktorin wrote: >>> On 06/13/2014 05:25 PM, Petr Viktorin wrote: >>>> >>>> With the first patch, old SYSTEM permissions can be replaced. The "Read >>>> DNS Entries" did not have an associated ACI, but was rather rolled into >>>> a single ACI with the managedBy rule used for per-zone access. >>>> (and before that it was part of a deny rule.) >>>> We can't remove this permission in an update file, because we need to >>>> check that it is indeed an old SYSTEM perm and not a new one with the >>>> same name. >>>> >>>> >>>> The second patch converts DNS permissions to managed. >>>> >>>> The ACIs are put directly in $SUFFIX, because the cn=dns subtree does >>>> not exist in all installations. >>>> >>>> I hope to change this for https://fedorahosted.org/freeipa/ticket/4058, >>>> when I've thought more about relationships between plugins, packages, >>>> install options, and the updater. >>> >>> Testing more, I found a benign bug: the updater complained if the cn=dns >>> container was missing. Fixed here. >>> >>> Also, the update_dns_permissions plugin is now now obsolete, the third patch >>> removes it. >>> >> >> 583.2: OK >> >> 584.2: >> >> 1) Typo in description: >> Convewrt the existing default permissions. > > Thanks for the catch, I'll fix it before pushing. > >> >> 2) What would you like to do with per-zone permissions? >> >> # ipa dnszone-add-permission example.com >> ------------------------------------------------------ >> Added system permission "Manage DNS zone example.com." >> ------------------------------------------------------ >> Manage DNS zone example.com. >> >> # ipa permission-show 'Manage DNS zone example.com.' >> Permission name: Manage DNS zone example.com. >> Granted to Privilege: test2 >> Indirect Member of roles: test2 >> >> Should the command be converted to add V2 permissions? We would have to also >> deal with conversion from old DNS zone permissions to permissionsv2 though. >> >> 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS >> entries in a zone" permissions to managed? It would make their maintenance and >> updates much easier, we would also get rid of more updates in update files. >> >> The only problem I see is how to define 'userattr = >> "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be >> rough at the moment. > > I'd like to leave these two cases until after the "regular" default permissions > are done. > The regular permissions must be converted now because when you "touch" them > with 4.0 permission-mod, they get converted to V2 and the updater will no > longer count them as old default permissions. So we need to convert all of them > right now. The SYSTEM ones can't be modified so they could theoretically wait > till 4.1+. > There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'. Ok, not a blocker. > For the second case, yes, adding more bind rule types will need some work (and > a new permission flag). I'd like to combine that work with the > selfservice/delegation, which also need special bind rules. Ok, please make sure that we have the ideas and missing TODOs reflected in tickets. Given these arrangements, ACK to the patch set as is (with the typo fix). Martin From alee at redhat.com Wed Jun 18 12:42:09 2014 From: alee at redhat.com (Ade Lee) Date: Wed, 18 Jun 2014 20:42:09 +0800 Subject: [Freeipa-devel] [PATCH] 6 - Dogtag DRM -IPA plugin In-Reply-To: <53874F2E.1040001@redhat.com> References: <1398872755.11303.12.camel@aleeredhat.laptop> <536298B6.9070907@redhat.com> <1399693089.26524.14.camel@aleeredhat.laptop> <1401227860.9297.9.camel@aleeredhat.laptop> <20140528064818.GE28407@dhcp-40-8.bne.redhat.com> <5385EA3D.8000505@redhat.com> <53874F2E.1040001@redhat.com> Message-ID: <1403095329.31066.4.camel@localhost.localdomain> I have not addressed Rob's comments here yet, but will do so in a later patch. We are most likely a couple weeks or so away from landing these patches and we can work on rejiggering/squashing them then. To help folks review the patches without getting merge issues, and so that I don't have to worry about rebases until we get closer to the time we want to commit these patches, I have exposed a repo with the patches committed so reviewers can pull the patches, or start to work with them. This is what Endi did to pull my patches: $ git remote add vakwetu git://fedorapeople.org/home/fedora/vakwetu/public_git/freeipa.git $ git checkout -b alee_0414_drm_add vakwetu/alee_0414_drm_add Note that there is a change which I am currently designing to provide a top level baseDN which will affect these patches. Ade On Thu, 2014-05-29 at 11:15 -0400, Rob Crittenden wrote: > Petr Viktorin wrote: > > On 05/28/2014 08:48 AM, Fraser Tweedale wrote: > >> On Tue, May 27, 2014 at 05:57:40PM -0400, Ade Lee wrote: > >>> There have been a couple of changes in the Dogtag interface, that > >>> require some changes in the IPA patches. Also, I had to add back a > >>> function in order to rebase to the latest IPA code. > >>> > >>> Most are the patches are as before, attached to this email by default. > >>> > >>> The latest Dogtag 10.2 build with the relevant changes needed to work > >>> with these patches is at: > >>> http://copr.fedoraproject.org/coprs/vakwetu/dogtag/ > >>> > >>> Ade > >>> > >> > >> ACK. > >> > >> ipa-server-install worked fine for me, and the formatting changes > >> seem good. Patch 0003 did not apply cleanly on master (due to minor > >> conflict in 71c6d2f:installutils.py); an updated patch 0003 is > >> attached. > > > > Hello, > > If you do a rebase, could you attach all the patches again? > > I don't have the Git objects that result from the original patch, so > > `git am` fails on the later patches: > > > > $ git am -3 *.patch > > Applying: Add a DRM to IPA > > Applying: Added ipa-drm-install > > Applying: Fix various pep 8 issues and comments from review > > Applying: Added nolog to pkispawn and some additional fixes from review. > > Applying: Added dogtag plugin for DRM > > Applying: set drm to not install by default with ipa-server-install > > Applying: Allow ipa-replica-install to be used for installing replicas > > error: invalid object 100755 0385a823baa971b0e08d1d93d7409b7a7716e33b > > for 'install/tools/ipa-replica-install' > > fatal: git-write-tree: error building trees > > Repository lacks necessary blobs to fall back on 3-way merge. > > Cannot fall back to three-way merge. > > Patch failed at 0007 Allow ipa-replica-install to be used for installing > > replicas > > The copy of the patch that failed is found in: > > /home/pviktori/freeipa/.git/rebase-apply/patch > > When you have resolved this problem, run "git am --continue". > > If you prefer to skip this patch, run "git am --skip" instead. > > To restore the original branch and stop patching, run "git am --abort". > > > > I needed to rebase patche 9 as well as it contained a duplicate > function, check_entropy. No need to rebase it again yet as we have to > wait to push these until after a future branch anyway. > > Speaking of patch 9, it appears to be all formatting and spelling fixes, > not all related to the DRM. Patch 4 does similar work. If we're going to > commit these all separately anyway, is it worthwhile to combine these > two? Something (or someone) is mighty picky about thru vs through too :-) > > The DRM patches should all have a ticket referenced. At a minimum the > first one (0002 in this case). > > I think 0007 can be rebased into an existing patch unless we want to > record in history that the default stance changed. > > Found a place that needs a change. The script > install/restart_scripts/renew_ca_cert handles fixing the trust on the > audit cert after renewal. This needs to update the DRM audit cert trust > as well. Be aware that Honza is making significant changes to this area. > > Otherwise looks ok to me. I'm not super-firm on squashing some of the > patches, I just don't know what historical benefit might be gained from > keeping them separate. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Wed Jun 18 12:48:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 14:48:14 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <53A184BE.6000107@redhat.com> References: <539B17D6.6040908@redhat.com> <539F10B6.80507@redhat.com> <53A18080.4030104@redhat.com> <53A1840D.9050009@redhat.com> <53A184BE.6000107@redhat.com> Message-ID: <53A18A8E.50707@redhat.com> On 06/18/2014 02:23 PM, Martin Kosek wrote: > On 06/18/2014 02:20 PM, Petr Viktorin wrote: >> On 06/18/2014 02:05 PM, Martin Kosek wrote: [...] >>> 583.2: OK >>> >>> 584.2: >>> >>> 1) Typo in description: >>> Convewrt the existing default permissions. >> >> Thanks for the catch, I'll fix it before pushing. >> >>> >>> 2) What would you like to do with per-zone permissions? >>> >>> # ipa dnszone-add-permission example.com >>> ------------------------------------------------------ >>> Added system permission "Manage DNS zone example.com." >>> ------------------------------------------------------ >>> Manage DNS zone example.com. >>> >>> # ipa permission-show 'Manage DNS zone example.com.' >>> Permission name: Manage DNS zone example.com. >>> Granted to Privilege: test2 >>> Indirect Member of roles: test2 >>> >>> Should the command be converted to add V2 permissions? We would have to also >>> deal with conversion from old DNS zone permissions to permissionsv2 though. >>> >>> 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS >>> entries in a zone" permissions to managed? It would make their maintenance and >>> updates much easier, we would also get rid of more updates in update files. >>> >>> The only problem I see is how to define 'userattr = >>> "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be >>> rough at the moment. >> >> I'd like to leave these two cases until after the "regular" default permissions >> are done. >> The regular permissions must be converted now because when you "touch" them >> with 4.0 permission-mod, they get converted to V2 and the updater will no >> longer count them as old default permissions. So we need to convert all of them >> right now. The SYSTEM ones can't be modified so they could theoretically wait >> till 4.1+. >> There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'. > > Ok, not a blocker. I opened [#4384] for 1). >> For the second case, yes, adding more bind rule types will need some work (and >> a new permission flag). I'd like to combine that work with the >> selfservice/delegation, which also need special bind rules. > > Ok, please make sure that we have the ideas and missing TODOs reflected in tickets. I'm tracking 3) as part of [#4346] now. These show up in a simple grep or ldapsearch. > Given these arrangements, ACK to the patch set as is (with the typo fix). > > Martin > Thanks, pushed to master: 700ac6c11627137db758ad376c44745db579dc84 [#4384] https://fedorahosted.org/freeipa/ticket/4384 [#4346] https://fedorahosted.org/freeipa/ticket/4346 -- Petr? From mkosek at redhat.com Wed Jun 18 12:48:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 14:48:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0585-0587 Convert Password Policy & COSTemplate default permissions to managed In-Reply-To: <539B20E2.8060805@redhat.com> References: <539B20E2.8060805@redhat.com> Message-ID: <53A18A8D.8060201@redhat.com> On 06/13/2014 06:03 PM, Petr Viktorin wrote: > The first patch is preparation. > > As for the second two, this is how the bulk of the transition will look. Works fine, also tested with unit test. When testing it, I found one error: # ipa pwpolicy-add ipausers --maxlife 90 --minlife 1 --priority 1 ipa: ERROR: no such entry However, this is not a problem in pwpolicy permissions, but rather caused by https://fedorahosted.org/freeipa/ticket/4372 as ipausers is not readable to the privileged user even though the user has Group Administrators privilege. ACK to this patch set (I wanted to push myself, but you just cause a conflict :) Martin From pviktori at redhat.com Wed Jun 18 12:48:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 14:48:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0583-0584 Convert DNS default permissions to managed In-Reply-To: <53A184BE.6000107@redhat.com> References: <539B17D6.6040908@redhat.com> <539F10B6.80507@redhat.com> <53A18080.4030104@redhat.com> <53A1840D.9050009@redhat.com> <53A184BE.6000107@redhat.com> Message-ID: <53A18A93.7010506@redhat.com> On 06/18/2014 02:23 PM, Martin Kosek wrote: > On 06/18/2014 02:20 PM, Petr Viktorin wrote: >> On 06/18/2014 02:05 PM, Martin Kosek wrote: [...] >>> 583.2: OK >>> >>> 584.2: >>> >>> 1) Typo in description: >>> Convewrt the existing default permissions. >> >> Thanks for the catch, I'll fix it before pushing. >> >>> >>> 2) What would you like to do with per-zone permissions? >>> >>> # ipa dnszone-add-permission example.com >>> ------------------------------------------------------ >>> Added system permission "Manage DNS zone example.com." >>> ------------------------------------------------------ >>> Manage DNS zone example.com. >>> >>> # ipa permission-show 'Manage DNS zone example.com.' >>> Permission name: Manage DNS zone example.com. >>> Granted to Privilege: test2 >>> Indirect Member of roles: test2 >>> >>> Should the command be converted to add V2 permissions? We would have to also >>> deal with conversion from old DNS zone permissions to permissionsv2 though. >>> >>> 3) How difficult would it be to also convert "Add/Read/Remove/Update DNS >>> entries in a zone" permissions to managed? It would make their maintenance and >>> updates much easier, we would also get rid of more updates in update files. >>> >>> The only problem I see is how to define 'userattr = >>> "parent[0,1].managedby#GROUPDN"' in the managed permission, IMO it could be >>> rough at the moment. >> >> I'd like to leave these two cases until after the "regular" default permissions >> are done. >> The regular permissions must be converted now because when you "touch" them >> with 4.0 permission-mod, they get converted to V2 and the updater will no >> longer count them as old default permissions. So we need to convert all of them >> right now. The SYSTEM ones can't be modified so they could theoretically wait >> till 4.1+. >> There'll be a few more SYSTEM permissions to convert like 'Modify DNA Range'. > > Ok, not a blocker. I opened [#4384] for 1). >> For the second case, yes, adding more bind rule types will need some work (and >> a new permission flag). I'd like to combine that work with the >> selfservice/delegation, which also need special bind rules. > > Ok, please make sure that we have the ideas and missing TODOs reflected in tickets. I'm tracking 3) as part of [#4346] now. These show up in a simple grep or ldapsearch. > Given these arrangements, ACK to the patch set as is (with the typo fix). > > Martin > Thanks, pushed to master: 700ac6c11627137db758ad376c44745db579dc84 [#4384] https://fedorahosted.org/freeipa/ticket/4384 [#4346] https://fedorahosted.org/freeipa/ticket/4346 -- Petr? From pviktori at redhat.com Wed Jun 18 12:57:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 14:57:44 +0200 Subject: [Freeipa-devel] [PATCHES] 0585-0587 Convert Password Policy & COSTemplate default permissions to managed In-Reply-To: <53A18A8D.8060201@redhat.com> References: <539B20E2.8060805@redhat.com> <53A18A8D.8060201@redhat.com> Message-ID: <53A18CC8.6010903@redhat.com> On 06/18/2014 02:48 PM, Martin Kosek wrote: > On 06/13/2014 06:03 PM, Petr Viktorin wrote: >> The first patch is preparation. >> >> As for the second two, this is how the bulk of the transition will look. > > Works fine, also tested with unit test. When testing it, I found one error: > > # ipa pwpolicy-add ipausers --maxlife 90 --minlife 1 --priority 1 > ipa: ERROR: no such entry > > However, this is not a problem in pwpolicy permissions, but rather caused by > https://fedorahosted.org/freeipa/ticket/4372 > as ipausers is not readable to the privileged user even though the user has > Group Administrators privilege. > > ACK to this patch set (I wanted to push myself, but you just cause a conflict :) Thanks for the review! -- Petr? From pviktori at redhat.com Wed Jun 18 13:15:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Jun 2014 15:15:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed In-Reply-To: <5398864C.9020708@redhat.com> References: <5398864C.9020708@redhat.com> Message-ID: <53A19102.9020802@redhat.com> On 06/11/2014 06:39 PM, Petr Viktorin wrote: > Patch 0578 does the conversion > > Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and > provides permissions needed for automatic enrollment (from > http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser) Rebasing to current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0578.2-Convert-Host-default-permissions-to-managed.patch Type: text/x-patch Size: 20315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0579.2-host-permissions-Allow-writing-attributes-needed-for.patch Type: text/x-patch Size: 4946 bytes Desc: not available URL: From tbordaz at redhat.com Wed Jun 18 13:22:02 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 18 Jun 2014 15:22:02 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A16E4A.10300@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> Message-ID: <53A1927A.9010306@redhat.com> On 06/18/2014 12:47 PM, Martin Kosek wrote: > On 06/17/2014 05:59 PM, thierry bordaz wrote: >> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > ... >> Thanks for your precise feedback and sorry for my late answer. >> So if I try to consolidate my understandings, the workflow would be: >> >> 1. Staging (container: cn=staged >> users,cn=accounts,cn=provisioning,SUFFIX) >> * ipa stageuser-add >> It creates a stage entry with >> >> uidNumber: -1 >> gidNumber: -1 >> ipaUniqueID: autogenerate >> description: __no_upg__ >> manager: checks that the DN is an active user >> nsAccountLock: True > I was thinking about the nsAccountLock part again. Should we really force > provisioning systems to set it to True for staged users? Should we even > manipulate it in stageduser plugin? That is correct, provisioning system can create entries in Staging area without nsAccountLock or with nsAccountLock: False. With stageuser-add we have this ability but as you described below it can be done with different ways. We may create a new DS plugin to enforce added stage entries (or modifications) have the expected values. But I think the idea was to make Stage container free to receive any kind of entries. This was the activation job to make the control. activation (stageuser-activate) is setting 'nsAccountLock: False' so currently at least this method is manipulating nsAccountLock. > > The original reason why I proposed it in > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? Sure this solution would also have the advantages to prevent authentication from Staging/Delete container and allow authentication only from 'Active' container. For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? About Kerberos update, my understanding is that if we restrict (in sasl mapping) the baseDN template (nsSaslMapBaseDNTemplate) to cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication only to Active user. Is that correct ? > > This would allow us to be sure that nobody can bind/authenticate to these users > without having to manipulate nsAccountLock attribute. > > The only downside is that this would not be effective in older FreeIPA > versions, but AFAIR, we specified that if User Life Cycle is enabled, all > server should have at least 4.1 - otherwise for example deleted users would be > put to the special container or old servers would not have the appropriate DS > plugins updates. > > Martin From ssorce at redhat.com Wed Jun 18 13:31:04 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 09:31:04 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A16E4A.10300@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> Message-ID: <1403098264.12884.46.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: > On 06/17/2014 05:59 PM, thierry bordaz wrote: > > On 06/16/2014 03:04 PM, Rob Crittenden wrote: > ... > > Thanks for your precise feedback and sorry for my late answer. > > So if I try to consolidate my understandings, the workflow would be: > > > > 1. Staging (container: cn=staged > > users,cn=accounts,cn=provisioning,SUFFIX) > > * ipa stageuser-add > > It creates a stage entry with > > > > uidNumber: -1 > > gidNumber: -1 > > ipaUniqueID: autogenerate > > description: __no_upg__ > > manager: checks that the DN is an active user > > nsAccountLock: True > > I was thinking about the nsAccountLock part again. Should we really force > provisioning systems to set it to True for staged users? Should we even > manipulate it in stageduser plugin? No, thinking hard about it I think nsAccountLock should be completely ignored in the staged area. It is an operational attribute that is responsibility of IPA admins, provisioning systems have nothing to do with it. If they do not want a user to be available they simply do not provision it. If they do then it is on the admin to decide if/when to unstage the user and make it available. > The original reason why I proposed it in > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? The staged user should have it's userPassword anmd KrbKerberosKey removed, so no binding should be possible. > This would allow us to be sure that nobody can bind/authenticate to these users > without having to manipulate nsAccountLock attribute. We should just make sure no credentials are set ? Is there any valid reson for the provisioning system to be allowed to set userPassword ? (It can't set KrbKerberosKey anyway) Alternatively/optionally just set a CoS that enforces nsAccountLock to be set on all staged entries without having to explicitly set it ? > The only downside is that this would not be effective in older FreeIPA > versions, but AFAIR, we specified that if User Life Cycle is enabled, all > server should have at least 4.1 - otherwise for example deleted users would be > put to the special container or old servers would not have the appropriate DS > plugins updates. Yeah I do not see an issue with older servers, esp if we do not allow credentials on the entry anyway. Simo. From simo at redhat.com Wed Jun 18 13:35:43 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 09:35:43 -0400 Subject: [Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server In-Reply-To: <53A15E5B.1020408@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <1403030370.12884.9.camel@willson.usersys.redhat.com> <53A095B6.3090805@redhat.com> <1403033390.12884.14.camel@willson.usersys.redhat.com> <53A098DB.8000700@redhat.com> <1403034161.12884.20.camel@willson.usersys.redhat.com> <53A15E5B.1020408@redhat.com> Message-ID: <1403098543.12884.48.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 11:39 +0200, thierry bordaz wrote: > On 06/17/2014 09:42 PM, Simo Sorce wrote: > > On Tue, 2014-06-17 at 21:36 +0200, thierry bordaz wrote: > >> On 06/17/2014 09:29 PM, Simo Sorce wrote: > >>> On Tue, 2014-06-17 at 15:23 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> On Tue, 2014-06-17 at 17:59 +0200, thierry bordaz wrote: > >>>>>> * ipa stageuser-add --from-delete > >>>>>> > >>>>>> It moves a deleted entry to staging container where > >>>>>> > >>>>>> uidNumber: >>>>>> prevous active account> > >>>>>> gidNumber: >>>>>> prevous active account> > >>>>>> ipaUniqueID: autogenerate (reset to autogenerate) > >>>>> Why are you resetting the unique id ? > >>>> Read back a few in the thread. I suggested, perhaps incorrectly, that > >>>> given that there should be no more references to the user once they go > >>>> into deleted or staged, it may be ok to reset this value. > >>> Well, let me reiterate, the deleted bucket is for those environments > >>> where they have a mandate (regulation, law, policy, etc..) to never > >>> delete users and reinstate users if they are deleted. > >>> So all uniquely identifying information should be preserved in case the > >>> object is revived. This means we need to do our best to preserve all > >>> these attributes if we can. > >> This is what is done when an Active user is deleted. > >> uidNumber/gidNumber/ipaUniqueID are preserved. > >> When activating a user, currently UUID plugin prevents to set a value. > >> Should it be relaxed.. I feel not. It is a sensitive info and > >> provisioning system should not define it. > > Why is it sensitive ? A ipaUniqueID is not really sensitive, it just > > needs to be unique. > > Ok. I believed it was :-) > > I have a concern, if a provisioning system is free to define this value, > I wonder if it can create problem for replication. > For example a provisioning system creates two staging entries on > different servers but with the same ipaUniqueID value. A provisioning system should never have to contact 2 different servers, what would be the point ? And then on top of that generate the same UUID ? Well don't do that, fix your provisioning tool. > If the entries are activated at the same time, the ADDs operation > (activation) will not be replicated because the attribute uniqueness > plugin will reject it. Right, don't do that. > This case existed before if two IPA uuid plugins generated identical > value on different replica. But the probability was less than if the > provisioning system is free to set it. Sure, but who cares ? I mean there are *many* ways to whose a system, the provisioning system can simply create 2 users accounts with the same name on 2 servers and get them activated at the same time and you get the same issue as uid is also unique. Just fix the malfunctioning provisioning system. > >> When undelete a user (move Delete->Staging), ipaUniqueID can be > >> preserved but as the purpose of Staging entry is to become active I > >> thought it would be better to wipe the value also at this time. > > I understand that (and I noted before that I think deleted->staged is a > > bad idea IMO :-) ), but you are wiping it only as a workaround, because > > the plugin prevents you from adding it. Would have you wiped it if it > > were not the case ? And if so, why ? > > That is correct. I thought to wipe it because the plugin rejected values > others than 'autogenerate'. > > To relax the control that rejects values other than 'autogenerate', I > need to modify the plugin. Should it be done under an other ticket or > can it be part of this RFE ? I think it can be part of this RFE, should we use the Relax Control for this ? I think it may still valuable to enforce the rule in non-staging cases. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jun 18 13:40:16 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 09:40:16 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A1927A.9010306@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <53A1927A.9010306@redhat.com> Message-ID: <1403098816.12884.50.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: > On 06/18/2014 12:47 PM, Martin Kosek wrote: > > On 06/17/2014 05:59 PM, thierry bordaz wrote: > >> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > > ... > >> Thanks for your precise feedback and sorry for my late answer. > >> So if I try to consolidate my understandings, the workflow would be: > >> > >> 1. Staging (container: cn=staged > >> users,cn=accounts,cn=provisioning,SUFFIX) > >> * ipa stageuser-add > >> It creates a stage entry with > >> > >> uidNumber: -1 > >> gidNumber: -1 > >> ipaUniqueID: autogenerate > >> description: __no_upg__ > >> manager: checks that the DN is an active user > >> nsAccountLock: True > > I was thinking about the nsAccountLock part again. Should we really force > > provisioning systems to set it to True for staged users? Should we even > > manipulate it in stageduser plugin? > > That is correct, provisioning system can create entries in Staging area > without nsAccountLock or with nsAccountLock: False. > With stageuser-add we have this ability but as you described below it > can be done with different ways. > > We may create a new DS plugin to enforce added stage entries (or > modifications) have the expected values. But I think the idea was to > make Stage container free to receive any kind of entries. This was the > activation job to make the control. > > activation (stageuser-activate) is setting 'nsAccountLock: False' so > currently at least this method is manipulating nsAccountLock. Shouldn't it just remove the attribute if present ? > > The original reason why I proposed it in > > http://www.freeipa.org/page/V4/User_Life-Cycle_Management > > is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > > Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > > pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? > Sure this solution would also have the advantages to prevent > authentication from Staging/Delete container and allow authentication > only from 'Active' container. > For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? > > About Kerberos update, my understanding is that if we restrict (in sasl > mapping) the baseDN template (nsSaslMapBaseDNTemplate) to > cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication > only to Active user. Is that correct ? No, we have many other principals that can bind to DS in cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you cannot exclude those. Besides there are also simple binds. Simo. From tbordaz at redhat.com Wed Jun 18 13:55:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 18 Jun 2014 15:55:05 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403098816.12884.50.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <53A1927A.9010306@redhat.com> <1403098816.12884.50.camel@willson.usersys.redhat.com> Message-ID: <53A19A39.5060602@redhat.com> On 06/18/2014 03:40 PM, Simo Sorce wrote: > On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: >> On 06/18/2014 12:47 PM, Martin Kosek wrote: >>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >>> ... >>>> Thanks for your precise feedback and sorry for my late answer. >>>> So if I try to consolidate my understandings, the workflow would be: >>>> >>>> 1. Staging (container: cn=staged >>>> users,cn=accounts,cn=provisioning,SUFFIX) >>>> * ipa stageuser-add >>>> It creates a stage entry with >>>> >>>> uidNumber: -1 >>>> gidNumber: -1 >>>> ipaUniqueID: autogenerate >>>> description: __no_upg__ >>>> manager: checks that the DN is an active user >>>> nsAccountLock: True >>> I was thinking about the nsAccountLock part again. Should we really force >>> provisioning systems to set it to True for staged users? Should we even >>> manipulate it in stageduser plugin? >> That is correct, provisioning system can create entries in Staging area >> without nsAccountLock or with nsAccountLock: False. >> With stageuser-add we have this ability but as you described below it >> can be done with different ways. >> >> We may create a new DS plugin to enforce added stage entries (or >> modifications) have the expected values. But I think the idea was to >> make Stage container free to receive any kind of entries. This was the >> activation job to make the control. >> >> activation (stageuser-activate) is setting 'nsAccountLock: False' so >> currently at least this method is manipulating nsAccountLock. > Shouldn't it just remove the attribute if present ? Yes as we decide to not use this attribute to allow/disallow . I will remove it from CLIs > >>> The original reason why I proposed it in >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management >>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. >>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND >>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? >> Sure this solution would also have the advantages to prevent >> authentication from Staging/Delete container and allow authentication >> only from 'Active' container. >> For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? >> >> About Kerberos update, my understanding is that if we restrict (in sasl >> mapping) the baseDN template (nsSaslMapBaseDNTemplate) to >> cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication >> only to Active user. Is that correct ? > No, we have many other principals that can bind to DS in > cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you > cannot exclude those. Besides there are also simple binds. Ok. We want to exclude 'Stage' and 'Delete' containers. A possibility is to create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for nsSaslMapping entry. thanks thierry > > Simo. > > From jcholast at redhat.com Wed Jun 18 13:56:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 18 Jun 2014 15:56:36 +0200 Subject: [Freeipa-devel] [PATCH] 302 Do not corrupt sshd_config in client install when trailing newline is missing Message-ID: <53A19A94.7010504@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-302-Do-not-corrupt-sshd_config-in-client-install-when-tr.patch Type: text/x-patch Size: 2842 bytes Desc: not available URL: From tbordaz at redhat.com Wed Jun 18 14:20:25 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 18 Jun 2014 16:20:25 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403098264.12884.46.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> Message-ID: <53A1A029.7060303@redhat.com> On 06/18/2014 03:31 PM, Simo Sorce wrote: > On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >> ... >>> Thanks for your precise feedback and sorry for my late answer. >>> So if I try to consolidate my understandings, the workflow would be: >>> >>> 1. Staging (container: cn=staged >>> users,cn=accounts,cn=provisioning,SUFFIX) >>> * ipa stageuser-add >>> It creates a stage entry with >>> >>> uidNumber: -1 >>> gidNumber: -1 >>> ipaUniqueID: autogenerate >>> description: __no_upg__ >>> manager: checks that the DN is an active user >>> nsAccountLock: True >> I was thinking about the nsAccountLock part again. Should we really force >> provisioning systems to set it to True for staged users? Should we even >> manipulate it in stageduser plugin? > No, thinking hard about it I think nsAccountLock should be completely > ignored in the staged area. It is an operational attribute that is > responsibility of IPA admins, provisioning systems have nothing to do > with it. If they do not want a user to be available they simply do not > provision it. If they do then it is on the admin to decide if/when to > unstage the user and make it available. A Stage user is waiting for an approval before being Active. And an approver may have a look at its properties to decide. During the time it remains in Staging, admin do not want someone to bind with that entry even if the provisioning system set the password. pre-bind plugin or cos are possibilites to prevent binding with that entry. > >> The original reason why I proposed it in >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management >> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. >> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND >> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? > The staged user should have it's userPassword anmd KrbKerberosKey > removed, so no binding should be possible. That means a Delete user being staged (ipa stageuser-add --from-delete) will loose its password/keys. I believe it is an acceptable limitation else the admin would prefere to do 'ipa user-undelete '. > >> This would allow us to be sure that nobody can bind/authenticate to these users >> without having to manipulate nsAccountLock attribute. > We should just make sure no credentials are set ? > Is there any valid reson for the provisioning system to be allowed to > set userPassword ? (It can't set KrbKerberosKey anyway) Does that mean stageuser-add/mod should not support options around password setting ? > > Alternatively/optionally just set a CoS that enforces nsAccountLock to > be set on all staged entries without having to explicitly set it ? > >> The only downside is that this would not be effective in older FreeIPA >> versions, but AFAIR, we specified that if User Life Cycle is enabled, all >> server should have at least 4.1 - otherwise for example deleted users would be >> put to the special container or old servers would not have the appropriate DS >> plugins updates. > Yeah I do not see an issue with older servers, esp if we do not allow > credentials on the entry anyway. > > Simo. > From ssorce at redhat.com Wed Jun 18 14:32:27 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 10:32:27 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A19A39.5060602@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <53A1927A.9010306@redhat.com> <1403098816.12884.50.camel@willson.usersys.redhat.com> <53A19A39.5060602@redhat.com> Message-ID: <1403101947.12884.57.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 15:55 +0200, thierry bordaz wrote: > On 06/18/2014 03:40 PM, Simo Sorce wrote: > > On Wed, 2014-06-18 at 15:22 +0200, thierry bordaz wrote: > >> On 06/18/2014 12:47 PM, Martin Kosek wrote: > >>> On 06/17/2014 05:59 PM, thierry bordaz wrote: > >>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > >>> ... > >>>> Thanks for your precise feedback and sorry for my late answer. > >>>> So if I try to consolidate my understandings, the workflow would be: > >>>> > >>>> 1. Staging (container: cn=staged > >>>> users,cn=accounts,cn=provisioning,SUFFIX) > >>>> * ipa stageuser-add > >>>> It creates a stage entry with > >>>> > >>>> uidNumber: -1 > >>>> gidNumber: -1 > >>>> ipaUniqueID: autogenerate > >>>> description: __no_upg__ > >>>> manager: checks that the DN is an active user > >>>> nsAccountLock: True > >>> I was thinking about the nsAccountLock part again. Should we really force > >>> provisioning systems to set it to True for staged users? Should we even > >>> manipulate it in stageduser plugin? > >> That is correct, provisioning system can create entries in Staging area > >> without nsAccountLock or with nsAccountLock: False. > >> With stageuser-add we have this ability but as you described below it > >> can be done with different ways. > >> > >> We may create a new DS plugin to enforce added stage entries (or > >> modifications) have the expected values. But I think the idea was to > >> make Stage container free to receive any kind of entries. This was the > >> activation job to make the control. > >> > >> activation (stageuser-activate) is setting 'nsAccountLock: False' so > >> currently at least this method is manipulating nsAccountLock. > > Shouldn't it just remove the attribute if present ? > > Yes as we decide to not use this attribute to allow/disallow . I will > remove it from CLIs > > > >>> The original reason why I proposed it in > >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > >>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > >>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? > >> Sure this solution would also have the advantages to prevent > >> authentication from Staging/Delete container and allow authentication > >> only from 'Active' container. > >> For LDAP BIND pre-bind which plugin are you thinking of ? a new one ? > >> > >> About Kerberos update, my understanding is that if we restrict (in sasl > >> mapping) the baseDN template (nsSaslMapBaseDNTemplate) to > >> cn=users,cn=accounts,SUFFIX it would restrict kerberos authentication > >> only to Active user. Is that correct ? > > No, we have many other principals that can bind to DS in > > cn=computers,cn=users cn=services,cn=users and cn=kerberos at least, you > > cannot exclude those. Besides there are also simple binds. > Ok. > We want to exclude 'Stage' and 'Delete' containers. A possibility is to > create a new multivalued attribute (like 'nsSaslMapExcludeSubtree') for > nsSaslMapping entry. I fail to see the need for this. In order to be able to to GSSAPI authentication you need to be able to acquire a ticket for the principal, but the KrbKerberosKey should be removed when deleting a user and the provisioning system has no way to create it in the staged entries. So there should be no way for a principal to make an AS request to start with nor a TGS request, so it should never be able to have a ticket that would map to one of those entries. Also just changing the Sasl mapping will not preclude simple binds ? But can we simply delete userPassword from deleted and prevent it to be set in staging (or alternatively force accountlock) ? Third alternative is to change the ipa pre-bind plugin to preclude any binding for entries in deleted/staged Simo. From ssorce at redhat.com Wed Jun 18 14:45:55 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 10:45:55 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A1A029.7060303@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> Message-ID: <1403102755.12884.59.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: > On 06/18/2014 03:31 PM, Simo Sorce wrote: > > On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: > >> On 06/17/2014 05:59 PM, thierry bordaz wrote: > >>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > >> ... > >>> Thanks for your precise feedback and sorry for my late answer. > >>> So if I try to consolidate my understandings, the workflow would be: > >>> > >>> 1. Staging (container: cn=staged > >>> users,cn=accounts,cn=provisioning,SUFFIX) > >>> * ipa stageuser-add > >>> It creates a stage entry with > >>> > >>> uidNumber: -1 > >>> gidNumber: -1 > >>> ipaUniqueID: autogenerate > >>> description: __no_upg__ > >>> manager: checks that the DN is an active user > >>> nsAccountLock: True > >> I was thinking about the nsAccountLock part again. Should we really force > >> provisioning systems to set it to True for staged users? Should we even > >> manipulate it in stageduser plugin? > > No, thinking hard about it I think nsAccountLock should be completely > > ignored in the staged area. It is an operational attribute that is > > responsibility of IPA admins, provisioning systems have nothing to do > > with it. If they do not want a user to be available they simply do not > > provision it. If they do then it is on the admin to decide if/when to > > unstage the user and make it available. > > A Stage user is waiting for an approval before being Active. And an > approver may have a look at its properties to decide. > During the time it remains in Staging, admin do not want someone to bind > with that entry even if the provisioning system set the password. > pre-bind plugin or cos are possibilites to prevent binding with that entry. Right, if we allow setting userPassword this would happen, but then if we allow setting userPassword do we also generate Kerberos Keys ? If this is the case then we probably need to change the pre-bind plugin (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). I was actually planning to use staging to allow kadmin to create entries, so we need to be careful how ipa-kdb limits access to staging, I would guess it should pretend KrbKerberosKey is not present for those entries. > >> The original reason why I proposed it in > >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > >> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > >> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? > > The staged user should have it's userPassword anmd KrbKerberosKey > > removed, so no binding should be possible. > > That means a Delete user being staged (ipa stageuser-add > --from-delete) will loose its password/keys. > I believe it is an acceptable limitation else the admin would prefere to > do 'ipa user-undelete '. What I meant here is the ipa-del would drop the passwords and keys, so there is no undelete that will restore them. But if we think we should preserve them then the above option (change in ipa-kdb plugin) is the best way to go to mask out these entries. > >> This would allow us to be sure that nobody can bind/authenticate to these users > >> without having to manipulate nsAccountLock attribute. > > We should just make sure no credentials are set ? > > Is there any valid reson for the provisioning system to be allowed to > > set userPassword ? (It can't set KrbKerberosKey anyway) > Does that mean stageuser-add/mod should not support options around > password setting ? Well the problem is that is you allow setting userPassword then you need it in the clear and have to also generate Kerberos Keys, and then we need to prevent them from being used (ipa-kdb change). Allowing to set a pre-hashed userPassword won't work because then the user cannot authenticate with Kerberos and the server need to be permanently set in migration mode or the user must be forced to go somewhere to change the password so setting a pre-shared password in the first place is basically useless. Otherwise we can simply forbid them being set by provisioning and the only thing we need to do is to remove userPassword/KrbPrincipalKey when the user is moved to the deleted tree. Simo. From mbasti at redhat.com Wed Jun 18 14:49:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Jun 2014 16:49:05 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains Message-ID: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> Due to compability with older versions, only IDNA domains should be checked Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0070-Check-normalization-only-for-IDNA-domains.patch Type: text/x-patch Size: 3561 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 18 15:14:45 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 18 Jun 2014 17:14:45 +0200 Subject: [Freeipa-devel] [PATCH 0229] dsinstance: Detect dynamic plugin support and restart server Message-ID: <53A1ACE5.2060600@redhat.com> Hi, With 389-ds-base 1.3.3. comes the dynamic plugin support. We need to restart the server right after modifying the schema, as the plugins will be enabled at the point they are added (and not at the next server restart). Properly handle both situations in the installer. https://fedorahosted.org/freeipa/ticket/4203 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0229-dsinstance-Detect-dynamic-plugin-support-and-restart.patch Type: text/x-patch Size: 4137 bytes Desc: not available URL: From pspacek at redhat.com Wed Jun 18 15:36:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 Jun 2014 17:36:02 +0200 Subject: [Freeipa-devel] [PATCH 0019] Clarify LDAPClient docstrings about get_entry, get_entries and find_entrie Message-ID: <53A1B1E2.3030108@redhat.com> Hello, Clarify LDAPClient docstrings about get_entry, get_entries and find_entries. BTW what is the purpose of size_limit in LDAPClient.get_entry()? def get_entry(self, dn, attrs_list=None, time_limit=None, size_limit=None) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0019-Clarify-LDAPClient-docstrings-about-get_entry-get_en.patch Type: text/x-patch Size: 1498 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 18 15:46:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Jun 2014 17:46:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed In-Reply-To: <5398864C.9020708@redhat.com> References: <5398864C.9020708@redhat.com> Message-ID: <53A1B45D.9020609@redhat.com> On 06/11/2014 06:39 PM, Petr Viktorin wrote: > Patch 0578 does the conversion > > Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and provides > permissions needed for automatic enrollment (from > http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser) 1) Inconsistent casing in permission names: System: Add Hosts System: Add krbPrincipalName to a host System: Enroll a host System: Manage Host SSH Public Keys System: Manage host keytab System: Modify Hosts System: Remove Hosts 2) This ACI does not look right, missing enrolledby: + 'System: Enroll a host': { + 'ipapermright': {'write'}, + 'ipapermdefaultattr': {'objectclass'}, When I fixed 2) via permission-mod, client enrollment with user with "Host Administrators" privilege worked fine. 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: No such virtual command" error triggered by "cert-show" command. We will need to add the permission "System: Read Virtual Operations" that Honza is creating also to "Host Administrators" to fix that part. 4) I ran unit tests and few missing attributes: - update hosts ACI should get "macaddress" attribute 5) I hit one nasty issue when running the unit tests (when my master stopped working as host account was deleted) - host_is_master function in baseldap no longer works as we hid cn=masters from regular users: def host_is_master(ldap, fqdn): """ Check to see if this host is a master. Raises an exception if a master, otherwise returns nothing. """ master_dn = DN(('cn', fqdn), ('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), api. env.basedn) try: ldap.get_entry(master_dn, ['objectclass']) raise errors.ValidationError(name='hostname', error=_('An IPA master host cannot be deleted or disabled')) except errors.NotFound: # Good, not a master return This means, that host-del on a master machine or service-del on master service happily passes. We need to make sure this functionality is still working after the permission refactoring. Should we reconsider the cn=masters tree and allow authenticated users see the list of IPA servers (without digging into any other detail like services) then? Martin From tbordaz at redhat.com Wed Jun 18 15:49:20 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 18 Jun 2014 17:49:20 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403102755.12884.59.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> Message-ID: <53A1B500.1060505@redhat.com> On 06/18/2014 04:45 PM, Simo Sorce wrote: > On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: >> On 06/18/2014 03:31 PM, Simo Sorce wrote: >>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >>>> ... >>>>> Thanks for your precise feedback and sorry for my late answer. >>>>> So if I try to consolidate my understandings, the workflow would be: >>>>> >>>>> 1. Staging (container: cn=staged >>>>> users,cn=accounts,cn=provisioning,SUFFIX) >>>>> * ipa stageuser-add >>>>> It creates a stage entry with >>>>> >>>>> uidNumber: -1 >>>>> gidNumber: -1 >>>>> ipaUniqueID: autogenerate >>>>> description: __no_upg__ >>>>> manager: checks that the DN is an active user >>>>> nsAccountLock: True >>>> I was thinking about the nsAccountLock part again. Should we really force >>>> provisioning systems to set it to True for staged users? Should we even >>>> manipulate it in stageduser plugin? >>> No, thinking hard about it I think nsAccountLock should be completely >>> ignored in the staged area. It is an operational attribute that is >>> responsibility of IPA admins, provisioning systems have nothing to do >>> with it. If they do not want a user to be available they simply do not >>> provision it. If they do then it is on the admin to decide if/when to >>> unstage the user and make it available. >> A Stage user is waiting for an approval before being Active. And an >> approver may have a look at its properties to decide. >> During the time it remains in Staging, admin do not want someone to bind >> with that entry even if the provisioning system set the password. >> pre-bind plugin or cos are possibilites to prevent binding with that entry. > Right, if we allow setting userPassword this would happen, but then if > we allow setting userPassword do we also generate Kerberos Keys ? Currently setting of the userPassword (add entry or mod entry) triggers generation of krb keys (I guess in ipa-kdb). > > If this is the case then we probably need to change the pre-bind plugin > (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). Do you mean to prevent ipa-kdb to generate krb keys when the this is Delete/Staging > > I was actually planning to use staging to allow kadmin to create > entries, so we need to be careful how ipa-kdb limits access to staging, > I would guess it should pretend KrbKerberosKey is not present for those > entries. > >>>> The original reason why I proposed it in >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management >>>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. >>>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND >>>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? >>> The staged user should have it's userPassword anmd KrbKerberosKey >>> removed, so no binding should be possible. >> That means a Delete user being staged (ipa stageuser-add >> --from-delete) will loose its password/keys. >> I believe it is an acceptable limitation else the admin would prefere to >> do 'ipa user-undelete '. > What I meant here is the ipa-del would drop the passwords and keys, so > there is no undelete that will restore them. But if we think we should > preserve them then the above option (change in ipa-kdb plugin) is the > best way to go to mask out these entries. I do not know what are the consequences of dropping password and keys. A use case would be someone that returns back to an organization and get his account undelete. This person will likely remember his previous password and would expect to be authenticate with kerberos using that password. Now if password and keys have been removed, he should reset his password before being authenticate. I think it is an acceptable limitation. > >>>> This would allow us to be sure that nobody can bind/authenticate to these users >>>> without having to manipulate nsAccountLock attribute. >>> We should just make sure no credentials are set ? >>> Is there any valid reson for the provisioning system to be allowed to >>> set userPassword ? (It can't set KrbKerberosKey anyway) >> Does that mean stageuser-add/mod should not support options around >> password setting ? > Well the problem is that is you allow setting userPassword then you need > it in the clear and have to also generate Kerberos Keys, and then we > need to prevent them from being used (ipa-kdb change). > > Allowing to set a pre-hashed userPassword won't work because then the > user cannot authenticate with Kerberos and the server need to be > permanently set in migration mode or the user must be forced to go > somewhere to change the password so setting a pre-shared password in the > first place is basically useless. > > Otherwise we can simply forbid them being set by provisioning and the > only thing we need to do is to remove userPassword/KrbPrincipalKey when > the user is moved to the deleted tree. > > Simo. > > > From ssorce at redhat.com Wed Jun 18 16:09:36 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 12:09:36 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A1B500.1060505@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> Message-ID: <1403107776.12884.69.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: > On 06/18/2014 04:45 PM, Simo Sorce wrote: > > On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: > >> On 06/18/2014 03:31 PM, Simo Sorce wrote: > >>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: > >>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: > >>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > >>>> ... > >>>>> Thanks for your precise feedback and sorry for my late answer. > >>>>> So if I try to consolidate my understandings, the workflow would be: > >>>>> > >>>>> 1. Staging (container: cn=staged > >>>>> users,cn=accounts,cn=provisioning,SUFFIX) > >>>>> * ipa stageuser-add > >>>>> It creates a stage entry with > >>>>> > >>>>> uidNumber: -1 > >>>>> gidNumber: -1 > >>>>> ipaUniqueID: autogenerate > >>>>> description: __no_upg__ > >>>>> manager: checks that the DN is an active user > >>>>> nsAccountLock: True > >>>> I was thinking about the nsAccountLock part again. Should we really force > >>>> provisioning systems to set it to True for staged users? Should we even > >>>> manipulate it in stageduser plugin? > >>> No, thinking hard about it I think nsAccountLock should be completely > >>> ignored in the staged area. It is an operational attribute that is > >>> responsibility of IPA admins, provisioning systems have nothing to do > >>> with it. If they do not want a user to be available they simply do not > >>> provision it. If they do then it is on the admin to decide if/when to > >>> unstage the user and make it available. > >> A Stage user is waiting for an approval before being Active. And an > >> approver may have a look at its properties to decide. > >> During the time it remains in Staging, admin do not want someone to bind > >> with that entry even if the provisioning system set the password. > >> pre-bind plugin or cos are possibilites to prevent binding with that entry. > > Right, if we allow setting userPassword this would happen, but then if > > we allow setting userPassword do we also generate Kerberos Keys ? > Currently setting of the userPassword (add entry or mod entry) triggers > generation of krb keys (I guess in ipa-kdb). No it happen in ipa-pwd-extop > > If this is the case then we probably need to change the pre-bind plugin > > (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). > Do you mean to prevent ipa-kdb to generate krb keys when the this is > Delete/Staging No I mean to prevent the ipa-kdb driver (it's the KDC driver) from returning any key even if present for entries in those suffixes. > > I was actually planning to use staging to allow kadmin to create > > entries, so we need to be careful how ipa-kdb limits access to staging, > > I would guess it should pretend KrbKerberosKey is not present for those > > entries. > > > >>>> The original reason why I proposed it in > >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management > >>>> is to prevent LDAP BINDs on such user or Kerberos authentication on such user. > >>>> Wouldn't it be better to simply just update KDC backend plugin and LDAP BIND > >>>> pre-bind callback to prevent authentication to users in cn=provisioning,SUFFIX? > >>> The staged user should have it's userPassword anmd KrbKerberosKey > >>> removed, so no binding should be possible. > >> That means a Delete user being staged (ipa stageuser-add > >> --from-delete) will loose its password/keys. > >> I believe it is an acceptable limitation else the admin would prefere to > >> do 'ipa user-undelete '. > > What I meant here is the ipa-del would drop the passwords and keys, so > > there is no undelete that will restore them. But if we think we should > > preserve them then the above option (change in ipa-kdb plugin) is the > > best way to go to mask out these entries. > I do not know what are the consequences of dropping password and keys. It means the entry cannot be used as an authentication source :) > A use case would be someone that returns back to an organization and get > his account undelete. This person will likely remember his previous > password and would expect to be authenticate with kerberos using that > password. TBH I think the likelihood of remembering an unused years old password is very low, and they would probably be expired anyway ... > Now if password and keys have been removed, he should reset his password > before being authenticate. I think it is an acceptable limitation. I think it may be a desirable feature rather than a limitation :-) Simo. From pspacek at redhat.com Wed Jun 18 17:19:17 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 18 Jun 2014 19:19:17 +0200 Subject: [Freeipa-devel] DNSSEC key metadata handling In-Reply-To: <539B2A3C.80908@redhat.com> References: <5399C270.1060608@redhat.com> <1402586393.22737.42.camel@willson.usersys.redhat.com> <5399CC20.9090907@redhat.com> <539B2A3C.80908@redhat.com> Message-ID: <53A1CA15.8020402@redhat.com> On 13.6.2014 18:43, Petr Spacek wrote: > On 12.6.2014 17:49, Petr Spacek wrote: >> On 12.6.2014 17:19, Simo Sorce wrote: >>> On Thu, 2014-06-12 at 17:08 +0200, Petr Spacek wrote: >>>> Hello list, >>>> >>>> I have realized that we need to store certain DNSSEC metadata for every >>>> (zone,key,replica) triplet. It is necessary to handle splits in replication >>>> topology. >>>> >>>> DNSSEC key can be in one of following states: >>>> - key created >>>> - published but not used for signing >>>> - published and used for signing >>>> - published and not used for signing but old signatures exist >>>> - unpublished >>>> >>>> Every state transition has to be postponed until relevant TTL expires, and of >>>> course, we need to consider TTL on all replicas. >>>> >>>> >>>> Example of a problem >>>> ==================== >>>> DNS TTL=10 units >>>> Key life time=100 units >>>> >>>> Replica=1 Key=1 Time=0 Published >>>> Replica=2 Key=1 Time=0 Published >>>> Replica=1 Key=1 Time=10 Published, signing >>>> Replica=2 Key=1 Time=10 Published, signing >>>> Replica=1 Key=2 Time=90 Generated, published, not signing yet >>>> Replica=2 Key=2 Time=90 >>>> Replica=1 Key=1 Time=100 >>>> ^^^ From time=100, all new signatures should be created with key=2 but that >>>> can break DNSSEC validation because key=2 is not available on replica=2. >>> >>> Can you explain how this break validation ? >>> Aren't signatures regenerated on each replica ? >> They are. >> >>> And so isn't each replica self-consistent ? >> Ah, sorry, I didn't mention one important detail. Keys published in the zone >> 'example.com.' have to match keys published in parent zone. There has to be a >> mechanism for synchronizing this. >> >> Validation will break if (keys published by parent) are not subset of (keys on >> replicas). >> >> Next logical step in the example above is to remove key1 from replica 1 so you >> will end replica1 having key2 and replica2 having only key1. >> >> How can we guarantee that synchronization mechanism will not wipe key1 from >> parent? Or the other way around? How can we guarantee that key2 was uploaded? >> >> Also, things will break is number of keys in parent exceeds reasonable number >> (because DNS replies will be to big etc.). >> >>>> Proposal 1 >>>> ========== >>>> - Store state and timestamps for (zone,key,replica) triplet >>>> - Do state transition only if all triplets (zone,key,?) indicate that all >>>> replicas reached desired state so the transition is safe. >>>> - This implicitly means that no transition will happen if one or more >>>> replicas >>>> is down. This is necessary otherwise DNSSEC validation can break mysteriously >>>> when keys got out of sync. >>>> >>>> dn: cn=,ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, >>>> cn=dns, dc=example >>>> idnssecKeyCreated: >>>> idnssecKeyPublished: >>>> idnssecKeyActivated: >>>> idnssecKeyInactivated: >>>> idnssecKeyDeleted: >>> >>> Why do you care for all 5 states ? >> In short, to follow RFC 6781 and all it's requirements. > > Simo and I have discussed this off-line. The final decision is to rely on > replication. The assumption is that if replication is broken, everything will > break soon anyway, so the original proposal is overkill. > > We have to store one set of timestamps somewhere to be able to follow RFC > 6781, so we decided to store it in the key-metadata object. > > I added other attributes to object class definition so it contains all > necessary metadata. The new object class idnsSecKey is now complete. > > Please note that DN in the previous example was incorrect. It is necessary to > store the metadata separately for pairs (zone, key) to cover the case where > key is shared between zones. This also nicely splits metadata from actual key > material. > > All attributes are single-valued. > MUST attributes are: > idnsSecKeyRef > idnsSecKeyCreated > idnsSecAlgorithm > > dn: cn=, cn=keys, idnsname=example.com, cn=dns, dc=example > objectClass: idnsSecKey > idnsSecKeyRef: > idnsSecKeyCreated: > idnsSecKeyPublish: > idnsSecKeyActivate: > idnsSecKeyInactive: > idnsSecKeyDelete: > idnsSecKeyZone: equivalent to bit 7 (ZONE) in [1] > idnsSecKeyRevoke: equivalent to bit 8 (REVOKE) in [1] > idnsSecKeySep: equivalent to bit 15 (SEP) in [1] > idnsSecAlgorithm: used as mnemonic in [2] I haven't heard any complains so I allocated OIDs and I'm going to implement it. Petr^2 Spacek > [1] > http://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml#dnskey-flags-1 > [2] > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > > >>> It looks to me the only relevant states are Activated and (perhaps) >>> Deactivated. >>> >>> But then again if replication is broken *many* other things are, so >>> should we *really* care to handle broken replication by adding all this >>> information ? >> We need to keep track of timestamps anyway (to follow RFC 6781) so we need >> some other way how to *make sure* that timestamps never go backwards, even if >> replication was broken and later restarted. >> >> What do you propose? >> >>>> Effectively, state machine will be controlled by max(attribute) over all >>>> replicas (for given key). >>>> >>>> Replication traffic estimation >>>> ------------------------------ >>>> Number of writes to LDAP = (State transitions per key) * (Keys per zone) * >>>> (Number of zones) * (Number of replicas) >>>> >>>> The obvious problem is that amount of traffic grows linearly with all >>>> variables. >>>> >>>> State transitions per key: 5 >>>> Keys per zone: 10 >>>> Zones: 100 >>>> Replicas: 30 >>>> Key life time: 1 month >>>> >>>> 5*10*100*30 / 1 month >>>> i.e. >>>> 150 000 writes / 1 month >>>> i.e. >>>> ~ 1 write / 17 seconds >>>> >>>> It seems like that this generates a lot of replication traffic. (Please note >>>> that number of replicas/zones/keys per zone is also quite high but it will be >>>> hard to improve scalability later if we decide to use LDAP in this way.) >>> >>> Right, and for an edge case that is already a broken state. I would >>> rather spend time on a monitoring process that warns the amdin >>> replication is broken rather than adding all this unnecessary traffic. >>> >>>> And ... our favorite question :-) >>>> What should I use for cn= ? I would propose use either FQDN >>>> of replica or value returned by LDAP whoami. >>> >>> Add to this dealing with dead/removed replicas ? I question the sanity >>> of this approach :) >>> >>>> Proposal 2 >>>> ========== >>>> Another possibility is to make timestamp attributes non-replicated and >>>> (somehow) use DNS queries to determine if the desired key is available on all >>>> other replicas before any state transition is allowed. >>>> >>>> That would require: >>>> - Full-mesh replica-to-replica connectivity >>>> - Similar amount of DNS query/response round trips (multiply ) >>>> - Security is questionable: (Maybe, I'm not sure!) Attacker could spoof DNS >>>> answers and break key rotation mechanism during bootstrap (when no keys are >>>> available) and maybe even later. >>>> >>>> It is easy to detect that key is: >>>> - published >>>> - unpublished >>>> - used for signing >>>> >>>> The problem is that there is no reliable way to detect that is a key was >>>> created/is available on replica but is not published yet and similarly that >>>> the key is published but not used for signing anymore (it would require to >>>> check all names published in the zone). >>>> >>>> I will think about it a bit more but I would like to know if full-mesh >>>> replica-to-replica connectivity is acceptable requirement or not. >>> >>> Not really, and again I question the need to do this. > > We will do some limited set DNS queries to do sanity checking, mainly when new > KSK is to-be published. In that case we need to wait until parent zone picks > it up. From npmccallum at redhat.com Wed Jun 18 21:34:41 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 18 Jun 2014 17:34:41 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1399999125.2512.9.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> Message-ID: <1403127281.6477.16.camel@ipa.example.com> On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > This patch adds support for importing tokens using RFC 6030 key > container files. This includes decryption support. For sysadmin sanity, > any tokens which fail to add will be written to the output file for > examination. The main use case here is where a small subset of a large > set of tokens fails to validate or add. Using the output file, the > sysadmin can attempt to recover these specific tokens. > > This code is implemented as a server-side script. However, it doesn't > actually need to run on the server. This was done because importing is > an odd fit for the IPA command framework: > 1. We need to write an output file. > 2. The operation may be long-running (thousands of tokens). > 3. Only admins need to perform this task and it only happens > infrequently. Attached is revision 4. I believe this addresses all the points given over the last few days in all emails. The ipa_otptoken_import.py has been significantly reworked to make it simpler and easy to test, but none of the logic has changed. I have removed most of the inheritance and sorted out most of the style issues (like map() vs comprehension). I did not change the XML parsing because it appears that network access is disabled by default. I have also included a test suite which should have 100% code coverage. It even tests for features we don't support yet (like X.509). All tests pass for me. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053.3-Implement-OTP-token-importing.patch Type: text/x-patch Size: 48774 bytes Desc: not available URL: From ssorce at redhat.com Wed Jun 18 21:48:29 2014 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 18 Jun 2014 17:48:29 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1403127281.6477.16.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1403127281.6477.16.camel@ipa.example.com> Message-ID: <1403128109.12884.76.camel@willson.usersys.redhat.com> On Wed, 2014-06-18 at 17:34 -0400, Nathaniel McCallum wrote: > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > > This patch adds support for importing tokens using RFC 6030 key > > container files. This includes decryption support. For sysadmin sanity, > > any tokens which fail to add will be written to the output file for > > examination. The main use case here is where a small subset of a large > > set of tokens fails to validate or add. Using the output file, the > > sysadmin can attempt to recover these specific tokens. > > > > This code is implemented as a server-side script. However, it doesn't > > actually need to run on the server. This was done because importing is > > an odd fit for the IPA command framework: > > 1. We need to write an output file. > > 2. The operation may be long-running (thousands of tokens). > > 3. Only admins need to perform this task and it only happens > > infrequently. > > Attached is revision 4. I believe this addresses all the points given > over the last few days in all emails. The ipa_otptoken_import.py has > been significantly reworked to make it simpler and easy to test, but > none of the logic has changed. > > I have removed most of the inheritance and sorted out most of the style > issues (like map() vs comprehension). I did not change the XML parsing > because it appears that network access is disabled by default. > > I have also included a test suite which should have 100% code coverage. > It even tests for features we don't support yet (like X.509). All tests > pass for me. > > Nathaniel +++ b/install/tools/man/ipa-otptoken-import.1 @@ -0,0 +1,36 @@ +.\" A man page for ipa-compat-manage Bad Copy&paste here ^^^ Simo. From npmccallum at redhat.com Wed Jun 18 21:54:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 18 Jun 2014 17:54:59 -0400 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1403128109.12884.76.camel@willson.usersys.redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1403127281.6477.16.camel@ipa.example.com> <1403128109.12884.76.camel@willson.usersys.redhat.com> Message-ID: <1403128499.6477.18.camel@ipa.example.com> On Wed, 2014-06-18 at 17:48 -0400, Simo Sorce wrote: > On Wed, 2014-06-18 at 17:34 -0400, Nathaniel McCallum wrote: > > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: > > > This patch adds support for importing tokens using RFC 6030 key > > > container files. This includes decryption support. For sysadmin sanity, > > > any tokens which fail to add will be written to the output file for > > > examination. The main use case here is where a small subset of a large > > > set of tokens fails to validate or add. Using the output file, the > > > sysadmin can attempt to recover these specific tokens. > > > > > > This code is implemented as a server-side script. However, it doesn't > > > actually need to run on the server. This was done because importing is > > > an odd fit for the IPA command framework: > > > 1. We need to write an output file. > > > 2. The operation may be long-running (thousands of tokens). > > > 3. Only admins need to perform this task and it only happens > > > infrequently. > > > > Attached is revision 4. I believe this addresses all the points given > > over the last few days in all emails. The ipa_otptoken_import.py has > > been significantly reworked to make it simpler and easy to test, but > > none of the logic has changed. > > > > I have removed most of the inheritance and sorted out most of the style > > issues (like map() vs comprehension). I did not change the XML parsing > > because it appears that network access is disabled by default. > > > > I have also included a test suite which should have 100% code coverage. > > It even tests for features we don't support yet (like X.509). All tests > > pass for me. > > > > Nathaniel > > +++ b/install/tools/man/ipa-otptoken-import.1 > @@ -0,0 +1,36 @@ > +.\" A man page for ipa-compat-manage > > Bad Copy&paste here ^^^ Thanks! Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0053.4-Implement-OTP-token-importing.patch Type: text/x-patch Size: 48748 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jun 19 02:50:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 18 Jun 2014 22:50:19 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <20140604154726.GI2726@redhat.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> <20140604154726.GI2726@redhat.com> Message-ID: <1403146219.6477.20.camel@ipa.example.com> On Wed, 2014-06-04 at 18:47 +0300, Alexander Bokovoy wrote: > On Thu, 01 May 2014, Nathaniel McCallum wrote: > >On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: > >> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > >> > On Tue, 11 Mar 2014, Jan Pazdziora wrote: > >> > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > >> > >> Before this patch, ipa-kdb would load global configuration on startup > >> > >> and never update it. This means that if global configuration is changed, > >> > >> the KDC never receives the new configuration until it is restarted. > >> > >> > >> > >> This patch enables caching of the global configuration with a timeout of > >> > >> 60 seconds. > >> > >> > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > >> > > > >> > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > >> > >> From: Nathaniel McCallum > >> > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 > >> > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > >> > >> > >> > >> Before this patch, ipa-kdb would load global configuration on startup and > >> > >> never update it. This means that if global configuration is changed, the > >> > >> KDC never receives the new configuration until it is restarted. > >> > >> > >> > >> This patch enables caching of the global configuration with a timeout of > >> > >> 60 seconds. > >> > >> > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > >> > > > >> > >I have only read the code and it looks sane, so depending on how much > >> > >you consider my word about code-reading worth, ack. > >> > > > >> > >However, my gut feeling is that my preferred way of handling the issue > >> > >(without knowing much about the background of the ticket) would > >> > >probably be a HUP signal handler or something similar, rather than > >> > >polling for current values with the value timeout. This patch > >> > >introduces small nondeterminism to the behaviour when the usage of the > >> > >new values cannot really be enfoced by the admin (without the daemon > >> > >restart). > >> > Thing is, we need the update to happen when other, non-root process > >> > makes the changes -- in our case when IPA server running under httpd > >> > privileges performs series of MS-RPC calls towards smbd which lead to > >> > creating certain LDAP objects. httpd couldn't send SIGHUP to a process > >> > not owned by httpd's effective user (non-root). > >> > >> Yes but this is not really the way to go. > >> > >> The proper fix is to use syncrepl/persistent search to get a > >> notification of when we need to reload the configuration. > >> > >> On the patch itself I have a NACK due to this syntax used in various > >> places: function()->attribute > >> > >> don't. do. that. ever. > >> > >> assign whatever come from the function to a local variable and *check* > >> it is not null, *then* use it. > > > >Attached patch fixes the NACK issue, but does not address the question > >of the larger approach. Do we need to take a different approach? If so, > >what is it? > > I've tested the patch but was unable to spot any activity to refresh the > configuration after I've updated it with > ipa config-mod --ipaconfigstring=KDC:Disable\ Lockout > > At least, dirsrv logs didn't show me any attempt to re-read IPA config > past the change. I spent extensive time testing this today. I am unable to reproduce a failure to reload data from LDAP. If I make the change using "ipa config-mod", wait a minute and run a kinit the KDC always gets the new values. So it works for me. However, I did uncover a subtle bug with regard to ipaconfigstring which would cause it to never to be unset once set. Perhaps you were running into this? The new attached version fixes this bug. Everything appears to work... Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0044.2-Periodically-refresh-global-ipa-kdb-configuration.patch Type: text/x-patch Size: 11637 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 19 07:06:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 09:06:56 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403107776.12884.69.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> Message-ID: <53A28C10.10509@redhat.com> On 06/18/2014 06:09 PM, Simo Sorce wrote: > On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: >> On 06/18/2014 04:45 PM, Simo Sorce wrote: >>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: >>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: >>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: ... >>> Right, if we allow setting userPassword this would happen, but then if >>> we allow setting userPassword do we also generate Kerberos Keys ? > >> Currently setting of the userPassword (add entry or mod entry) triggers >> generation of krb keys (I guess in ipa-kdb). > > No it happen in ipa-pwd-extop > >>> If this is the case then we probably need to change the pre-bind plugin >>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). > >> Do you mean to prevent ipa-kdb to generate krb keys when the this is >> Delete/Staging > > No I mean to prevent the ipa-kdb driver (it's the KDC driver) from > returning any key even if present for entries in those suffixes. IMO we should definitely allow provisioning system to set userPassword, looks like a valid use case to me. >>> I was actually planning to use staging to allow kadmin to create >>> entries, so we need to be careful how ipa-kdb limits access to staging, >>> I would guess it should pretend KrbKerberosKey is not present for those >>> entries. When someone creates user with plain text userPassword, we normally hash it and also generate krbPrincipalKey, right? Should we then simply avoid both operations in the staging area, let the password be stored in plain text and let the Kerberos keys and attributes be generated during user activation? It will happen via recreating the entry anyway, so the right operations should be triggered. Martin From pspacek at redhat.com Thu Jun 19 07:43:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 09:43:06 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? Message-ID: <53A2948A.7000308@redhat.com> Hello list, the thread "named's LDAP connection hangs" on freeipa-users list [1] opened question "Why do we use Kerberos for named<->DS connection? Named connects over LDAPI to local DS instance anyway." Maybe we can get rid of Kerberos for this particular connection and use autobind instead. It would make it more reliable and effective. As a side effect, named will be able to start even if KDC is down for some reason. It partially solves chicken-egg problem during IPA start-up. I wasn't around when it bind-dyndb-ldap was designed so I don't know historical reasons. [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html -- Petr^2 Spacek From sbose at redhat.com Thu Jun 19 08:01:10 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 19 Jun 2014 10:01:10 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2948A.7000308@redhat.com> References: <53A2948A.7000308@redhat.com> Message-ID: <20140619080110.GK16782@localhost.localdomain> On Thu, Jun 19, 2014 at 09:43:06AM +0200, Petr Spacek wrote: > Hello list, > > the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > question "Why do we use Kerberos for named<->DS connection? Named connects > over LDAPI to local DS instance anyway." > > Maybe we can get rid of Kerberos for this particular connection and use > autobind instead. It would make it more reliable and effective. > > As a side effect, named will be able to start even if KDC is down for some > reason. It partially solves chicken-egg problem during IPA start-up. > > I wasn't around when it bind-dyndb-ldap was designed so I don't know > historical reasons. I think there are two differences: # ldapexop -H 'ldapi://%2fvar%2frun%2fslapd-IPA20-DEVEL.socket' whoami SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=Directory Manager # ldapexop -H 'ldapi://%2fvar%2frun%2fslapd-IPA20-DEVEL.socket' whoami -Y GSSAPI SASL/GSSAPI authentication started SASL username: DNS/ipa20-devel.ipa20.devel at IPA20.DEVEL SASL SSF: 56 SASL data security layer installed. dn: krbprincipalname=dns/ipa20-devel.ipa20.devel at ipa20.devel,cn=services,cn=accounts,dc=ipa20,dc=devel With Kerberos you bind with a specific DN and all access control rule can be applied for the connection. Additionally you have an SSF level. I think most of our plugin which requires a secure connection check not only SSF but check if the connection is coming via the ldapi socket as well but there might some which miss this check. We use LDAPI+Kerberos in samba as well to access the IPA DS, but I agree that samba is not that important for IPA and there is no chicken-egg problem. bye, Sumit > > [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From tjaalton at ubuntu.com Thu Jun 19 08:18:02 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 19 Jun 2014 11:18:02 +0300 Subject: [Freeipa-devel] freeipa and Debian multiarch triplet Message-ID: <53A29CBA.3020505@ubuntu.com> Hi While porting the client code for current master I noticed that there are some hardcodings to use /usr/lib{,64} paths for various things. This is problematic for Debian and it's derivatives, since we use "proper multiarch(tm)" which means paths like /usr/lib/{i386-linux-gnu,x86_64-linux-gnu} and other GNU triplets. I'd need to force freeipa to build only on these two archs by setting FOO = /usr/lib/i386-linux-gnu and FOO_64 = /usr/lib/x86_64-linux-gnu. Ideas for solving it cleanly so that at least freeipa-client would be possible to build on other archs too? For the server at least 389 needs updates too, since it hardcodes paths the same way. From abokovoy at redhat.com Thu Jun 19 09:02:52 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 12:02:52 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2948A.7000308@redhat.com> References: <53A2948A.7000308@redhat.com> Message-ID: <20140619090252.GD7233@redhat.com> On Thu, 19 Jun 2014, Petr Spacek wrote: >Hello list, > >the thread "named's LDAP connection hangs" on freeipa-users list [1] >opened question "Why do we use Kerberos for named<->DS connection? >Named connects over LDAPI to local DS instance anyway." > >Maybe we can get rid of Kerberos for this particular connection and >use autobind instead. It would make it more reliable and effective. > >As a side effect, named will be able to start even if KDC is down for >some reason. It partially solves chicken-egg problem during IPA >start-up. > >I wasn't around when it bind-dyndb-ldap was designed so I don't know >historical reasons. My primary worry is the fact that any break in named/bind-dyndb-ldap could be then exploited to have access to all key material. In the case of GSSAPI you are confined to whatever ACIs allow for dns/ principal. Samba case goes further -- I specifically added GSSAPI bind to Samba code LDAP code to allow splitting DCs and file servers while being able to use the same ipasam module securely, in addition to the usual ACI limitations. For named what we could do is to have named+ldapi:// access mapped to specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth achieving essentially the same thing, if we would use dn: cn=config nsslapd-ldapimaptoentries: on nsslapd-ldapiuidnumbertype: uidNumber nsslapd-ldapigidnumbertype: gidNumber nsslapd-ldapientrysearchbase: cn=accounts,$SUFFIX and dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX uidNumber: gidNumber: and then define ACIs equal to what we have for DNS service now. There is an issue of uid/gid being different on different platforms, though but it is doable. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jun 19 10:29:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 12:29:36 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619090252.GD7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> Message-ID: <53A2BB90.6070404@redhat.com> On 19.6.2014 11:02, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Petr Spacek wrote: >> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >> question "Why do we use Kerberos for named<->DS connection? Named connects >> over LDAPI to local DS instance anyway." >> >> Maybe we can get rid of Kerberos for this particular connection and use >> autobind instead. It would make it more reliable and effective. >> >> As a side effect, named will be able to start even if KDC is down for some >> reason. It partially solves chicken-egg problem during IPA start-up. >> >> I wasn't around when it bind-dyndb-ldap was designed so I don't know >> historical reasons. > My primary worry is the fact that any break in named/bind-dyndb-ldap > could be then exploited to have access to all key material. In the case of > GSSAPI you are confined to whatever ACIs allow for dns/ principal. IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I don't see any difference from using SASL/GSSAPI/Kerberos. > Samba case goes further -- I specifically added GSSAPI bind to Samba > code LDAP code to allow splitting DCs and file servers while being able > to use the same ipasam module securely, in addition to the usual > ACI limitations. Named has only one function (i.e. DNS server with support for DNS updates). I don't think that there is meaningful separation. > For named what we could do is to have named+ldapi:// access mapped to > specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth This is OpenLDAP-ism, right? > achieving essentially the same thing, if we would use > dn: cn=config > nsslapd-ldapimaptoentries: on > nsslapd-ldapiuidnumbertype: uidNumber > nsslapd-ldapigidnumbertype: gidNumber > nsslapd-ldapientrysearchbase: cn=accounts,$SUFFIX This is part of default IPA installation. > and > > dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX This object already exists for every single DNS server, which is exactly the problem. Multiple servers are running under the same UID/GID pair on Fedora. > uidNumber: > gidNumber: > > and then define ACIs equal to what we have for DNS service now. ACIs are already in place and associated with the principals mentioned above. > There is an issue of uid/gid being different on different platforms, > though but it is doable. I can see the problem with UID/GID mapping to multiple different principals. We can't remove these principals because they are used on server side for DNS updates. Maybe we can create autobind mapping objects in some non-replicated part of the tree. That would solve the problem with different UID/GIDs on different platforms and also mapping UID/GID mapping to multiple principals because one replica would see only one mapping object for given UID/GID. It would be even better if DS could do something like: dn: uidNumber=+gidNumber=, cn=autobind, cn=config uidNumber: gidNumber: autobindDN: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX I.e. add one layer of indirection to autobind evaluation. That would allow us to have autobind object in non-replicated part of the tree and at the same time centralize ACIs under one DN (i.e. principal) in replicated part of the tree. I guess that it would require DS modification... -- Petr^2 Spacek From tbordaz at redhat.com Thu Jun 19 10:36:46 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 19 Jun 2014 12:36:46 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A28C10.10509@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> <53A28C10.10509@redhat.com> Message-ID: <53A2BD3E.3000401@redhat.com> On 06/19/2014 09:06 AM, Martin Kosek wrote: > On 06/18/2014 06:09 PM, Simo Sorce wrote: >> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: >>> On 06/18/2014 04:45 PM, Simo Sorce wrote: >>>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: >>>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: >>>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >>>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > ... >>>> Right, if we allow setting userPassword this would happen, but then if >>>> we allow setting userPassword do we also generate Kerberos Keys ? >>> Currently setting of the userPassword (add entry or mod entry) triggers >>> generation of krb keys (I guess in ipa-kdb). >> No it happen in ipa-pwd-extop >> >>>> If this is the case then we probably need to change the pre-bind plugin >>>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). >>> Do you mean to prevent ipa-kdb to generate krb keys when the this is >>> Delete/Staging >> No I mean to prevent the ipa-kdb driver (it's the KDC driver) from >> returning any key even if present for entries in those suffixes. > IMO we should definitely allow provisioning system to set userPassword, looks > like a valid use case to me. > >>>> I was actually planning to use staging to allow kadmin to create >>>> entries, so we need to be careful how ipa-kdb limits access to staging, >>>> I would guess it should pretend KrbKerberosKey is not present for those >>>> entries. > When someone creates user with plain text userPassword, we normally hash it and > also generate krbPrincipalKey, right? Should we then simply avoid both > operations in the staging area, let the password be stored in plain text and > let the Kerberos keys and attributes be generated during user activation? It > will happen via recreating the entry anyway, so the right operations should be > triggered. Setting a Staging password policy would keep userPassword in clear. This is needed because generation of krb keys is done by ipa-pwd on an unhashed password. For kerberos authentication, to limit ipa-pwd to generate the keys only in Active container, we need to provide a scope to that plugin. I did not find such scope and needs to be implemented. When deleting an Active user, krb keys are removed. That means that only Active entries have krb keys. For simple bind, we can do simple bind on Active entry. we can not bind with Delete user as userPassword has been removed. Stage users may contain userPassword (in clear), we can rely on a cos to lock the entry or reject a bind in pre-op plugin. thierry > > Martin From pviktori at redhat.com Thu Jun 19 10:52:52 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Jun 2014 12:52:52 +0200 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <53A1B45D.9020609@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> Message-ID: <53A2C104.8070102@redhat.com> I'll address the other issues separately. On 06/18/2014 05:46 PM, Martin Kosek wrote: > 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: > No such virtual command" error triggered by "cert-show" command. > > We will need to add the permission "System: Read Virtual Operations" that Honza > is creating also to "Host Administrators" to fix that part. I'm not familiar with Honza's effort, but that seems right. I'm curious, why don't we just allow reading virtual operations by anybody? It seems to me they're the same in every IPA installation, what's there to hide? Anyway, I poked around in how it works now: for cert-show you need write access to the objectClass of the "retrieve certificate" virt op entry. So that right you can actually remove the "ipaVirtualOperation" objectClass. Aand the new "Anonymous read access to containers" ACI has a (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for a virt op can allow everyone see that virt op). Shouldn't we base the check on some other attribute instead? And curiously, for cert-find there is no virt op based access check. -- Petr? From tbabej at redhat.com Thu Jun 19 10:52:58 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Jun 2014 12:52:58 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A1535C.2030402@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> Message-ID: <53A2C10A.2080406@redhat.com> On 06/18/2014 10:52 AM, Petr Viktorin wrote: > On 06/17/2014 02:15 PM, Tomas Babej wrote: >> >> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>> On 17.06.2014 11:16, Martin Kosek wrote: > >> Attached is a new version of patch 226, and a new patch 228, which moves >> the paths from installers to the paths module. > > In patch 226, there's another "certificated" typo in > remove_ca_cert_from_systemwide_ca_store > >> I greped the repository, and I do not see many paths lurking around any >> more, there are only some in the error messages (as these can't be >> reliably replaced automatically, and will need some manual love). >> >> If you see any forgotten paths, which should be added to the module, let >> me know. > > > I see another duplicate: > SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" > SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = > "/var/lib/sss/pubconf/krb5.include.d/" > > > Rather than using e.g. > filename = paths.VAR_KERBEROS_KRB5KDC_DIR + file > It would be cleaner to use > filename = os.path.join(paths.VAR_KERBEROS_KRB5KDC_DIR, file) > > Fixed all mentioned issues. I also attached a patch 230, which removes the base Authconfig class. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0230-ipaplatform-Drop-the-base-authconfig-class.patch Type: text/x-patch Size: 6053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-3-ipaplatform-Move-paths-from-installers-to-paths-modu.patch Type: text/x-patch Size: 61141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-3-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4755 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jun 19 11:13:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 14:13:48 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2BB90.6070404@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> Message-ID: <20140619111348.GE7233@redhat.com> On Thu, 19 Jun 2014, Petr Spacek wrote: >On 19.6.2014 11:02, Alexander Bokovoy wrote: >>On Thu, 19 Jun 2014, Petr Spacek wrote: >>>the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >>>question "Why do we use Kerberos for named<->DS connection? Named connects >>>over LDAPI to local DS instance anyway." >>> >>>Maybe we can get rid of Kerberos for this particular connection and use >>>autobind instead. It would make it more reliable and effective. >>> >>>As a side effect, named will be able to start even if KDC is down for some >>>reason. It partially solves chicken-egg problem during IPA start-up. >>> >>>I wasn't around when it bind-dyndb-ldap was designed so I don't know >>>historical reasons. >>My primary worry is the fact that any break in named/bind-dyndb-ldap >>could be then exploited to have access to all key material. In the case of >>GSSAPI you are confined to whatever ACIs allow for dns/ principal. >IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so >I don't see any difference from using SASL/GSSAPI/Kerberos. My impression was that you wanted autobind to Directory Manager (root autobind), this is what I don't want to support, for sure. >>Samba case goes further -- I specifically added GSSAPI bind to Samba >>code LDAP code to allow splitting DCs and file servers while being able >>to use the same ipasam module securely, in addition to the usual >>ACI limitations. >Named has only one function (i.e. DNS server with support for DNS >updates). I don't think that there is meaningful separation. > >>For named what we could do is to have named+ldapi:// access mapped to >>specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >This is OpenLDAP-ism, right? yes, this is what the client code reports. 389-ds server sees proper dn: # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ --setattr=uid=named ----------------------------------------------- Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" ----------------------------------------------- Principal: DNS/ipa-01.t.vda.li at T.VDA.LI Managed by: ipa-01.t.vda.li # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' SASL/EXTERNAL authentication started SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base (default) with scope subtree # filter: cn=config # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 and here is what we see in the logs: [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > >> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >This object already exists for every single DNS server, which is >exactly the problem. Multiple servers are running under the same >UID/GID pair on Fedora. No, it is not a problem because there are multiple objects, one per server. >>There is an issue of uid/gid being different on different platforms, >>though but it is doable. >I can see the problem with UID/GID mapping to multiple different >principals. We can't remove these principals because they are used on >server side for DNS updates. > >Maybe we can create autobind mapping objects in some non-replicated >part of the tree. That would solve the problem with different UID/GIDs >on different platforms and also mapping UID/GID mapping to multiple >principals because one replica would see only one mapping object for >given UID/GID. No, I don't think we ever need to modify anything here apart from giving posixgroup/posixaccount object classes to the DNS principal per server and setting their properties. As you can see above, it simply works. I actually tested it with named too, by setting diff -up /etc/named.conf.old /etc/named.conf --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 @@ -45,7 +45,7 @@ dynamic-db "ipa" { arg "base cn=dns, dc=t,dc=vda,dc=li"; arg "fake_mname ipa-01.t.vda.li."; arg "auth_method sasl"; - arg "sasl_mech GSSAPI"; - arg "sasl_user DNS/ipa-01.t.vda.li"; + arg "sasl_mech EXTERNAL"; + arg "sasl_user named"; arg "serial_autoincrement yes"; }; and named successfully started, with 389-ds showing autobind to the same krprincipalname=dns/... in the logs. -- / Alexander Bokovoy From pspacek at redhat.com Thu Jun 19 11:26:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 13:26:50 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619111348.GE7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> Message-ID: <53A2C8FA.7000803@redhat.com> On 19.6.2014 13:13, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Petr Spacek wrote: >> On 19.6.2014 11:02, Alexander Bokovoy wrote: >>> On Thu, 19 Jun 2014, Petr Spacek wrote: >>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >>>> question "Why do we use Kerberos for named<->DS connection? Named connects >>>> over LDAPI to local DS instance anyway." >>>> >>>> Maybe we can get rid of Kerberos for this particular connection and use >>>> autobind instead. It would make it more reliable and effective. >>>> >>>> As a side effect, named will be able to start even if KDC is down for some >>>> reason. It partially solves chicken-egg problem during IPA start-up. >>>> >>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know >>>> historical reasons. >>> My primary worry is the fact that any break in named/bind-dyndb-ldap >>> could be then exploited to have access to all key material. In the case of >>> GSSAPI you are confined to whatever ACIs allow for dns/ principal. >> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I >> don't see any difference from using SASL/GSSAPI/Kerberos. > My impression was that you wanted autobind to Directory Manager (root > autobind), this is what I don't want to support, for sure. > >>> Samba case goes further -- I specifically added GSSAPI bind to Samba >>> code LDAP code to allow splitting DCs and file servers while being able >>> to use the same ipasam module securely, in addition to the usual >>> ACI limitations. >> Named has only one function (i.e. DNS server with support for DNS updates). >> I don't think that there is meaningful separation. >> >>> For named what we could do is to have named+ldapi:// access mapped to >>> specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >> This is OpenLDAP-ism, right? > yes, this is what the client code reports. 389-ds server sees proper dn: > > # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ > --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ > --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ > --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ > --setattr=uid=named > ----------------------------------------------- > Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" > ----------------------------------------------- > Principal: DNS/ipa-01.t.vda.li at T.VDA.LI > Managed by: ipa-01.t.vda.li > > # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H > ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' > SASL/EXTERNAL authentication started > SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: cn=config > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > and here is what we see in the logs: > [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND > dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > > [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND > dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > method=sasl version=3 mech=EXTERNAL > [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 > etime=0 > dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > > [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" > scope=2 filter="(cn=config)" attrs=ALL > [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 > etime=0 > [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > > >> >>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >> This object already exists for every single DNS server, which is exactly the >> problem. Multiple servers are running under the same UID/GID pair on Fedora. > No, it is not a problem because there are multiple objects, one per > server. >>> There is an issue of uid/gid being different on different platforms, >>> though but it is doable. >> I can see the problem with UID/GID mapping to multiple different principals. >> We can't remove these principals because they are used on server side for >> DNS updates. >> >> Maybe we can create autobind mapping objects in some non-replicated part of >> the tree. That would solve the problem with different UID/GIDs on different >> platforms and also mapping UID/GID mapping to multiple principals because >> one replica would see only one mapping object for given UID/GID. > No, I don't think we ever need to modify anything here apart from giving > posixgroup/posixaccount object classes to the DNS principal per server > and setting their properties. > > As you can see above, it simply works. I actually tested it with named > too, by setting > > diff -up /etc/named.conf.old /etc/named.conf > --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 > +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 > @@ -45,7 +45,7 @@ dynamic-db "ipa" { > arg "base cn=dns, dc=t,dc=vda,dc=li"; > arg "fake_mname ipa-01.t.vda.li."; > arg "auth_method sasl"; > - arg "sasl_mech GSSAPI"; > - arg "sasl_user DNS/ipa-01.t.vda.li"; > + arg "sasl_mech EXTERNAL"; > + arg "sasl_user named"; > arg "serial_autoincrement yes"; > }; > > and named successfully started, with 389-ds showing autobind to the same > krprincipalname=dns/... in the logs. Sure, this will work for single principal. Things will break if there is more than one object with given uidNumber and gidNumber. See figure 13.1 on page https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/configuring-special-binds.html#autobind-enabling That is why I proposed the 'indirection object' (under cn=config) hack. -- Petr^2 Spacek From abokovoy at redhat.com Thu Jun 19 11:33:36 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 14:33:36 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2C8FA.7000803@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <53A2C8FA.7000803@redhat.com> Message-ID: <20140619113336.GF7233@redhat.com> On Thu, 19 Jun 2014, Petr Spacek wrote: >On 19.6.2014 13:13, Alexander Bokovoy wrote: >>On Thu, 19 Jun 2014, Petr Spacek wrote: >>>On 19.6.2014 11:02, Alexander Bokovoy wrote: >>>>On Thu, 19 Jun 2014, Petr Spacek wrote: >>>>>the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >>>>>question "Why do we use Kerberos for named<->DS connection? Named connects >>>>>over LDAPI to local DS instance anyway." >>>>> >>>>>Maybe we can get rid of Kerberos for this particular connection and use >>>>>autobind instead. It would make it more reliable and effective. >>>>> >>>>>As a side effect, named will be able to start even if KDC is down for some >>>>>reason. It partially solves chicken-egg problem during IPA start-up. >>>>> >>>>>I wasn't around when it bind-dyndb-ldap was designed so I don't know >>>>>historical reasons. >>>>My primary worry is the fact that any break in named/bind-dyndb-ldap >>>>could be then exploited to have access to all key material. In the case of >>>>GSSAPI you are confined to whatever ACIs allow for dns/ principal. >>>IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so I >>>don't see any difference from using SASL/GSSAPI/Kerberos. >>My impression was that you wanted autobind to Directory Manager (root >>autobind), this is what I don't want to support, for sure. >> >>>>Samba case goes further -- I specifically added GSSAPI bind to Samba >>>>code LDAP code to allow splitting DCs and file servers while being able >>>>to use the same ipasam module securely, in addition to the usual >>>>ACI limitations. >>>Named has only one function (i.e. DNS server with support for DNS updates). >>>I don't think that there is meaningful separation. >>> >>>>For named what we could do is to have named+ldapi:// access mapped to >>>>specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >>>This is OpenLDAP-ism, right? >>yes, this is what the client code reports. 389-ds server sees proper dn: >> >># ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ >> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ >> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ >> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ >> --setattr=uid=named >>----------------------------------------------- >>Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" >>----------------------------------------------- >> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI >> Managed by: ipa-01.t.vda.li >> >># su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H >>ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' >>SASL/EXTERNAL authentication started >>SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth >>SASL SSF: 0 >># extended LDIF >># >># LDAPv3 >># base (default) with scope subtree >># filter: cn=config >># requesting: ALL >># >> >># search result >>search: 2 >>result: 0 Success >> >># numResponses: 1 >> >>and here is what we see in the logs: >>[19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND >>dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> >>[19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND >>dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >>method=sasl version=3 mech=EXTERNAL >>[19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 >>etime=0 >>dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> >>[19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" >>scope=2 filter="(cn=config)" attrs=ALL >>[19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 >>etime=0 >>[19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND >> >> >>> >>>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >>>This object already exists for every single DNS server, which is exactly the >>>problem. Multiple servers are running under the same UID/GID pair on Fedora. >>No, it is not a problem because there are multiple objects, one per >>server. >>>>There is an issue of uid/gid being different on different platforms, >>>>though but it is doable. >>>I can see the problem with UID/GID mapping to multiple different principals. >>>We can't remove these principals because they are used on server side for >>>DNS updates. >>> >>>Maybe we can create autobind mapping objects in some non-replicated part of >>>the tree. That would solve the problem with different UID/GIDs on different >>>platforms and also mapping UID/GID mapping to multiple principals because >>>one replica would see only one mapping object for given UID/GID. >>No, I don't think we ever need to modify anything here apart from giving >>posixgroup/posixaccount object classes to the DNS principal per server >>and setting their properties. >> >>As you can see above, it simply works. I actually tested it with named >>too, by setting >> >>diff -up /etc/named.conf.old /etc/named.conf >>--- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 >>+++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 >>@@ -45,7 +45,7 @@ dynamic-db "ipa" { >> arg "base cn=dns, dc=t,dc=vda,dc=li"; >> arg "fake_mname ipa-01.t.vda.li."; >> arg "auth_method sasl"; >>- arg "sasl_mech GSSAPI"; >>- arg "sasl_user DNS/ipa-01.t.vda.li"; >>+ arg "sasl_mech EXTERNAL"; >>+ arg "sasl_user named"; >> arg "serial_autoincrement yes"; >>}; >> >>and named successfully started, with 389-ds showing autobind to the same >>krprincipalname=dns/... in the logs. > >Sure, this will work for single principal. Things will break if there >is more than one object with given uidNumber and gidNumber. > >See figure 13.1 on page >https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/configuring-special-binds.html#autobind-enabling > >That is why I proposed the 'indirection object' (under cn=config) hack. I think it is better to extend the logic in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user() to further process multiple returned entries, selecting those that are Kerberos principals (object class can be defined similar to existing ldapi attributes in cn=config) and then pick up the one that corresponds to the host 389-ds is running on. If there are still multiple of them, only then reject the bind. -- / Alexander Bokovoy From pviktori at redhat.com Thu Jun 19 11:39:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Jun 2014 13:39:47 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users Message-ID: <53A2CC03.4010508@redhat.com> See commit message. This was found in the review of host write permissions (my patches 0578-0579). -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0580.3-Allow-read-access-to-masters-but-not-their-services-.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: From pviktori at redhat.com Thu Jun 19 11:41:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Jun 2014 13:41:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed In-Reply-To: <53A1B45D.9020609@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> Message-ID: <53A2CC5D.9000708@redhat.com> On 06/18/2014 05:46 PM, Martin Kosek wrote: > On 06/11/2014 06:39 PM, Petr Viktorin wrote: >> Patch 0578 does the conversion >> >> Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and provides >> permissions needed for automatic enrollment (from >> http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser) > > 1) Inconsistent casing in permission names: > > System: Add Hosts > System: Add krbPrincipalName to a host > System: Enroll a host > System: Manage Host SSH Public Keys > System: Manage host keytab > System: Modify Hosts > System: Remove Hosts Fixed > 2) This ACI does not look right, missing enrolledby: > > + 'System: Enroll a host': { > + 'ipapermright': {'write'}, > + 'ipapermdefaultattr': {'objectclass'}, > > When I fixed 2) via permission-mod, client enrollment with user with "Host > Administrators" privilege worked fine. Added > 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: > No such virtual command" error triggered by "cert-show" command. Virtual operations seem to be quite a can of worms. I've sent a separate reply for these. > We will need to add the permission "System: Read Virtual Operations" that Honza > is creating also to "Host Administrators" to fix that part. > > > 4) I ran unit tests and few missing attributes: > - update hosts ACI should get "macaddress" attribute Added > 5) I hit one nasty issue when running the unit tests (when my master stopped > working as host account was deleted) - host_is_master function in baseldap no > longer works as we hid cn=masters from regular users: > > def host_is_master(ldap, fqdn): > """ > Check to see if this host is a master. > > Raises an exception if a master, otherwise returns nothing. > """ > master_dn = DN(('cn', fqdn), ('cn', 'masters'), ('cn', 'ipa'), ('cn', > 'etc'), api. env.basedn) > try: > ldap.get_entry(master_dn, ['objectclass']) > raise errors.ValidationError(name='hostname', error=_('An IPA master > host cannot be deleted or disabled')) > except errors.NotFound: > # Good, not a master > return > > This means, that host-del on a master machine or service-del on master service > happily passes. > > We need to make sure this functionality is still working after the permission > refactoring. Should we reconsider the cn=masters tree and allow authenticated > users see the list of IPA servers (without digging into any other detail like > services) then? Nasty indeed, thanks for the catch! Sent as patch 0590, since it's a different issue than converting the host permissions. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0578.3-Convert-Host-default-permissions-to-managed.patch Type: text/x-patch Size: 20371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0579.3-host-permissions-Allow-writing-attributes-needed-for.patch Type: text/x-patch Size: 4702 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 19 12:13:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:13:13 +0200 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <53A2C104.8070102@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> Message-ID: <53A2D3D9.6000906@redhat.com> On 06/19/2014 12:52 PM, Petr Viktorin wrote: > I'll address the other issues separately. > > On 06/18/2014 05:46 PM, Martin Kosek wrote: >> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: >> No such virtual command" error triggered by "cert-show" command. >> >> We will need to add the permission "System: Read Virtual Operations" that Honza >> is creating also to "Host Administrators" to fix that part. > > I'm not familiar with Honza's effort, but that seems right. > I'm curious, why don't we just allow reading virtual operations by anybody? It > seems to me they're the same in every IPA installation, what's there to hide? They are indeed the same. This is an old (very old) mean to check access when ACI cannot be used. I admit it is a bit clumsy. I agree that we should indeed allow reading the list of virtual operations as the list can be retrieved from our git anyway. The virtual operations do not even show list of it's members as permissions hold it, so it really should not leak any sensitive information. > Anyway, I poked around in how it works now: for cert-show you need write access > to the objectClass of the "retrieve certificate" virt op entry. So that right > you can actually remove the "ipaVirtualOperation" objectClass. > Aand the new "Anonymous read access to containers" ACI has a > (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for a virt > op can allow everyone see that virt op). > Shouldn't we base the check on some other attribute instead? > > And curiously, for cert-find there is no virt op based access check. I think we should eventually invent something better than current virtual operations. For now (4.0), we should do something simple and straightforward. The simplest thing to do is stick to the old behavior, i.e.: 1) Remove the (!(objectclass=ipaVirtualOperation)) part of the filter (should improve performance, right?) 2) Remove the ipaVirtualOperation objectclass again from the virtual operations as it would be useless after change 1) Martin From mkosek at redhat.com Thu Jun 19 12:19:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:19:04 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2CC03.4010508@redhat.com> References: <53A2CC03.4010508@redhat.com> Message-ID: <53A2D538.2050704@redhat.com> On 06/19/2014 01:39 PM, Petr Viktorin wrote: > See commit message. > > This was found in the review of host write permissions (my patches 0578-0579). Wouldn't it be better to filter based on objectclass? I.e.: (targetfilter="(!(objectclass=ipaConfigObject))" instead of DN based target filter? It seems to me that it is more resilient to changes in LDAP structure, in case we change RDN or make one more level like (just example): cn=DNSSEC,cn=DNS,cn=ipa.master.test,... Martin From abokovoy at redhat.com Thu Jun 19 12:31:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 15:31:45 +0300 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1403146219.6477.20.camel@ipa.example.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> <20140604154726.GI2726@redhat.com> <1403146219.6477.20.camel@ipa.example.com> Message-ID: <20140619123145.GH7233@redhat.com> On Wed, 18 Jun 2014, Nathaniel McCallum wrote: >On Wed, 2014-06-04 at 18:47 +0300, Alexander Bokovoy wrote: >> On Thu, 01 May 2014, Nathaniel McCallum wrote: >> >On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: >> >> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: >> >> > On Tue, 11 Mar 2014, Jan Pazdziora wrote: >> >> > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: >> >> > >> Before this patch, ipa-kdb would load global configuration on startup >> >> > >> and never update it. This means that if global configuration is changed, >> >> > >> the KDC never receives the new configuration until it is restarted. >> >> > >> >> >> > >> This patch enables caching of the global configuration with a timeout of >> >> > >> 60 seconds. >> >> > >> >> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >> >> > > >> >> > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 >> >> > >> From: Nathaniel McCallum >> >> > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 >> >> > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration >> >> > >> >> >> > >> Before this patch, ipa-kdb would load global configuration on startup and >> >> > >> never update it. This means that if global configuration is changed, the >> >> > >> KDC never receives the new configuration until it is restarted. >> >> > >> >> >> > >> This patch enables caching of the global configuration with a timeout of >> >> > >> 60 seconds. >> >> > >> >> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >> >> > > >> >> > >I have only read the code and it looks sane, so depending on how much >> >> > >you consider my word about code-reading worth, ack. >> >> > > >> >> > >However, my gut feeling is that my preferred way of handling the issue >> >> > >(without knowing much about the background of the ticket) would >> >> > >probably be a HUP signal handler or something similar, rather than >> >> > >polling for current values with the value timeout. This patch >> >> > >introduces small nondeterminism to the behaviour when the usage of the >> >> > >new values cannot really be enfoced by the admin (without the daemon >> >> > >restart). >> >> > Thing is, we need the update to happen when other, non-root process >> >> > makes the changes -- in our case when IPA server running under httpd >> >> > privileges performs series of MS-RPC calls towards smbd which lead to >> >> > creating certain LDAP objects. httpd couldn't send SIGHUP to a process >> >> > not owned by httpd's effective user (non-root). >> >> >> >> Yes but this is not really the way to go. >> >> >> >> The proper fix is to use syncrepl/persistent search to get a >> >> notification of when we need to reload the configuration. >> >> >> >> On the patch itself I have a NACK due to this syntax used in various >> >> places: function()->attribute >> >> >> >> don't. do. that. ever. >> >> >> >> assign whatever come from the function to a local variable and *check* >> >> it is not null, *then* use it. >> > >> >Attached patch fixes the NACK issue, but does not address the question >> >of the larger approach. Do we need to take a different approach? If so, >> >what is it? >> >> I've tested the patch but was unable to spot any activity to refresh the >> configuration after I've updated it with >> ipa config-mod --ipaconfigstring=KDC:Disable\ Lockout >> >> At least, dirsrv logs didn't show me any attempt to re-read IPA config >> past the change. > >I spent extensive time testing this today. I am unable to reproduce a >failure to reload data from LDAP. If I make the change using "ipa >config-mod", wait a minute and run a kinit the KDC always gets the new >values. So it works for me. > >However, I did uncover a subtle bug with regard to ipaconfigstring which >would cause it to never to be unset once set. Perhaps you were running >into this? Yes, that seems a likely cause. At least, I cannot reproduce it again. > >The new attached version fixes this bug. Everything appears to work... Thanks, ACK. -- / Alexander Bokovoy From ssorce at redhat.com Thu Jun 19 12:33:10 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 08:33:10 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A28C10.10509@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> <53A28C10.10509@redhat.com> Message-ID: <1403181190.12884.78.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: > On 06/18/2014 06:09 PM, Simo Sorce wrote: > > On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: > >> On 06/18/2014 04:45 PM, Simo Sorce wrote: > >>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: > >>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: > >>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: > >>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: > >>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > ... > >>> Right, if we allow setting userPassword this would happen, but then if > >>> we allow setting userPassword do we also generate Kerberos Keys ? > > > >> Currently setting of the userPassword (add entry or mod entry) triggers > >> generation of krb keys (I guess in ipa-kdb). > > > > No it happen in ipa-pwd-extop > > > >>> If this is the case then we probably need to change the pre-bind plugin > >>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). > > > >> Do you mean to prevent ipa-kdb to generate krb keys when the this is > >> Delete/Staging > > > > No I mean to prevent the ipa-kdb driver (it's the KDC driver) from > > returning any key even if present for entries in those suffixes. > > IMO we should definitely allow provisioning system to set userPassword, looks > like a valid use case to me. > > >>> I was actually planning to use staging to allow kadmin to create > >>> entries, so we need to be careful how ipa-kdb limits access to staging, > >>> I would guess it should pretend KrbKerberosKey is not present for those > >>> entries. > > When someone creates user with plain text userPassword, we normally hash it and > also generate krbPrincipalKey, right? Should we then simply avoid both > operations in the staging area, let the password be stored in plain text and > let the Kerberos keys and attributes be generated during user activation? It > will happen via recreating the entry anyway, so the right operations should be > triggered. No, we do not store plain text passwords. Simo. From ssorce at redhat.com Thu Jun 19 12:43:39 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 08:43:39 -0400 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <53A2C104.8070102@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> Message-ID: <1403181819.12884.80.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 12:52 +0200, Petr Viktorin wrote: > I'll address the other issues separately. > > On 06/18/2014 05:46 PM, Martin Kosek wrote: > > 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: > > No such virtual command" error triggered by "cert-show" command. > > > > We will need to add the permission "System: Read Virtual Operations" that Honza > > is creating also to "Host Administrators" to fix that part. > > I'm not familiar with Honza's effort, but that seems right. > I'm curious, why don't we just allow reading virtual operations by > anybody? It seems to me they're the same in every IPA installation, > what's there to hide? > > Anyway, I poked around in how it works now: for cert-show you need write > access to the objectClass of the "retrieve certificate" virt op entry. > So that right you can actually remove the "ipaVirtualOperation" objectClass. > Aand the new "Anonymous read access to containers" ACI has a > (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for > a virt op can allow everyone see that virt op). > Shouldn't we base the check on some other attribute instead? > > And curiously, for cert-find there is no virt op based access check. I wonder if we can replace some of these with the ipaProtectedOperation machinery, it works better for protecting itself from manipulation. Simo. From tbordaz at redhat.com Thu Jun 19 12:48:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 19 Jun 2014 14:48:05 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403181190.12884.78.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> <53A28C10.10509@redhat.com> <1403181190.12884.78.camel@willson.usersys.redhat.com> Message-ID: <53A2DC05.7020107@redhat.com> On 06/19/2014 02:33 PM, Simo Sorce wrote: > On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: >> On 06/18/2014 06:09 PM, Simo Sorce wrote: >>> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: >>>> On 06/18/2014 04:45 PM, Simo Sorce wrote: >>>>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: >>>>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >>>>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >> ... >>>>> Right, if we allow setting userPassword this would happen, but then if >>>>> we allow setting userPassword do we also generate Kerberos Keys ? >>>> Currently setting of the userPassword (add entry or mod entry) triggers >>>> generation of krb keys (I guess in ipa-kdb). >>> No it happen in ipa-pwd-extop >>> >>>>> If this is the case then we probably need to change the pre-bind plugin >>>>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). >>>> Do you mean to prevent ipa-kdb to generate krb keys when the this is >>>> Delete/Staging >>> No I mean to prevent the ipa-kdb driver (it's the KDC driver) from >>> returning any key even if present for entries in those suffixes. >> IMO we should definitely allow provisioning system to set userPassword, looks >> like a valid use case to me. >> >>>>> I was actually planning to use staging to allow kadmin to create >>>>> entries, so we need to be careful how ipa-kdb limits access to staging, >>>>> I would guess it should pretend KrbKerberosKey is not present for those >>>>> entries. >> When someone creates user with plain text userPassword, we normally hash it and >> also generate krbPrincipalKey, right? Should we then simply avoid both >> operations in the staging area, let the password be stored in plain text and >> let the Kerberos keys and attributes be generated during user activation? It >> will happen via recreating the entry anyway, so the right operations should be >> triggered. > No, we do not store plain text passwords. So the only way to have clear password is during the ADD or MOD (password). For user-add or user-mod, keys are generated and we can authenticate with the account. For stageuser-add or stageuser-mod , we can generate krb keys but do not want to authenticate with it. So it is a change in ipa-kdb to skip Staging. Then when activating an account, userpassword/krb keys are simply copied to the new Active account. thierry > > Simo. > From mkosek at redhat.com Thu Jun 19 12:47:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:47:19 +0200 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <1403181190.12884.78.camel@willson.usersys.redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> <53A28C10.10509@redhat.com> <1403181190.12884.78.camel@willson.usersys.redhat.com> Message-ID: <53A2DBD7.50204@redhat.com> On 06/19/2014 02:33 PM, Simo Sorce wrote: > On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: >> On 06/18/2014 06:09 PM, Simo Sorce wrote: >>> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: >>>> On 06/18/2014 04:45 PM, Simo Sorce wrote: >>>>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: >>>>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: >>>>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: >>>>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: >>>>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: >> ... >>>>> Right, if we allow setting userPassword this would happen, but then if >>>>> we allow setting userPassword do we also generate Kerberos Keys ? >>> >>>> Currently setting of the userPassword (add entry or mod entry) triggers >>>> generation of krb keys (I guess in ipa-kdb). >>> >>> No it happen in ipa-pwd-extop >>> >>>>> If this is the case then we probably need to change the pre-bind plugin >>>>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). >>> >>>> Do you mean to prevent ipa-kdb to generate krb keys when the this is >>>> Delete/Staging >>> >>> No I mean to prevent the ipa-kdb driver (it's the KDC driver) from >>> returning any key even if present for entries in those suffixes. >> >> IMO we should definitely allow provisioning system to set userPassword, looks >> like a valid use case to me. >> >>>>> I was actually planning to use staging to allow kadmin to create >>>>> entries, so we need to be careful how ipa-kdb limits access to staging, >>>>> I would guess it should pretend KrbKerberosKey is not present for those >>>>> entries. >> >> When someone creates user with plain text userPassword, we normally hash it and >> also generate krbPrincipalKey, right? Should we then simply avoid both >> operations in the staging area, let the password be stored in plain text and >> let the Kerberos keys and attributes be generated during user activation? It >> will happen via recreating the entry anyway, so the right operations should be >> triggered. > > No, we do not store plain text passwords. > > Simo. Ok, but then we need to allow generation krbPrincipalKey for staged users, when a new user is filed and userPassword is set. Otherwise you would not be able to generate the krpPrincipalKey during user activation. Martin From mkosek at redhat.com Thu Jun 19 12:49:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:49:20 +0200 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <1403181819.12884.80.camel@willson.usersys.redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> <1403181819.12884.80.camel@willson.usersys.redhat.com> Message-ID: <53A2DC50.5000100@redhat.com> On 06/19/2014 02:43 PM, Simo Sorce wrote: > On Thu, 2014-06-19 at 12:52 +0200, Petr Viktorin wrote: >> I'll address the other issues separately. >> >> On 06/18/2014 05:46 PM, Martin Kosek wrote: >>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: >>> No such virtual command" error triggered by "cert-show" command. >>> >>> We will need to add the permission "System: Read Virtual Operations" that Honza >>> is creating also to "Host Administrators" to fix that part. >> >> I'm not familiar with Honza's effort, but that seems right. >> I'm curious, why don't we just allow reading virtual operations by >> anybody? It seems to me they're the same in every IPA installation, >> what's there to hide? >> >> Anyway, I poked around in how it works now: for cert-show you need write >> access to the objectClass of the "retrieve certificate" virt op entry. >> So that right you can actually remove the "ipaVirtualOperation" objectClass. >> Aand the new "Anonymous read access to containers" ACI has a >> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for >> a virt op can allow everyone see that virt op). >> Shouldn't we base the check on some other attribute instead? >> >> And curiously, for cert-find there is no virt op based access check. > > I wonder if we can replace some of these with the ipaProtectedOperation > machinery, it works better for protecting itself from manipulation. > > Simo. Yup, as I said in other part of this thread, we should invent something better eventually for Virtual Operations. For 4.0, I would just keep previous behavior and dump ipaVirtualOperation objectclass. Martin From ssorce at redhat.com Thu Jun 19 12:52:19 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 08:52:19 -0400 Subject: [Freeipa-devel] User life-cycle: nsAccountLock In-Reply-To: <53A2DBD7.50204@redhat.com> References: <539EE8FF.2060000@redhat.com> <539EEB47.3030901@redhat.com> <53A065FE.7000401@redhat.com> <53A16E4A.10300@redhat.com> <1403098264.12884.46.camel@willson.usersys.redhat.com> <53A1A029.7060303@redhat.com> <1403102755.12884.59.camel@willson.usersys.redhat.com> <53A1B500.1060505@redhat.com> <1403107776.12884.69.camel@willson.usersys.redhat.com> <53A28C10.10509@redhat.com> <1403181190.12884.78.camel@willson.usersys.redhat.com> <53A2DBD7.50204@redhat.com> Message-ID: <1403182339.12884.83.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 14:47 +0200, Martin Kosek wrote: > On 06/19/2014 02:33 PM, Simo Sorce wrote: > > On Thu, 2014-06-19 at 09:06 +0200, Martin Kosek wrote: > >> On 06/18/2014 06:09 PM, Simo Sorce wrote: > >>> On Wed, 2014-06-18 at 17:49 +0200, thierry bordaz wrote: > >>>> On 06/18/2014 04:45 PM, Simo Sorce wrote: > >>>>> On Wed, 2014-06-18 at 16:20 +0200, thierry bordaz wrote: > >>>>>> On 06/18/2014 03:31 PM, Simo Sorce wrote: > >>>>>>> On Wed, 2014-06-18 at 12:47 +0200, Martin Kosek wrote: > >>>>>>>> On 06/17/2014 05:59 PM, thierry bordaz wrote: > >>>>>>>>> On 06/16/2014 03:04 PM, Rob Crittenden wrote: > >> ... > >>>>> Right, if we allow setting userPassword this would happen, but then if > >>>>> we allow setting userPassword do we also generate Kerberos Keys ? > >>> > >>>> Currently setting of the userPassword (add entry or mod entry) triggers > >>>> generation of krb keys (I guess in ipa-kdb). > >>> > >>> No it happen in ipa-pwd-extop > >>> > >>>>> If this is the case then we probably need to change the pre-bind plugin > >>>>> (and ipa-kdb ?) to explicitly exclude staging (and deleted ?). > >>> > >>>> Do you mean to prevent ipa-kdb to generate krb keys when the this is > >>>> Delete/Staging > >>> > >>> No I mean to prevent the ipa-kdb driver (it's the KDC driver) from > >>> returning any key even if present for entries in those suffixes. > >> > >> IMO we should definitely allow provisioning system to set userPassword, looks > >> like a valid use case to me. > >> > >>>>> I was actually planning to use staging to allow kadmin to create > >>>>> entries, so we need to be careful how ipa-kdb limits access to staging, > >>>>> I would guess it should pretend KrbKerberosKey is not present for those > >>>>> entries. > >> > >> When someone creates user with plain text userPassword, we normally hash it and > >> also generate krbPrincipalKey, right? Should we then simply avoid both > >> operations in the staging area, let the password be stored in plain text and > >> let the Kerberos keys and attributes be generated during user activation? It > >> will happen via recreating the entry anyway, so the right operations should be > >> triggered. > > > > No, we do not store plain text passwords. > > > > Simo. > > Ok, but then we need to allow generation krbPrincipalKey for staged users, when > a new user is filed and userPassword is set. Otherwise you would not be able to > generate the krpPrincipalKey during user activation. This is ok, this is actually what happens today if you do it. The only thing we need to do is to change the code to not allow use of keys for staged/deleted entries, which we have to do anyway if we allow to write userPassword. One issue is what to do with expiration times. When you store a password we do create keys and hash it, but we also mark it as expired by default. I guess we want to maintain that ? Simo. From mkosek at redhat.com Thu Jun 19 12:54:22 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:54:22 +0200 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <20140619123145.GH7233@redhat.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> <1394550599.32465.73.camel@willson.li.ssimo.org> <1398975733.2017.1.camel@localhost.localdomain> <20140604154726.GI2726@redhat.com> <1403146219.6477.20.camel@ipa.example.com> <20140619123145.GH7233@redhat.com> Message-ID: <53A2DD7E.40203@redhat.com> On 06/19/2014 02:31 PM, Alexander Bokovoy wrote: > On Wed, 18 Jun 2014, Nathaniel McCallum wrote: >> On Wed, 2014-06-04 at 18:47 +0300, Alexander Bokovoy wrote: >>> On Thu, 01 May 2014, Nathaniel McCallum wrote: >>> >On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: >>> >> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: >>> >> > On Tue, 11 Mar 2014, Jan Pazdziora wrote: >>> >> > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: >>> >> > >> Before this patch, ipa-kdb would load global configuration on startup >>> >> > >> and never update it. This means that if global configuration is >>> changed, >>> >> > >> the KDC never receives the new configuration until it is restarted. >>> >> > >> >>> >> > >> This patch enables caching of the global configuration with a >>> timeout of >>> >> > >> 60 seconds. >>> >> > >> >>> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >>> >> > > >>> >> > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 >>> >> > >> From: Nathaniel McCallum >>> >> > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 >>> >> > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration >>> >> > >> >>> >> > >> Before this patch, ipa-kdb would load global configuration on >>> startup and >>> >> > >> never update it. This means that if global configuration is changed, >>> the >>> >> > >> KDC never receives the new configuration until it is restarted. >>> >> > >> >>> >> > >> This patch enables caching of the global configuration with a >>> timeout of >>> >> > >> 60 seconds. >>> >> > >> >>> >> > >> https://fedorahosted.org/freeipa/ticket/4153 >>> >> > > >>> >> > >I have only read the code and it looks sane, so depending on how much >>> >> > >you consider my word about code-reading worth, ack. >>> >> > > >>> >> > >However, my gut feeling is that my preferred way of handling the issue >>> >> > >(without knowing much about the background of the ticket) would >>> >> > >probably be a HUP signal handler or something similar, rather than >>> >> > >polling for current values with the value timeout. This patch >>> >> > >introduces small nondeterminism to the behaviour when the usage of the >>> >> > >new values cannot really be enfoced by the admin (without the daemon >>> >> > >restart). >>> >> > Thing is, we need the update to happen when other, non-root process >>> >> > makes the changes -- in our case when IPA server running under httpd >>> >> > privileges performs series of MS-RPC calls towards smbd which lead to >>> >> > creating certain LDAP objects. httpd couldn't send SIGHUP to a process >>> >> > not owned by httpd's effective user (non-root). >>> >> >>> >> Yes but this is not really the way to go. >>> >> >>> >> The proper fix is to use syncrepl/persistent search to get a >>> >> notification of when we need to reload the configuration. >>> >> >>> >> On the patch itself I have a NACK due to this syntax used in various >>> >> places: function()->attribute >>> >> >>> >> don't. do. that. ever. >>> >> >>> >> assign whatever come from the function to a local variable and *check* >>> >> it is not null, *then* use it. >>> > >>> >Attached patch fixes the NACK issue, but does not address the question >>> >of the larger approach. Do we need to take a different approach? If so, >>> >what is it? >>> >>> I've tested the patch but was unable to spot any activity to refresh the >>> configuration after I've updated it with >>> ipa config-mod --ipaconfigstring=KDC:Disable\ Lockout >>> >>> At least, dirsrv logs didn't show me any attempt to re-read IPA config >>> past the change. >> >> I spent extensive time testing this today. I am unable to reproduce a >> failure to reload data from LDAP. If I make the change using "ipa >> config-mod", wait a minute and run a kinit the KDC always gets the new >> values. So it works for me. >> >> However, I did uncover a subtle bug with regard to ipaconfigstring which >> would cause it to never to be unset once set. Perhaps you were running >> into this? > Yes, that seems a likely cause. At least, I cannot reproduce it again. > >> >> The new attached version fixes this bug. Everything appears to work... > Thanks, ACK. Pushed to master. Martin From ssorce at redhat.com Thu Jun 19 12:54:51 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 08:54:51 -0400 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <53A2DC50.5000100@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> <1403181819.12884.80.camel@willson.usersys.redhat.com> <53A2DC50.5000100@redhat.com> Message-ID: <1403182491.12884.85.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 14:49 +0200, Martin Kosek wrote: > On 06/19/2014 02:43 PM, Simo Sorce wrote: > > On Thu, 2014-06-19 at 12:52 +0200, Petr Viktorin wrote: > >> I'll address the other issues separately. > >> > >> On 06/18/2014 05:46 PM, Martin Kosek wrote: > >>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: > >>> No such virtual command" error triggered by "cert-show" command. > >>> > >>> We will need to add the permission "System: Read Virtual Operations" that Honza > >>> is creating also to "Host Administrators" to fix that part. > >> > >> I'm not familiar with Honza's effort, but that seems right. > >> I'm curious, why don't we just allow reading virtual operations by > >> anybody? It seems to me they're the same in every IPA installation, > >> what's there to hide? > >> > >> Anyway, I poked around in how it works now: for cert-show you need write > >> access to the objectClass of the "retrieve certificate" virt op entry. > >> So that right you can actually remove the "ipaVirtualOperation" objectClass. > >> Aand the new "Anonymous read access to containers" ACI has a > >> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for > >> a virt op can allow everyone see that virt op). > >> Shouldn't we base the check on some other attribute instead? > >> > >> And curiously, for cert-find there is no virt op based access check. > > > > I wonder if we can replace some of these with the ipaProtectedOperation > > machinery, it works better for protecting itself from manipulation. > > > > Simo. > > Yup, as I said in other part of this thread, we should invent something better Well given we already have something better introduced with the getkeytab patches, maybe we can go ahead and start using them ? > eventually for Virtual Operations. For 4.0, I would just keep previous behavior > and dump ipaVirtualOperation objectclass. Are we concerned that older replicas will not work if we change these to ipaProtectedOperation based ACIs ? (unless their DS is fixed, there were bugs). Simo. From mkosek at redhat.com Thu Jun 19 12:57:58 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 14:57:58 +0200 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <1403182491.12884.85.camel@willson.usersys.redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> <1403181819.12884.80.camel@willson.usersys.redhat.com> <53A2DC50.5000100@redhat.com> <1403182491.12884.85.camel@willson.usersys.redhat.com> Message-ID: <53A2DE56.1000001@redhat.com> On 06/19/2014 02:54 PM, Simo Sorce wrote: > On Thu, 2014-06-19 at 14:49 +0200, Martin Kosek wrote: >> On 06/19/2014 02:43 PM, Simo Sorce wrote: >>> On Thu, 2014-06-19 at 12:52 +0200, Petr Viktorin wrote: >>>> I'll address the other issues separately. >>>> >>>> On 06/18/2014 05:46 PM, Martin Kosek wrote: >>>>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: >>>>> No such virtual command" error triggered by "cert-show" command. >>>>> >>>>> We will need to add the permission "System: Read Virtual Operations" that Honza >>>>> is creating also to "Host Administrators" to fix that part. >>>> >>>> I'm not familiar with Honza's effort, but that seems right. >>>> I'm curious, why don't we just allow reading virtual operations by >>>> anybody? It seems to me they're the same in every IPA installation, >>>> what's there to hide? >>>> >>>> Anyway, I poked around in how it works now: for cert-show you need write >>>> access to the objectClass of the "retrieve certificate" virt op entry. >>>> So that right you can actually remove the "ipaVirtualOperation" objectClass. >>>> Aand the new "Anonymous read access to containers" ACI has a >>>> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for >>>> a virt op can allow everyone see that virt op). >>>> Shouldn't we base the check on some other attribute instead? >>>> >>>> And curiously, for cert-find there is no virt op based access check. >>> >>> I wonder if we can replace some of these with the ipaProtectedOperation >>> machinery, it works better for protecting itself from manipulation. >>> >>> Simo. >> >> Yup, as I said in other part of this thread, we should invent something better > > Well given we already have something better introduced with the > getkeytab patches, maybe we can go ahead and start using them ? Well yeah, I have the same opinion as you do, we should consider using ipaProtectedOperation for Virtual Operations. I just said we may not be able to do it directly in 4.0. >> eventually for Virtual Operations. For 4.0, I would just keep previous behavior >> and dump ipaVirtualOperation objectclass. > > Are we concerned that older replicas will not work if we change these to > ipaProtectedOperation based ACIs ? (unless their DS is fixed, there were > bugs). I am concerned. One more reason to wait a bit and keep the old Virtual Operation behavior in 4.0 :-) Martin From pvoborni at redhat.com Thu Jun 19 13:16:51 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 19 Jun 2014 15:16:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1403091728.20101.5.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> <1403091728.20101.5.camel@unused-4-145.brq.redhat.com> Message-ID: <53A2E2C3.1010703@redhat.com> On 18.6.2014 13:42, Martin Basti wrote: > Rebased patches with pep8 fixes attached git diff HEAD~4 -U0 | pep8 --diff --ignore=E501,E126,E128,E124 ./ipalib/plugins/dns.py:1754:9: E265 block comment should start with '# ' ./ipalib/plugins/dns.py:1755:9: E265 block comment should start with '# ' ./ipalib/plugins/dns.py:2550:13: E265 block comment should start with '# ' ./ipalib/plugins/dns.py:2551:16: E713 test for membership should be 'not in' ./ipalib/plugins/dns.py:3516:9: E265 block comment should start with '# ' ./ipalib/plugins/dns.py:3686:12: E713 test for membership should be 'not in' I don't like how the patches are structured. It's hard to review. IMHO you should have started with creation of the base class and then build the forward zone on top of it. Reading a bunch of copy-pasted code with minor changes which is then removed in the next patch is a waste of time. Current approach is acceptable if the patch set is huge and rebases would be really difficult. Or if it's sent and reviewed separately. But what's done is done. 1. Is it possible to disable the interactive wizard for dnsrecord-add forward.zone.? It would be nice to show the error right at the beginning. Patch 54-5: 2. You forgot to remove the 'execute' method from 'dnszone_disable' and 'dnszone_enable' 3. 'pre_callback' in 'dnsforwardzone_find' seems to be redundant, it just calls the parent's pre_callback with no additional logic General question: Looking at the help text, especially the `--name=DNSNAMEPARAM`, I wonder if have somewhere documented the formats of various param types. -- Petr Vobornik From simo at redhat.com Thu Jun 19 13:28:12 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 09:28:12 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2948A.7000308@redhat.com> References: <53A2948A.7000308@redhat.com> Message-ID: <1403184492.12884.86.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: > Hello list, > > the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > question "Why do we use Kerberos for named<->DS connection? Named connects > over LDAPI to local DS instance anyway." > > Maybe we can get rid of Kerberos for this particular connection and use > autobind instead. It would make it more reliable and effective. > > As a side effect, named will be able to start even if KDC is down for some > reason. It partially solves chicken-egg problem during IPA start-up. > > I wasn't around when it bind-dyndb-ldap was designed so I don't know > historical reasons. > > [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html I would be in favor if we can make bind run as an unprivileged user instead of root, can we do that ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbordaz at redhat.com Thu Jun 19 13:32:33 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 19 Jun 2014 15:32:33 +0200 Subject: [Freeipa-devel] User life cycle: authentication and preserved attributes Message-ID: <53A2E671.6060108@redhat.com> Hello, Thanks for all you feedbacks and help about which attributes to preserved and how to limit authentication (simple and krb) to Active accounts, here are my understandings: 1. Staging (container: cn=staged users,cn=accounts,cn=provisioning,SUFFIX) plugins scoping Staging: * ipa_pwd_extop (kerberos keys generated) In order to prevent simple bind, there is pre-bind plugin or cos (nsAccoutLock: True). * provisioning constraints - no constraint when creating an entry but to be activated the entries in that container must have: o 'uid' RDN o have OC: posixaccount, ipaObject (MUST: cn, uid, uidNumber, gidNumber, homedirectory, ipaUniqueID) * ipa stageuser-add It creates a stage entry with uidNumber: -1 gidNumber: -1 ipaUniqueID: autogenerate description: __no_upg__ manager: checks that the DN is an active user userPassword/krb keys: if userPassword is set, krb keys are generated * ipa stageuser-add --from-delete It possibly updates (MOD-delete) the deleted entry to delete the attributes: o userPassword o krb keys Then it moves (modrdn) the deleted entry to staging container where uidNumber: gidNumber: ipaUniqueID: description: __no_upg__ (to show there is not managed group) (Deleted entries have no userPassword nor krb keys) * ipa stageuser-activate To be activated an entry must have: o 'uid' RDN o have OC: posixaccount, ipaObject (MUST: cn, uid, uidNumber, gidNumber, homedirectory, ipaUniqueID) It adds in the active container, a destination copy of a stage entry where uidNumber: (if it was '-1' DNA generates it) gidNumber: (if it was '-1' DNA generates it) ipaUniqueID: (if it was 'autogenerate' ipa uuid generates it) description: value __no_upg__ is removed DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) userPassword/krb keys: copied from source entry if they exists Then removes the source entry from the 'Staging' container. * ipa stageuser-find * ipa stageuser-show * ipa stageuser-mod DN syntax attributes: checks that the DN is an active user * ipa stageuser-del 1. Active (container: cn=users,cn=accounts,SUFFIX) plugins scoping Staging: * ipa_pwd_extop (kerberos keys generated) * attribute uniqueness (ipaUniqueID, uid, krbprincipalname, krbcanonicalName) * referential integrity * memberof * managed entries * ipa uuid In order to allow simple bind, there is pre-bind plugin or cos (nsAccoutLock: False). A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries, and DNA plugins) * ipa user-add * ipa user-mod DN syntax attributes: checks that the DN is an active user * ipa user-show * ipa user-find * ipa user-delete The entry is moved (modrdn) to Delete container: o all memberships attributes updated by plugins (managed entries/memberof) o group members updated by referential integrity then updated (mod) o all DN syntax attributes are wiped except: manager, managedby, secretary o description: add __no_upg__ value o userPassword is deleted o kerberos keys are deleted * ipa user-undelete The entry is possibly updated (MOD-delete) to delete attributes o userPassword (no simple bind on undeleted entry, requires to create a password) o kerberos keys (no kerberos bind on undeleted entry, requires to recreate user password) Then is moved (modrdn) to Active container 1. Delete (container is cn=deleted users,cn=accounts,SUFFIX) plugins scoping Delete: * ipa_pwd_extop (not required as Delete account should not have userPassword nor krb keys) * attribute uniqueness (ipaUniqueID, uid, krbprincipalname, krbcanonicalName) In order to prevent simple bind (in addition to userPassword being cleared), there is pre-bind plugin or cos (nsAccoutLock: True). Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Jun 19 13:36:47 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 09:36:47 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619111348.GE7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> Message-ID: <1403185007.12884.87.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Petr Spacek wrote: > >On 19.6.2014 11:02, Alexander Bokovoy wrote: > >>On Thu, 19 Jun 2014, Petr Spacek wrote: > >>>the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > >>>question "Why do we use Kerberos for named<->DS connection? Named connects > >>>over LDAPI to local DS instance anyway." > >>> > >>>Maybe we can get rid of Kerberos for this particular connection and use > >>>autobind instead. It would make it more reliable and effective. > >>> > >>>As a side effect, named will be able to start even if KDC is down for some > >>>reason. It partially solves chicken-egg problem during IPA start-up. > >>> > >>>I wasn't around when it bind-dyndb-ldap was designed so I don't know > >>>historical reasons. > >>My primary worry is the fact that any break in named/bind-dyndb-ldap > >>could be then exploited to have access to all key material. In the case of > >>GSSAPI you are confined to whatever ACIs allow for dns/ principal. > >IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so > >I don't see any difference from using SASL/GSSAPI/Kerberos. > My impression was that you wanted autobind to Directory Manager (root > autobind), this is what I don't want to support, for sure. > > >>Samba case goes further -- I specifically added GSSAPI bind to Samba > >>code LDAP code to allow splitting DCs and file servers while being able > >>to use the same ipasam module securely, in addition to the usual > >>ACI limitations. > >Named has only one function (i.e. DNS server with support for DNS > >updates). I don't think that there is meaningful separation. > > > >>For named what we could do is to have named+ldapi:// access mapped to > >>specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth > >This is OpenLDAP-ism, right? > yes, this is what the client code reports. 389-ds server sees proper dn: > > # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ > --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ > --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ > --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ > --setattr=uid=named > ----------------------------------------------- > Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" > ----------------------------------------------- > Principal: DNS/ipa-01.t.vda.li at T.VDA.LI > Managed by: ipa-01.t.vda.li > > # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' > SASL/EXTERNAL authentication started > SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: cn=config > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > and here is what we see in the logs: > [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL > [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL > [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 > [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > > > > > >> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX > >This object already exists for every single DNS server, which is > >exactly the problem. Multiple servers are running under the same > >UID/GID pair on Fedora. > No, it is not a problem because there are multiple objects, one per > server. > > >>There is an issue of uid/gid being different on different platforms, > >>though but it is doable. > >I can see the problem with UID/GID mapping to multiple different > >principals. We can't remove these principals because they are used on > >server side for DNS updates. > > > >Maybe we can create autobind mapping objects in some non-replicated > >part of the tree. That would solve the problem with different UID/GIDs > >on different platforms and also mapping UID/GID mapping to multiple > >principals because one replica would see only one mapping object for > >given UID/GID. > No, I don't think we ever need to modify anything here apart from giving > posixgroup/posixaccount object classes to the DNS principal per server > and setting their properties. > > As you can see above, it simply works. I actually tested it with named > too, by setting > > diff -up /etc/named.conf.old /etc/named.conf > --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 > +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 > @@ -45,7 +45,7 @@ dynamic-db "ipa" { > arg "base cn=dns, dc=t,dc=vda,dc=li"; > arg "fake_mname ipa-01.t.vda.li."; > arg "auth_method sasl"; > - arg "sasl_mech GSSAPI"; > - arg "sasl_user DNS/ipa-01.t.vda.li"; > + arg "sasl_mech EXTERNAL"; > + arg "sasl_user named"; > arg "serial_autoincrement yes"; > }; > > and named successfully started, with 389-ds showing autobind to the same > krprincipalname=dns/... in the logs. why do we need to associate bind to dns/whatever ?? we can have a sysaccount called named, like we did for kerberos before we had the ipa-kdb driver. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Jun 19 13:40:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 15:40:10 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403184492.12884.86.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <1403184492.12884.86.camel@willson.usersys.redhat.com> Message-ID: <53A2E83A.7040108@redhat.com> On 19.6.2014 15:28, Simo Sorce wrote: > On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: >> Hello list, >> >> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >> question "Why do we use Kerberos for named<->DS connection? Named connects >> over LDAPI to local DS instance anyway." >> >> Maybe we can get rid of Kerberos for this particular connection and use >> autobind instead. It would make it more reliable and effective. >> >> As a side effect, named will be able to start even if KDC is down for some >> reason. It partially solves chicken-egg problem during IPA start-up. >> >> I wasn't around when it bind-dyndb-ldap was designed so I don't know >> historical reasons. >> >> [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html > > I would be in favor if we can make bind run as an unprivileged user > instead of root, can we do that ? We already do that :-) The user is called 'named'. -- Petr^2 Spacek From abokovoy at redhat.com Thu Jun 19 13:41:28 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 16:41:28 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403185007.12884.87.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> Message-ID: <20140619134128.GL7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Petr Spacek wrote: >> >On 19.6.2014 11:02, Alexander Bokovoy wrote: >> >>On Thu, 19 Jun 2014, Petr Spacek wrote: >> >>>the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >> >>>question "Why do we use Kerberos for named<->DS connection? Named connects >> >>>over LDAPI to local DS instance anyway." >> >>> >> >>>Maybe we can get rid of Kerberos for this particular connection and use >> >>>autobind instead. It would make it more reliable and effective. >> >>> >> >>>As a side effect, named will be able to start even if KDC is down for some >> >>>reason. It partially solves chicken-egg problem during IPA start-up. >> >>> >> >>>I wasn't around when it bind-dyndb-ldap was designed so I don't know >> >>>historical reasons. >> >>My primary worry is the fact that any break in named/bind-dyndb-ldap >> >>could be then exploited to have access to all key material. In the case of >> >>GSSAPI you are confined to whatever ACIs allow for dns/ principal. >> >IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so >> >I don't see any difference from using SASL/GSSAPI/Kerberos. >> My impression was that you wanted autobind to Directory Manager (root >> autobind), this is what I don't want to support, for sure. >> >> >>Samba case goes further -- I specifically added GSSAPI bind to Samba >> >>code LDAP code to allow splitting DCs and file servers while being able >> >>to use the same ipasam module securely, in addition to the usual >> >>ACI limitations. >> >Named has only one function (i.e. DNS server with support for DNS >> >updates). I don't think that there is meaningful separation. >> > >> >>For named what we could do is to have named+ldapi:// access mapped to >> >>specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >> >This is OpenLDAP-ism, right? >> yes, this is what the client code reports. 389-ds server sees proper dn: >> >> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ >> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ >> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ >> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ >> --setattr=uid=named >> ----------------------------------------------- >> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" >> ----------------------------------------------- >> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI >> Managed by: ipa-01.t.vda.li >> >> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: cn=config >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> and here is what we see in the logs: >> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 >> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND >> >> >> > >> >> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >> >This object already exists for every single DNS server, which is >> >exactly the problem. Multiple servers are running under the same >> >UID/GID pair on Fedora. >> No, it is not a problem because there are multiple objects, one per >> server. >> >> >>There is an issue of uid/gid being different on different platforms, >> >>though but it is doable. >> >I can see the problem with UID/GID mapping to multiple different >> >principals. We can't remove these principals because they are used on >> >server side for DNS updates. >> > >> >Maybe we can create autobind mapping objects in some non-replicated >> >part of the tree. That would solve the problem with different UID/GIDs >> >on different platforms and also mapping UID/GID mapping to multiple >> >principals because one replica would see only one mapping object for >> >given UID/GID. >> No, I don't think we ever need to modify anything here apart from giving >> posixgroup/posixaccount object classes to the DNS principal per server >> and setting their properties. >> >> As you can see above, it simply works. I actually tested it with named >> too, by setting >> >> diff -up /etc/named.conf.old /etc/named.conf >> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 >> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 >> @@ -45,7 +45,7 @@ dynamic-db "ipa" { >> arg "base cn=dns, dc=t,dc=vda,dc=li"; >> arg "fake_mname ipa-01.t.vda.li."; >> arg "auth_method sasl"; >> - arg "sasl_mech GSSAPI"; >> - arg "sasl_user DNS/ipa-01.t.vda.li"; >> + arg "sasl_mech EXTERNAL"; >> + arg "sasl_user named"; >> arg "serial_autoincrement yes"; >> }; >> >> and named successfully started, with 389-ds showing autobind to the same >> krprincipalname=dns/... in the logs. > >why do we need to associate bind to dns/whatever ?? Because we already have ACIs given to dns/hostname to handle DNS entries. > >we can have a sysaccount called named, like we did for kerberos before >we had the ipa-kdb driver. A modification of DNS service with 'ipa service-mod' is all what we need for single node case, I tried it. -- / Alexander Bokovoy From ssorce at redhat.com Thu Jun 19 13:41:48 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 09:41:48 -0400 Subject: [Freeipa-devel] User life cycle: authentication and preserved attributes In-Reply-To: <53A2E671.6060108@redhat.com> References: <53A2E671.6060108@redhat.com> Message-ID: <1403185308.12884.89.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 15:32 +0200, thierry bordaz wrote: > (those values must be active DN entries) > userPassword/krb keys: copied from source entry if > they > exists Uhmm this may actually fail, as we prevent storing pre-hashed passwords :/ We'll have to somehow detect that krbprincipalkeys are also being added at the same time and allow pre-hashed password in that case, I guess. Also I realized one thing for deleted users, should we preserve password History (should we put the last used password there) ? Simo. From pspacek at redhat.com Thu Jun 19 13:41:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 15:41:51 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403185007.12884.87.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> Message-ID: <53A2E89F.90904@redhat.com> On 19.6.2014 15:36, Simo Sorce wrote: > On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Petr Spacek wrote: >>> On 19.6.2014 11:02, Alexander Bokovoy wrote: >>>> On Thu, 19 Jun 2014, Petr Spacek wrote: >>>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >>>>> question "Why do we use Kerberos for named<->DS connection? Named connects >>>>> over LDAPI to local DS instance anyway." >>>>> >>>>> Maybe we can get rid of Kerberos for this particular connection and use >>>>> autobind instead. It would make it more reliable and effective. >>>>> >>>>> As a side effect, named will be able to start even if KDC is down for some >>>>> reason. It partially solves chicken-egg problem during IPA start-up. >>>>> >>>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know >>>>> historical reasons. >>>> My primary worry is the fact that any break in named/bind-dyndb-ldap >>>> could be then exploited to have access to all key material. In the case of >>>> GSSAPI you are confined to whatever ACIs allow for dns/ principal. >>> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so >>> I don't see any difference from using SASL/GSSAPI/Kerberos. >> My impression was that you wanted autobind to Directory Manager (root >> autobind), this is what I don't want to support, for sure. >> >>>> Samba case goes further -- I specifically added GSSAPI bind to Samba >>>> code LDAP code to allow splitting DCs and file servers while being able >>>> to use the same ipasam module securely, in addition to the usual >>>> ACI limitations. >>> Named has only one function (i.e. DNS server with support for DNS >>> updates). I don't think that there is meaningful separation. >>> >>>> For named what we could do is to have named+ldapi:// access mapped to >>>> specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >>> This is OpenLDAP-ism, right? >> yes, this is what the client code reports. 389-ds server sees proper dn: >> >> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ >> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ >> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ >> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ >> --setattr=uid=named >> ----------------------------------------------- >> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" >> ----------------------------------------------- >> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI >> Managed by: ipa-01.t.vda.li >> >> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: cn=config >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> and here is what we see in the logs: >> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 >> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND >> >> >>> >>>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >>> This object already exists for every single DNS server, which is >>> exactly the problem. Multiple servers are running under the same >>> UID/GID pair on Fedora. >> No, it is not a problem because there are multiple objects, one per >> server. >> >>>> There is an issue of uid/gid being different on different platforms, >>>> though but it is doable. >>> I can see the problem with UID/GID mapping to multiple different >>> principals. We can't remove these principals because they are used on >>> server side for DNS updates. >>> >>> Maybe we can create autobind mapping objects in some non-replicated >>> part of the tree. That would solve the problem with different UID/GIDs >>> on different platforms and also mapping UID/GID mapping to multiple >>> principals because one replica would see only one mapping object for >>> given UID/GID. >> No, I don't think we ever need to modify anything here apart from giving >> posixgroup/posixaccount object classes to the DNS principal per server >> and setting their properties. >> >> As you can see above, it simply works. I actually tested it with named >> too, by setting >> >> diff -up /etc/named.conf.old /etc/named.conf >> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 >> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 >> @@ -45,7 +45,7 @@ dynamic-db "ipa" { >> arg "base cn=dns, dc=t,dc=vda,dc=li"; >> arg "fake_mname ipa-01.t.vda.li."; >> arg "auth_method sasl"; >> - arg "sasl_mech GSSAPI"; >> - arg "sasl_user DNS/ipa-01.t.vda.li"; >> + arg "sasl_mech EXTERNAL"; >> + arg "sasl_user named"; >> arg "serial_autoincrement yes"; >> }; >> >> and named successfully started, with 389-ds showing autobind to the same >> krprincipalname=dns/... in the logs. > > why do we need to associate bind to dns/whatever ?? As I said earlier in the thread, we need DNS/ principal for DNS updates with GSS-TSIG. > we can have a sysaccount called named, like we did for kerberos before > we had the ipa-kdb driver. I would prefer to have only one account for named daemon... -- Petr^2 Spacek From abokovoy at redhat.com Thu Jun 19 13:42:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 16:42:32 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403184492.12884.86.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <1403184492.12884.86.camel@willson.usersys.redhat.com> Message-ID: <20140619134232.GM7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-19 at 09:43 +0200, Petr Spacek wrote: >> Hello list, >> >> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >> question "Why do we use Kerberos for named<->DS connection? Named connects >> over LDAPI to local DS instance anyway." >> >> Maybe we can get rid of Kerberos for this particular connection and use >> autobind instead. It would make it more reliable and effective. >> >> As a side effect, named will be able to start even if KDC is down for some >> reason. It partially solves chicken-egg problem during IPA start-up. >> >> I wasn't around when it bind-dyndb-ldap was designed so I don't know >> historical reasons. >> >> [1] https://www.redhat.com/archives/freeipa-users/2014-June/msg00065.html > >I would be in favor if we can make bind run as an unprivileged user >instead of root, can we do that ? It already runs as 'named' user, see my other mail with actual experiment results. -- / Alexander Bokovoy From tbabej at redhat.com Thu Jun 19 13:52:36 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Jun 2014 15:52:36 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A2C10A.2080406@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> Message-ID: <53A2EB24.8030404@redhat.com> On 06/19/2014 12:52 PM, Tomas Babej wrote: > On 06/18/2014 10:52 AM, Petr Viktorin wrote: >> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>> On 17.06.2014 11:16, Martin Kosek wrote: >>> Attached is a new version of patch 226, and a new patch 228, which moves >>> the paths from installers to the paths module. >> In patch 226, there's another "certificated" typo in >> remove_ca_cert_from_systemwide_ca_store >> >>> I greped the repository, and I do not see many paths lurking around any >>> more, there are only some in the error messages (as these can't be >>> reliably replaced automatically, and will need some manual love). >>> >>> If you see any forgotten paths, which should be added to the module, let >>> me know. >> >> I see another duplicate: >> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >> "/var/lib/sss/pubconf/krb5.include.d/" >> >> >> Rather than using e.g. >> filename = paths.VAR_KERBEROS_KRB5KDC_DIR + file >> It would be cleaner to use >> filename = os.path.join(paths.VAR_KERBEROS_KRB5KDC_DIR, file) >> >> > Fixed all mentioned issues. I also attached a patch 230, which removes > the base Authconfig class. > Attaching one additional patch, which removes unnecessary build warnings. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0231-ipaplatform-Fix-build-warnings.patch Type: text/x-patch Size: 1120 bytes Desc: not available URL: From pviktori at redhat.com Thu Jun 19 13:59:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Jun 2014 15:59:45 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2D538.2050704@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> Message-ID: <53A2ECD1.9080906@redhat.com> On 06/19/2014 02:19 PM, Martin Kosek wrote: > On 06/19/2014 01:39 PM, Petr Viktorin wrote: >> See commit message. >> >> This was found in the review of host write permissions (my patches 0578-0579). > > Wouldn't it be better to filter based on objectclass? I.e.: > > (targetfilter="(!(objectclass=ipaConfigObject))" > > instead of DN based target filter? It seems to me that it is more resilient to > changes in LDAP structure, in case we change RDN or make one more level like > (just example): > > cn=DNSSEC,cn=DNS,cn=ipa.master.test,... Sure, fixed patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0590.3-Allow-read-access-to-masters-but-not-their-services-.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 19 14:00:21 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jun 2014 10:00:21 -0400 Subject: [Freeipa-devel] Virtual operation ACIs (Was Re: 0578-0579 Convert Host default permissions to managed) In-Reply-To: <53A2C104.8070102@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> Message-ID: <53A2ECF5.9080004@redhat.com> Petr Viktorin wrote: > I'll address the other issues separately. > > On 06/18/2014 05:46 PM, Martin Kosek wrote: >> 3) I hit one issue when I open the Web UI host tab, I get >> "Insufficient access: >> No such virtual command" error triggered by "cert-show" command. >> >> We will need to add the permission "System: Read Virtual Operations" >> that Honza >> is creating also to "Host Administrators" to fix that part. > > I'm not familiar with Honza's effort, but that seems right. > I'm curious, why don't we just allow reading virtual operations by > anybody? It seems to me they're the same in every IPA installation, > what's there to hide? > > Anyway, I poked around in how it works now: for cert-show you need write > access to the objectClass of the "retrieve certificate" virt op entry. > So that right you can actually remove the "ipaVirtualOperation" > objectClass. > Aand the new "Anonymous read access to containers" ACI has a > (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for > a virt op can allow everyone see that virt op). > Shouldn't we base the check on some other attribute instead? Jumping back in the thread a bit, I agree with Martin's and Simo's sentiment that a new model is needed. Backwards compatibility is going to be a challenge. Ideally I'd have done this using a read aci but the global read anything aci prevented this, so I went with write, accepting the less-than-perfect solution. The expectation was that not too much damage could be done just allowing write to objectclass and it would be fairly obvious if someone did it. > > And curiously, for cert-find there is no virt op based access check. This is because it is executed against the public dogtag API. Given the new read-based aci system is probably prudent to add one, defaulting to letting everyone read it (for compatibility). rob From simo at redhat.com Thu Jun 19 14:02:20 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:02:20 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619134128.GL7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> Message-ID: <1403186540.12884.92.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: > >On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: > >> On Thu, 19 Jun 2014, Petr Spacek wrote: > >> >On 19.6.2014 11:02, Alexander Bokovoy wrote: > >> >>On Thu, 19 Jun 2014, Petr Spacek wrote: > >> >>>the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > >> >>>question "Why do we use Kerberos for named<->DS connection? Named connects > >> >>>over LDAPI to local DS instance anyway." > >> >>> > >> >>>Maybe we can get rid of Kerberos for this particular connection and use > >> >>>autobind instead. It would make it more reliable and effective. > >> >>> > >> >>>As a side effect, named will be able to start even if KDC is down for some > >> >>>reason. It partially solves chicken-egg problem during IPA start-up. > >> >>> > >> >>>I wasn't around when it bind-dyndb-ldap was designed so I don't know > >> >>>historical reasons. > >> >>My primary worry is the fact that any break in named/bind-dyndb-ldap > >> >>could be then exploited to have access to all key material. In the case of > >> >>GSSAPI you are confined to whatever ACIs allow for dns/ principal. > >> >IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so > >> >I don't see any difference from using SASL/GSSAPI/Kerberos. > >> My impression was that you wanted autobind to Directory Manager (root > >> autobind), this is what I don't want to support, for sure. > >> > >> >>Samba case goes further -- I specifically added GSSAPI bind to Samba > >> >>code LDAP code to allow splitting DCs and file servers while being able > >> >>to use the same ipasam module securely, in addition to the usual > >> >>ACI limitations. > >> >Named has only one function (i.e. DNS server with support for DNS > >> >updates). I don't think that there is meaningful separation. > >> > > >> >>For named what we could do is to have named+ldapi:// access mapped to > >> >>specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth > >> >This is OpenLDAP-ism, right? > >> yes, this is what the client code reports. 389-ds server sees proper dn: > >> > >> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ > >> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ > >> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ > >> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ > >> --setattr=uid=named > >> ----------------------------------------------- > >> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" > >> ----------------------------------------------- > >> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI > >> Managed by: ipa-01.t.vda.li > >> > >> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' > >> SASL/EXTERNAL authentication started > >> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth > >> SASL SSF: 0 > >> # extended LDIF > >> # > >> # LDAPv3 > >> # base (default) with scope subtree > >> # filter: cn=config > >> # requesting: ALL > >> # > >> > >> # search result > >> search: 2 > >> result: 0 Success > >> > >> # numResponses: 1 > >> > >> and here is what we see in the logs: > >> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > >> > >> > >> > > >> >> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX > >> >This object already exists for every single DNS server, which is > >> >exactly the problem. Multiple servers are running under the same > >> >UID/GID pair on Fedora. > >> No, it is not a problem because there are multiple objects, one per > >> server. > >> > >> >>There is an issue of uid/gid being different on different platforms, > >> >>though but it is doable. > >> >I can see the problem with UID/GID mapping to multiple different > >> >principals. We can't remove these principals because they are used on > >> >server side for DNS updates. > >> > > >> >Maybe we can create autobind mapping objects in some non-replicated > >> >part of the tree. That would solve the problem with different UID/GIDs > >> >on different platforms and also mapping UID/GID mapping to multiple > >> >principals because one replica would see only one mapping object for > >> >given UID/GID. > >> No, I don't think we ever need to modify anything here apart from giving > >> posixgroup/posixaccount object classes to the DNS principal per server > >> and setting their properties. > >> > >> As you can see above, it simply works. I actually tested it with named > >> too, by setting > >> > >> diff -up /etc/named.conf.old /etc/named.conf > >> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 > >> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 > >> @@ -45,7 +45,7 @@ dynamic-db "ipa" { > >> arg "base cn=dns, dc=t,dc=vda,dc=li"; > >> arg "fake_mname ipa-01.t.vda.li."; > >> arg "auth_method sasl"; > >> - arg "sasl_mech GSSAPI"; > >> - arg "sasl_user DNS/ipa-01.t.vda.li"; > >> + arg "sasl_mech EXTERNAL"; > >> + arg "sasl_user named"; > >> arg "serial_autoincrement yes"; > >> }; > >> > >> and named successfully started, with 389-ds showing autobind to the same > >> krprincipalname=dns/... in the logs. > > > >why do we need to associate bind to dns/whatever ?? > Because we already have ACIs given to dns/hostname to handle DNS > entries. Which are easy to change on upgrade. > >we can have a sysaccount called named, like we did for kerberos before > >we had the ipa-kdb driver. > A modification of DNS service with 'ipa service-mod' is all what we > need for single node case, I tried it. I do not like it at all, plus each server has a different object and they would all be duplicates. I prefer very much a single, passwordless special user in sysconfig, added to the same group that control access for the DNS tree. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 19 14:03:33 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jun 2014 10:03:33 -0400 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2ECD1.9080906@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> <53A2ECD1.9080906@redhat.com> Message-ID: <53A2EDB5.1050803@redhat.com> Petr Viktorin wrote: > On 06/19/2014 02:19 PM, Martin Kosek wrote: >> On 06/19/2014 01:39 PM, Petr Viktorin wrote: >>> See commit message. >>> >>> This was found in the review of host write permissions (my patches >>> 0578-0579). >> >> Wouldn't it be better to filter based on objectclass? I.e.: >> >> (targetfilter="(!(objectclass=ipaConfigObject))" >> >> instead of DN based target filter? It seems to me that it is more >> resilient to >> changes in LDAP structure, in case we change RDN or make one more >> level like >> (just example): >> >> cn=DNSSEC,cn=DNS,cn=ipa.master.test,... > > Sure, fixed patch attached. Are you sure you need read access and not just search/compare? The purpose is to see "is that thing there" and not "what is in that thing" right? Sure someone could fish for masters if they really wanted to. rob From simo at redhat.com Thu Jun 19 14:04:15 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:04:15 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2E89F.90904@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <53A2E89F.90904@redhat.com> Message-ID: <1403186655.12884.94.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 15:41 +0200, Petr Spacek wrote: > On 19.6.2014 15:36, Simo Sorce wrote: > > On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: > >> On Thu, 19 Jun 2014, Petr Spacek wrote: > >>> On 19.6.2014 11:02, Alexander Bokovoy wrote: > >>>> On Thu, 19 Jun 2014, Petr Spacek wrote: > >>>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > >>>>> question "Why do we use Kerberos for named<->DS connection? Named connects > >>>>> over LDAPI to local DS instance anyway." > >>>>> > >>>>> Maybe we can get rid of Kerberos for this particular connection and use > >>>>> autobind instead. It would make it more reliable and effective. > >>>>> > >>>>> As a side effect, named will be able to start even if KDC is down for some > >>>>> reason. It partially solves chicken-egg problem during IPA start-up. > >>>>> > >>>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know > >>>>> historical reasons. > >>>> My primary worry is the fact that any break in named/bind-dyndb-ldap > >>>> could be then exploited to have access to all key material. In the case of > >>>> GSSAPI you are confined to whatever ACIs allow for dns/ principal. > >>> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so > >>> I don't see any difference from using SASL/GSSAPI/Kerberos. > >> My impression was that you wanted autobind to Directory Manager (root > >> autobind), this is what I don't want to support, for sure. > >> > >>>> Samba case goes further -- I specifically added GSSAPI bind to Samba > >>>> code LDAP code to allow splitting DCs and file servers while being able > >>>> to use the same ipasam module securely, in addition to the usual > >>>> ACI limitations. > >>> Named has only one function (i.e. DNS server with support for DNS > >>> updates). I don't think that there is meaningful separation. > >>> > >>>> For named what we could do is to have named+ldapi:// access mapped to > >>>> specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth > >>> This is OpenLDAP-ism, right? > >> yes, this is what the client code reports. 389-ds server sees proper dn: > >> > >> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ > >> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ > >> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ > >> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ > >> --setattr=uid=named > >> ----------------------------------------------- > >> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" > >> ----------------------------------------------- > >> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI > >> Managed by: ipa-01.t.vda.li > >> > >> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' > >> SASL/EXTERNAL authentication started > >> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth > >> SASL SSF: 0 > >> # extended LDIF > >> # > >> # LDAPv3 > >> # base (default) with scope subtree > >> # filter: cn=config > >> # requesting: ALL > >> # > >> > >> # search result > >> search: 2 > >> result: 0 Success > >> > >> # numResponses: 1 > >> > >> and here is what we see in the logs: > >> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 > >> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > >> > >> > >>> > >>>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX > >>> This object already exists for every single DNS server, which is > >>> exactly the problem. Multiple servers are running under the same > >>> UID/GID pair on Fedora. > >> No, it is not a problem because there are multiple objects, one per > >> server. > >> > >>>> There is an issue of uid/gid being different on different platforms, > >>>> though but it is doable. > >>> I can see the problem with UID/GID mapping to multiple different > >>> principals. We can't remove these principals because they are used on > >>> server side for DNS updates. > >>> > >>> Maybe we can create autobind mapping objects in some non-replicated > >>> part of the tree. That would solve the problem with different UID/GIDs > >>> on different platforms and also mapping UID/GID mapping to multiple > >>> principals because one replica would see only one mapping object for > >>> given UID/GID. > >> No, I don't think we ever need to modify anything here apart from giving > >> posixgroup/posixaccount object classes to the DNS principal per server > >> and setting their properties. > >> > >> As you can see above, it simply works. I actually tested it with named > >> too, by setting > >> > >> diff -up /etc/named.conf.old /etc/named.conf > >> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 > >> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 > >> @@ -45,7 +45,7 @@ dynamic-db "ipa" { > >> arg "base cn=dns, dc=t,dc=vda,dc=li"; > >> arg "fake_mname ipa-01.t.vda.li."; > >> arg "auth_method sasl"; > >> - arg "sasl_mech GSSAPI"; > >> - arg "sasl_user DNS/ipa-01.t.vda.li"; > >> + arg "sasl_mech EXTERNAL"; > >> + arg "sasl_user named"; > >> arg "serial_autoincrement yes"; > >> }; > >> > >> and named successfully started, with 389-ds showing autobind to the same > >> krprincipalname=dns/... in the logs. > > > > why do we need to associate bind to dns/whatever ?? > As I said earlier in the thread, we need DNS/ principal for DNS > updates with GSS-TSIG. I know this, I am not proposing to remove the keytab, but that's a different thing. > > we can have a sysaccount called named, like we did for kerberos before > > we had the ipa-kdb driver. > I would prefer to have only one account for named daemon... Right, which is why we should have one entry in sysaccounts for named. The main issue is if we ever end up with 2 masters having different uid/gid assigned to the named user in /etc/passwd ... Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Jun 19 14:05:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 16:05:26 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403186540.12884.92.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> Message-ID: <53A2EE26.30501@redhat.com> On 19.6.2014 16:02, Simo Sorce wrote: > On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >>> On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: >>>> On Thu, 19 Jun 2014, Petr Spacek wrote: >>>>> On 19.6.2014 11:02, Alexander Bokovoy wrote: >>>>>> On Thu, 19 Jun 2014, Petr Spacek wrote: >>>>>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened >>>>>>> question "Why do we use Kerberos for named<->DS connection? Named connects >>>>>>> over LDAPI to local DS instance anyway." >>>>>>> >>>>>>> Maybe we can get rid of Kerberos for this particular connection and use >>>>>>> autobind instead. It would make it more reliable and effective. >>>>>>> >>>>>>> As a side effect, named will be able to start even if KDC is down for some >>>>>>> reason. It partially solves chicken-egg problem during IPA start-up. >>>>>>> >>>>>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know >>>>>>> historical reasons. >>>>>> My primary worry is the fact that any break in named/bind-dyndb-ldap >>>>>> could be then exploited to have access to all key material. In the case of >>>>>> GSSAPI you are confined to whatever ACIs allow for dns/ principal. >>>>> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so >>>>> I don't see any difference from using SASL/GSSAPI/Kerberos. >>>> My impression was that you wanted autobind to Directory Manager (root >>>> autobind), this is what I don't want to support, for sure. >>>> >>>>>> Samba case goes further -- I specifically added GSSAPI bind to Samba >>>>>> code LDAP code to allow splitting DCs and file servers while being able >>>>>> to use the same ipasam module securely, in addition to the usual >>>>>> ACI limitations. >>>>> Named has only one function (i.e. DNS server with support for DNS >>>>> updates). I don't think that there is meaningful separation. >>>>> >>>>>> For named what we could do is to have named+ldapi:// access mapped to >>>>>> specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth >>>>> This is OpenLDAP-ism, right? >>>> yes, this is what the client code reports. 389-ds server sees proper dn: >>>> >>>> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ >>>> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ >>>> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ >>>> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ >>>> --setattr=uid=named >>>> ----------------------------------------------- >>>> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" >>>> ----------------------------------------------- >>>> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI >>>> Managed by: ipa-01.t.vda.li >>>> >>>> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' >>>> SASL/EXTERNAL authentication started >>>> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth >>>> SASL SSF: 0 >>>> # extended LDIF >>>> # >>>> # LDAPv3 >>>> # base (default) with scope subtree >>>> # filter: cn=config >>>> # requesting: ALL >>>> # >>>> >>>> # search result >>>> search: 2 >>>> result: 0 Success >>>> >>>> # numResponses: 1 >>>> >>>> and here is what we see in the logs: >>>> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND >>>> >>>> >>>>> >>>>>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX >>>>> This object already exists for every single DNS server, which is >>>>> exactly the problem. Multiple servers are running under the same >>>>> UID/GID pair on Fedora. >>>> No, it is not a problem because there are multiple objects, one per >>>> server. >>>> >>>>>> There is an issue of uid/gid being different on different platforms, >>>>>> though but it is doable. >>>>> I can see the problem with UID/GID mapping to multiple different >>>>> principals. We can't remove these principals because they are used on >>>>> server side for DNS updates. >>>>> >>>>> Maybe we can create autobind mapping objects in some non-replicated >>>>> part of the tree. That would solve the problem with different UID/GIDs >>>>> on different platforms and also mapping UID/GID mapping to multiple >>>>> principals because one replica would see only one mapping object for >>>>> given UID/GID. >>>> No, I don't think we ever need to modify anything here apart from giving >>>> posixgroup/posixaccount object classes to the DNS principal per server >>>> and setting their properties. >>>> >>>> As you can see above, it simply works. I actually tested it with named >>>> too, by setting >>>> >>>> diff -up /etc/named.conf.old /etc/named.conf >>>> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 >>>> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 >>>> @@ -45,7 +45,7 @@ dynamic-db "ipa" { >>>> arg "base cn=dns, dc=t,dc=vda,dc=li"; >>>> arg "fake_mname ipa-01.t.vda.li."; >>>> arg "auth_method sasl"; >>>> - arg "sasl_mech GSSAPI"; >>>> - arg "sasl_user DNS/ipa-01.t.vda.li"; >>>> + arg "sasl_mech EXTERNAL"; >>>> + arg "sasl_user named"; >>>> arg "serial_autoincrement yes"; >>>> }; >>>> >>>> and named successfully started, with 389-ds showing autobind to the same >>>> krprincipalname=dns/... in the logs. >>> >>> why do we need to associate bind to dns/whatever ?? >> Because we already have ACIs given to dns/hostname to handle DNS >> entries. > > Which are easy to change on upgrade. > >>> we can have a sysaccount called named, like we did for kerberos before >>> we had the ipa-kdb driver. >> A modification of DNS service with 'ipa service-mod' is all what we >> need for single node case, I tried it. > > I do not like it at all, plus each server has a different object and > they would all be duplicates. I prefer very much a single, passwordless > special user in sysconfig, added to the same group that control access > for the DNS tree. We need to have the DNS principal for every replica anyway - for DNS updates. There is no way how to get rid of it without changes in GSS-TSIG protocol. -- Petr^2 Spacek From simo at redhat.com Thu Jun 19 14:08:31 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:08:31 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2EE26.30501@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <53A2EE26.30501@redhat.com> Message-ID: <1403186911.12884.96.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 16:05 +0200, Petr Spacek wrote: > On 19.6.2014 16:02, Simo Sorce wrote: > > On Thu, 2014-06-19 at 16:41 +0300, Alexander Bokovoy wrote: > >> On Thu, 19 Jun 2014, Simo Sorce wrote: > >>> On Thu, 2014-06-19 at 14:13 +0300, Alexander Bokovoy wrote: > >>>> On Thu, 19 Jun 2014, Petr Spacek wrote: > >>>>> On 19.6.2014 11:02, Alexander Bokovoy wrote: > >>>>>> On Thu, 19 Jun 2014, Petr Spacek wrote: > >>>>>>> the thread "named's LDAP connection hangs" on freeipa-users list [1] opened > >>>>>>> question "Why do we use Kerberos for named<->DS connection? Named connects > >>>>>>> over LDAPI to local DS instance anyway." > >>>>>>> > >>>>>>> Maybe we can get rid of Kerberos for this particular connection and use > >>>>>>> autobind instead. It would make it more reliable and effective. > >>>>>>> > >>>>>>> As a side effect, named will be able to start even if KDC is down for some > >>>>>>> reason. It partially solves chicken-egg problem during IPA start-up. > >>>>>>> > >>>>>>> I wasn't around when it bind-dyndb-ldap was designed so I don't know > >>>>>>> historical reasons. > >>>>>> My primary worry is the fact that any break in named/bind-dyndb-ldap > >>>>>> could be then exploited to have access to all key material. In the case of > >>>>>> GSSAPI you are confined to whatever ACIs allow for dns/ principal. > >>>>> IMHO autobind maps uid+gid to a DN and normal ACIs apply after that so > >>>>> I don't see any difference from using SASL/GSSAPI/Kerberos. > >>>> My impression was that you wanted autobind to Directory Manager (root > >>>> autobind), this is what I don't want to support, for sure. > >>>> > >>>>>> Samba case goes further -- I specifically added GSSAPI bind to Samba > >>>>>> code LDAP code to allow splitting DCs and file servers while being able > >>>>>> to use the same ipasam module securely, in addition to the usual > >>>>>> ACI limitations. > >>>>> Named has only one function (i.e. DNS server with support for DNS > >>>>> updates). I don't think that there is meaningful separation. > >>>>> > >>>>>> For named what we could do is to have named+ldapi:// access mapped to > >>>>>> specific DN uidNumber=+gidNumbe=,cn=peercred,cn=external,cn=auth > >>>>> This is OpenLDAP-ism, right? > >>>> yes, this is what the client code reports. 389-ds server sees proper dn: > >>>> > >>>> # ipa service-mod DNS/ipa-01.t.vda.li at T.VDA.LI \ > >>>> --addattr=objectclass=posixgroup --addattr=objectclass=posixaccount \ > >>>> --setattr=cn=DNS/ipa-01.t.vda.li --setattr=uidNumber=25 \ > >>>> --setattr=gidNumber=25 --setattr=HomeDirectory=/var/named \ > >>>> --setattr=uid=named > >>>> ----------------------------------------------- > >>>> Modified service "DNS/ipa-01.t.vda.li at T.VDA.LI" > >>>> ----------------------------------------------- > >>>> Principal: DNS/ipa-01.t.vda.li at T.VDA.LI > >>>> Managed by: ipa-01.t.vda.li > >>>> > >>>> # su -l named -s /bin/bash -c 'ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-T-VDA-LI.socket cn=config ' > >>>> SASL/EXTERNAL authentication started > >>>> SASL username: gidNumber=25+uidNumber=25,cn=peercred,cn=external,cn=auth > >>>> SASL SSF: 0 > >>>> # extended LDIF > >>>> # > >>>> # LDAPv3 > >>>> # base (default) with scope subtree > >>>> # filter: cn=config > >>>> # requesting: ALL > >>>> # > >>>> > >>>> # search result > >>>> search: 2 > >>>> result: 0 Success > >>>> > >>>> # numResponses: 1 > >>>> > >>>> and here is what we see in the logs: > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 AUTOBIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 BIND dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" method=sasl version=3 mech=EXTERNAL > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/ipa-01.t.vda.li at t.vda.li,cn=services,cn=accounts,dc=t,dc=vda,dc=li" > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 SRCH base="dc=t,dc=vda,dc=li" scope=2 filter="(cn=config)" attrs=ALL > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=1 RESULT err=0 tag=101 nentries=0 etime=0 > >>>> [19/Jun/2014:14:04:24 +0300] conn=177 op=2 UNBIND > >>>> > >>>> > >>>>> > >>>>>> dn: krbprincipalname=dns/$master@$REALM,cn=services,cn=accounts,$SUFFIX > >>>>> This object already exists for every single DNS server, which is > >>>>> exactly the problem. Multiple servers are running under the same > >>>>> UID/GID pair on Fedora. > >>>> No, it is not a problem because there are multiple objects, one per > >>>> server. > >>>> > >>>>>> There is an issue of uid/gid being different on different platforms, > >>>>>> though but it is doable. > >>>>> I can see the problem with UID/GID mapping to multiple different > >>>>> principals. We can't remove these principals because they are used on > >>>>> server side for DNS updates. > >>>>> > >>>>> Maybe we can create autobind mapping objects in some non-replicated > >>>>> part of the tree. That would solve the problem with different UID/GIDs > >>>>> on different platforms and also mapping UID/GID mapping to multiple > >>>>> principals because one replica would see only one mapping object for > >>>>> given UID/GID. > >>>> No, I don't think we ever need to modify anything here apart from giving > >>>> posixgroup/posixaccount object classes to the DNS principal per server > >>>> and setting their properties. > >>>> > >>>> As you can see above, it simply works. I actually tested it with named > >>>> too, by setting > >>>> > >>>> diff -up /etc/named.conf.old /etc/named.conf > >>>> --- /etc/named.conf.old 2014-06-19 14:10:40.725934702 +0300 > >>>> +++ /etc/named.conf 2014-06-19 14:10:58.432601624 +0300 > >>>> @@ -45,7 +45,7 @@ dynamic-db "ipa" { > >>>> arg "base cn=dns, dc=t,dc=vda,dc=li"; > >>>> arg "fake_mname ipa-01.t.vda.li."; > >>>> arg "auth_method sasl"; > >>>> - arg "sasl_mech GSSAPI"; > >>>> - arg "sasl_user DNS/ipa-01.t.vda.li"; > >>>> + arg "sasl_mech EXTERNAL"; > >>>> + arg "sasl_user named"; > >>>> arg "serial_autoincrement yes"; > >>>> }; > >>>> > >>>> and named successfully started, with 389-ds showing autobind to the same > >>>> krprincipalname=dns/... in the logs. > >>> > >>> why do we need to associate bind to dns/whatever ?? > >> Because we already have ACIs given to dns/hostname to handle DNS > >> entries. > > > > Which are easy to change on upgrade. > > > >>> we can have a sysaccount called named, like we did for kerberos before > >>> we had the ipa-kdb driver. > >> A modification of DNS service with 'ipa service-mod' is all what we > >> need for single node case, I tried it. > > > > I do not like it at all, plus each server has a different object and > > they would all be duplicates. I prefer very much a single, passwordless > > special user in sysconfig, added to the same group that control access > > for the DNS tree. > > We need to have the DNS principal for every replica anyway - for DNS updates. > There is no way how to get rid of it without changes in GSS-TSIG protocol. They serve 2 completely different purposes, there is no reason to tie LDAP access to one principal just because it is available to you to get keys for GSS-TSIG. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Jun 19 14:10:24 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 17:10:24 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403186540.12884.92.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> Message-ID: <20140619141024.GN7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >> >> and named successfully started, with 389-ds showing autobind to the same >> >> krprincipalname=dns/... in the logs. >> > >> >why do we need to associate bind to dns/whatever ?? >> Because we already have ACIs given to dns/hostname to handle DNS >> entries. > >Which are easy to change on upgrade. > >> >we can have a sysaccount called named, like we did for kerberos before >> >we had the ipa-kdb driver. >> A modification of DNS service with 'ipa service-mod' is all what we >> need for single node case, I tried it. > >I do not like it at all, plus each server has a different object and >they would all be duplicates. I prefer very much a single, passwordless >special user in sysconfig, added to the same group that control access >for the DNS tree. autobind needs uidNumber=+gidNumber= search to resolve to a single entry. Given that replicas might be running on machines where 'named' user could deviate (think Fedora, RHEL, and Debian), there will still be multiple 'named' sysaccounts and the whole story will break. I don't see how this helps compared to having DNS/hostname principal object extended to cover uidNumber/gidNumber. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jun 19 14:11:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 16:11:27 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2EDB5.1050803@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> <53A2ECD1.9080906@redhat.com> <53A2EDB5.1050803@redhat.com> Message-ID: <53A2EF8F.8060008@redhat.com> On 06/19/2014 04:03 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 06/19/2014 02:19 PM, Martin Kosek wrote: >>> On 06/19/2014 01:39 PM, Petr Viktorin wrote: >>>> See commit message. >>>> >>>> This was found in the review of host write permissions (my patches >>>> 0578-0579). >>> >>> Wouldn't it be better to filter based on objectclass? I.e.: >>> >>> (targetfilter="(!(objectclass=ipaConfigObject))" >>> >>> instead of DN based target filter? It seems to me that it is more >>> resilient to >>> changes in LDAP structure, in case we change RDN or make one more >>> level like >>> (just example): >>> >>> cn=DNSSEC,cn=DNS,cn=ipa.master.test,... >> >> Sure, fixed patch attached. > > Are you sure you need read access and not just search/compare? The > purpose is to see "is that thing there" and not "what is in that thing" > right? Sure someone could fish for masters if they really wanted to. > > rob I had the same idea and I did couple tests with just search&compare yesterday. However, neither form worked for me so I gave up. Martin From simo at redhat.com Thu Jun 19 14:16:15 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:16:15 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619141024.GN7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> Message-ID: <1403187375.12884.98.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: > >> >> and named successfully started, with 389-ds showing autobind to the same > >> >> krprincipalname=dns/... in the logs. > >> > > >> >why do we need to associate bind to dns/whatever ?? > >> Because we already have ACIs given to dns/hostname to handle DNS > >> entries. > > > >Which are easy to change on upgrade. > > > >> >we can have a sysaccount called named, like we did for kerberos before > >> >we had the ipa-kdb driver. > >> A modification of DNS service with 'ipa service-mod' is all what we > >> need for single node case, I tried it. > > > >I do not like it at all, plus each server has a different object and > >they would all be duplicates. I prefer very much a single, passwordless > >special user in sysconfig, added to the same group that control access > >for the DNS tree. > autobind needs uidNumber=+gidNumber= search to resolve to a > single entry. Given that replicas might be running on machines where > 'named' user could deviate (think Fedora, RHEL, and Debian), there will > still be multiple 'named' sysaccounts and the whole story will break. I > don't see how this helps compared to having DNS/hostname principal > object extended to cover uidNumber/gidNumber. This is not really a huge issue. We need to allow access to the DNS tree to a group, so all we need is for install/upgrade script to check what is the named user on the system and create a corresponding system account. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Jun 19 14:24:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 17:24:12 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403187375.12884.98.camel@willson.usersys.redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> Message-ID: <20140619142412.GO7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >> >> >> and named successfully started, with 389-ds showing autobind to the same >> >> >> krprincipalname=dns/... in the logs. >> >> > >> >> >why do we need to associate bind to dns/whatever ?? >> >> Because we already have ACIs given to dns/hostname to handle DNS >> >> entries. >> > >> >Which are easy to change on upgrade. >> > >> >> >we can have a sysaccount called named, like we did for kerberos before >> >> >we had the ipa-kdb driver. >> >> A modification of DNS service with 'ipa service-mod' is all what we >> >> need for single node case, I tried it. >> > >> >I do not like it at all, plus each server has a different object and >> >they would all be duplicates. I prefer very much a single, passwordless >> >special user in sysconfig, added to the same group that control access >> >for the DNS tree. >> autobind needs uidNumber=+gidNumber= search to resolve to a >> single entry. Given that replicas might be running on machines where >> 'named' user could deviate (think Fedora, RHEL, and Debian), there will >> still be multiple 'named' sysaccounts and the whole story will break. I >> don't see how this helps compared to having DNS/hostname principal >> object extended to cover uidNumber/gidNumber. > >This is not really a huge issue. >We need to allow access to the DNS tree to a group, so all we need is >for install/upgrade script to check what is the named user on the system >and create a corresponding system account. So, now we'll have to manage multiple named accounts named what, 'named1', 'named2', ... ? How to manage them? One solution could be to have multi-value uidNumber/gidNumber attributes... -- / Alexander Bokovoy From simo at redhat.com Thu Jun 19 14:26:09 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:26:09 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619142412.GO7233@redhat.com> References: <53A2948A.7000308@redhat.com> <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> Message-ID: <1403187969.12884.100.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: > >On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: > >> On Thu, 19 Jun 2014, Simo Sorce wrote: > >> >> >> and named successfully started, with 389-ds showing autobind to the same > >> >> >> krprincipalname=dns/... in the logs. > >> >> > > >> >> >why do we need to associate bind to dns/whatever ?? > >> >> Because we already have ACIs given to dns/hostname to handle DNS > >> >> entries. > >> > > >> >Which are easy to change on upgrade. > >> > > >> >> >we can have a sysaccount called named, like we did for kerberos before > >> >> >we had the ipa-kdb driver. > >> >> A modification of DNS service with 'ipa service-mod' is all what we > >> >> need for single node case, I tried it. > >> > > >> >I do not like it at all, plus each server has a different object and > >> >they would all be duplicates. I prefer very much a single, passwordless > >> >special user in sysconfig, added to the same group that control access > >> >for the DNS tree. > >> autobind needs uidNumber=+gidNumber= search to resolve to a > >> single entry. Given that replicas might be running on machines where > >> 'named' user could deviate (think Fedora, RHEL, and Debian), there will > >> still be multiple 'named' sysaccounts and the whole story will break. I > >> don't see how this helps compared to having DNS/hostname principal > >> object extended to cover uidNumber/gidNumber. > > > >This is not really a huge issue. > >We need to allow access to the DNS tree to a group, so all we need is > >for install/upgrade script to check what is the named user on the system > >and create a corresponding system account. > So, now we'll have to manage multiple named accounts named what, > 'named1', 'named2', ... ? How to manage them? what is there to manage ? > One solution could be to have multi-value uidNumber/gidNumber > attributes... nope, you just need to create a new object only if one does not exist with the same uidNumber, and add it to the group we use for ACIs on DNS. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Jun 19 14:33:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 17:33:34 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403187969.12884.100.camel@willson.usersys.redhat.com> References: <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> Message-ID: <20140619143334.GP7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >> >On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: >> >> On Thu, 19 Jun 2014, Simo Sorce wrote: >> >> >> >> and named successfully started, with 389-ds showing autobind to the same >> >> >> >> krprincipalname=dns/... in the logs. >> >> >> > >> >> >> >why do we need to associate bind to dns/whatever ?? >> >> >> Because we already have ACIs given to dns/hostname to handle DNS >> >> >> entries. >> >> > >> >> >Which are easy to change on upgrade. >> >> > >> >> >> >we can have a sysaccount called named, like we did for kerberos before >> >> >> >we had the ipa-kdb driver. >> >> >> A modification of DNS service with 'ipa service-mod' is all what we >> >> >> need for single node case, I tried it. >> >> > >> >> >I do not like it at all, plus each server has a different object and >> >> >they would all be duplicates. I prefer very much a single, passwordless >> >> >special user in sysconfig, added to the same group that control access >> >> >for the DNS tree. >> >> autobind needs uidNumber=+gidNumber= search to resolve to a >> >> single entry. Given that replicas might be running on machines where >> >> 'named' user could deviate (think Fedora, RHEL, and Debian), there will >> >> still be multiple 'named' sysaccounts and the whole story will break. I >> >> don't see how this helps compared to having DNS/hostname principal >> >> object extended to cover uidNumber/gidNumber. >> > >> >This is not really a huge issue. >> >We need to allow access to the DNS tree to a group, so all we need is >> >for install/upgrade script to check what is the named user on the system >> >and create a corresponding system account. >> So, now we'll have to manage multiple named accounts named what, >> 'named1', 'named2', ... ? How to manage them? > >what is there to manage ? > >> One solution could be to have multi-value uidNumber/gidNumber >> attributes... > >nope, you just need to create a new object only if one does not exist >with the same uidNumber, and add it to the group we use for ACIs on DNS. I assume the account like that shouldn't have any password at all, to prevent its use over LDAP instead of LDAPI. I'm still a bit uncomfortable with it because if this trend goes, we'll be making such accounts for other services as well. Given that we have no means to manage sysaccounts from IPA right now, their life cycle is a bit weird. I may need to revive my sysaccounts module... -- / Alexander Bokovoy From simo at redhat.com Thu Jun 19 14:37:33 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:37:33 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619143334.GP7233@redhat.com> References: <20140619090252.GD7233@redhat.com> <53A2BB90.6070404@redhat.com> <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> Message-ID: <1403188653.12884.102.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:33 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: > >On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote: > >> On Thu, 19 Jun 2014, Simo Sorce wrote: > >> >On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote: > >> >> On Thu, 19 Jun 2014, Simo Sorce wrote: > >> >> >> >> and named successfully started, with 389-ds showing autobind to the same > >> >> >> >> krprincipalname=dns/... in the logs. > >> >> >> > > >> >> >> >why do we need to associate bind to dns/whatever ?? > >> >> >> Because we already have ACIs given to dns/hostname to handle DNS > >> >> >> entries. > >> >> > > >> >> >Which are easy to change on upgrade. > >> >> > > >> >> >> >we can have a sysaccount called named, like we did for kerberos before > >> >> >> >we had the ipa-kdb driver. > >> >> >> A modification of DNS service with 'ipa service-mod' is all what we > >> >> >> need for single node case, I tried it. > >> >> > > >> >> >I do not like it at all, plus each server has a different object and > >> >> >they would all be duplicates. I prefer very much a single, passwordless > >> >> >special user in sysconfig, added to the same group that control access > >> >> >for the DNS tree. > >> >> autobind needs uidNumber=+gidNumber= search to resolve to a > >> >> single entry. Given that replicas might be running on machines where > >> >> 'named' user could deviate (think Fedora, RHEL, and Debian), there will > >> >> still be multiple 'named' sysaccounts and the whole story will break. I > >> >> don't see how this helps compared to having DNS/hostname principal > >> >> object extended to cover uidNumber/gidNumber. > >> > > >> >This is not really a huge issue. > >> >We need to allow access to the DNS tree to a group, so all we need is > >> >for install/upgrade script to check what is the named user on the system > >> >and create a corresponding system account. > >> So, now we'll have to manage multiple named accounts named what, > >> 'named1', 'named2', ... ? How to manage them? > > > >what is there to manage ? > > > >> One solution could be to have multi-value uidNumber/gidNumber > >> attributes... > > > >nope, you just need to create a new object only if one does not exist > >with the same uidNumber, and add it to the group we use for ACIs on DNS. > I assume the account like that shouldn't have any password at all, to > prevent its use over LDAP instead of LDAPI. Yep. > I'm still a bit uncomfortable with it because if this trend goes, we'll > be making such accounts for other services as well. Given that we have > no means to manage sysaccounts from IPA right now, their life cycle is a > bit weird. I know. > I may need to revive my sysaccounts module... There is one more issue though, and this one really concerns me. If you need to put there multiple accounts because different servers have different local accounts, then you open up access to unrelated services. Because all these uids are shared on all systems. I think this kills my own proposal of sticking these entries in cn=sysaccounts. However we could have something in cn=config maybe ? So that each server can: A) use the same name/DN B) have ids that match exactly the local named account no matter how many different variants we have C) no management issues when the server is killed from the infrastructure as cn=config is local to that server and goes away with it. What do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Thu Jun 19 14:47:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 17:47:02 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403188653.12884.102.camel@willson.usersys.redhat.com> References: <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> Message-ID: <20140619144702.GR7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >> I may need to revive my sysaccounts module... > >There is one more issue though, and this one really concerns me. >If you need to put there multiple accounts because different servers >have different local accounts, then you open up access to unrelated >services. Because all these uids are shared on all systems. > >I think this kills my own proposal of sticking these entries in >cn=sysaccounts. > >However we could have something in cn=config maybe ? >So that each server can: >A) use the same name/DN >B) have ids that match exactly the local named account no matter how >many different variants we have >C) no management issues when the server is killed from the >infrastructure as cn=config is local to that server and goes away with >it. > >What do you think ? This is what Petr proposed too. 389-ds autobind code searches starting from a base defined in cn=config. IPA defines it to be $SUFFIX. If we move these entries to cn=config, they will not be found by the code in ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a search base to something in cn=config, we wouldn't be able to use user accounts for autobind -- something which is possible right now. I'm not really concerned about user accounts' autobind but this is actually a behavior change for IPA. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jun 19 14:50:49 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 16:50:49 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2ECD1.9080906@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> <53A2ECD1.9080906@redhat.com> Message-ID: <53A2F8C9.4060005@redhat.com> On 06/19/2014 03:59 PM, Petr Viktorin wrote: > On 06/19/2014 02:19 PM, Martin Kosek wrote: >> On 06/19/2014 01:39 PM, Petr Viktorin wrote: >>> See commit message. >>> >>> This was found in the review of host write permissions (my patches 0578-0579). >> >> Wouldn't it be better to filter based on objectclass? I.e.: >> >> (targetfilter="(!(objectclass=ipaConfigObject))" >> >> instead of DN based target filter? It seems to me that it is more resilient to >> changes in LDAP structure, in case we change RDN or make one more level like >> (just example): >> >> cn=DNSSEC,cn=DNS,cn=ipa.master.test,... > > Sure, fixed patch attached. /me sighs. I took the information for granted and I did not read the ACI carefully and did not notice you sent wrong patch which I pushed... Could we please fix the filter and remove the target part now? Thanks, Martin From simo at redhat.com Thu Jun 19 14:52:57 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 10:52:57 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619144702.GR7233@redhat.com> References: <20140619111348.GE7233@redhat.com> <1403185007.12884.87.camel@willson.usersys.redhat.com> <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> Message-ID: <1403189577.12884.104.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: > >> I may need to revive my sysaccounts module... > > > >There is one more issue though, and this one really concerns me. > >If you need to put there multiple accounts because different servers > >have different local accounts, then you open up access to unrelated > >services. Because all these uids are shared on all systems. > > > >I think this kills my own proposal of sticking these entries in > >cn=sysaccounts. > > > >However we could have something in cn=config maybe ? > >So that each server can: > >A) use the same name/DN > >B) have ids that match exactly the local named account no matter how > >many different variants we have > >C) no management issues when the server is killed from the > >infrastructure as cn=config is local to that server and goes away with > >it. > > > >What do you think ? > This is what Petr proposed too. > > 389-ds autobind code searches starting from a base defined in cn=config. > IPA defines it to be $SUFFIX. If we move these entries to cn=config, > they will not be found by the code in > ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a > search base to something in cn=config, we wouldn't be able to use user > accounts for autobind -- something which is possible right now. > > I'm not really concerned about user accounts' autobind but this is > actually a behavior change for IPA. And I guess we can't list multiple bases for now ? We do not use autobind for anything now though, and I do not see it as useful for "normal" users on an IPA server, so I would be ok with the change, even if it breaks backward compatibility on masters themselves. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbasti at redhat.com Thu Jun 19 14:55:35 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Jun 2014 16:55:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <53A2E2C3.1010703@redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> <1403091728.20101.5.camel@unused-4-145.brq.redhat.com> <53A2E2C3.1010703@redhat.com> Message-ID: <1403189735.2295.19.camel@unused-4-145.brq.redhat.com> On Thu, 2014-06-19 at 15:16 +0200, Petr Vobornik wrote: > On 18.6.2014 13:42, Martin Basti wrote: > > Rebased patches with pep8 fixes attached > > git diff HEAD~4 -U0 | pep8 --diff --ignore=E501,E126,E128,E124 > ./ipalib/plugins/dns.py:1754:9: E265 block comment should start with '# ' > ./ipalib/plugins/dns.py:1755:9: E265 block comment should start with '# ' > ./ipalib/plugins/dns.py:2550:13: E265 block comment should start with '# ' > ./ipalib/plugins/dns.py:2551:16: E713 test for membership should be 'not in' > ./ipalib/plugins/dns.py:3516:9: E265 block comment should start with '# ' > ./ipalib/plugins/dns.py:3686:12: E713 test for membership should be 'not in' Thanks, I had an older pep8 version which didn't show me that > > I don't like how the patches are structured. It's hard to review. IMHO > you should have started with creation of the base class and then build > the forward zone on top of it. Reading a bunch of copy-pasted code with > minor changes which is then removed in the next patch is a waste of > time. Current approach is acceptable if the patch set is huge and > rebases would be really difficult. Or if it's sent and reviewed > separately. But what's done is done. Sorry for that. > > 1. Is it possible to disable the interactive wizard for dnsrecord-add > forward.zone.? It would be nice to show the error right at the beginning. It is partially possible. It requires to change interactive wizard for dnsrecord-mod, dnsrecord-del too. I vote for don't change it. > Patch 54-5: > 2. You forgot to remove the 'execute' method from 'dnszone_disable' and > 'dnszone_enable' > > 3. 'pre_callback' in 'dnsforwardzone_find' seems to be redundant, it > just calls the parent's pre_callback with no additional logic Thank you, I will remove it > > General question: > > Looking at the help text, especially the `--name=DNSNAMEPARAM`, I wonder > if have somewhere documented the formats of various param types. I dont know, I found nothing. I'm thinking about, rename it to DNSNAME only Rebased and fixed patches attached Thank you. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0052-6-Separate-master-and-forward-DNS-zones.patch Type: text/x-patch Size: 21640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0053-6-Prevent-commands-to-modify-different-type-of-a-zone.patch Type: text/x-patch Size: 11862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0054-6-Create-BASE-zone-class.patch Type: text/x-patch Size: 41133 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0055-6-Tests-DNS-forward-zones.patch Type: text/x-patch Size: 29017 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jun 19 14:58:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 17:58:50 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <1403189577.12884.104.camel@willson.usersys.redhat.com> References: <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> Message-ID: <20140619145850.GS7233@redhat.com> On Thu, 19 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >> >> I may need to revive my sysaccounts module... >> > >> >There is one more issue though, and this one really concerns me. >> >If you need to put there multiple accounts because different servers >> >have different local accounts, then you open up access to unrelated >> >services. Because all these uids are shared on all systems. >> > >> >I think this kills my own proposal of sticking these entries in >> >cn=sysaccounts. >> > >> >However we could have something in cn=config maybe ? >> >So that each server can: >> >A) use the same name/DN >> >B) have ids that match exactly the local named account no matter how >> >many different variants we have >> >C) no management issues when the server is killed from the >> >infrastructure as cn=config is local to that server and goes away with >> >it. >> > >> >What do you think ? >> This is what Petr proposed too. >> >> 389-ds autobind code searches starting from a base defined in cn=config. >> IPA defines it to be $SUFFIX. If we move these entries to cn=config, >> they will not be found by the code in >> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a >> search base to something in cn=config, we wouldn't be able to use user >> accounts for autobind -- something which is possible right now. >> >> I'm not really concerned about user accounts' autobind but this is >> actually a behavior change for IPA. > >And I guess we can't list multiple bases for now ? >We do not use autobind for anything now though, and I do not see it as >useful for "normal" users on an IPA server, so I would be ok with the >change, even if it breaks backward compatibility on masters themselves. The only thing we use is root autobind which is handled by a separate mechanism, I think. Thus, it suits me. Petr, can you please make a ticket? -- / Alexander Bokovoy From mkosek at redhat.com Thu Jun 19 15:06:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 17:06:27 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619145850.GS7233@redhat.com> References: <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> Message-ID: <53A2FC73.3060509@redhat.com> On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Simo Sorce wrote: >> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >>> On Thu, 19 Jun 2014, Simo Sorce wrote: >>> >> I may need to revive my sysaccounts module... >>> > >>> >There is one more issue though, and this one really concerns me. >>> >If you need to put there multiple accounts because different servers >>> >have different local accounts, then you open up access to unrelated >>> >services. Because all these uids are shared on all systems. >>> > >>> >I think this kills my own proposal of sticking these entries in >>> >cn=sysaccounts. >>> > >>> >However we could have something in cn=config maybe ? >>> >So that each server can: >>> >A) use the same name/DN >>> >B) have ids that match exactly the local named account no matter how >>> >many different variants we have >>> >C) no management issues when the server is killed from the >>> >infrastructure as cn=config is local to that server and goes away with >>> >it. >>> > >>> >What do you think ? >>> This is what Petr proposed too. >>> >>> 389-ds autobind code searches starting from a base defined in cn=config. >>> IPA defines it to be $SUFFIX. If we move these entries to cn=config, >>> they will not be found by the code in >>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a >>> search base to something in cn=config, we wouldn't be able to use user >>> accounts for autobind -- something which is possible right now. >>> >>> I'm not really concerned about user accounts' autobind but this is >>> actually a behavior change for IPA. >> >> And I guess we can't list multiple bases for now ? >> We do not use autobind for anything now though, and I do not see it as >> useful for "normal" users on an IPA server, so I would be ok with the >> change, even if it breaks backward compatibility on masters themselves. > The only thing we use is root autobind which is handled by a separate > mechanism, I think. > > Thus, it suits me. > > Petr, can you please make a ticket? How can you be sure that people do not already use the autobind feature? IMO, it is a bad move to just break it because we have no better idea how to handle named autobind. I would rather like to see improved autobind capability in 389-ds-base which would allow us to do the autobind configuration in cn=config and do entries like: uidnumber=25+gidnumber=25,cn=autobind,cn=config ... binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... And thus have a per-server configuration without breaking existent functionality. Martin From pspacek at redhat.com Thu Jun 19 15:10:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 19 Jun 2014 17:10:08 +0200 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2FC73.3060509@redhat.com> References: <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> Message-ID: <53A2FD50.3040909@redhat.com> On 19.6.2014 17:06, Martin Kosek wrote: > On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >>> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >>>> On Thu, 19 Jun 2014, Simo Sorce wrote: >>>>>> I may need to revive my sysaccounts module... >>>>> >>>>> There is one more issue though, and this one really concerns me. >>>>> If you need to put there multiple accounts because different servers >>>>> have different local accounts, then you open up access to unrelated >>>>> services. Because all these uids are shared on all systems. >>>>> >>>>> I think this kills my own proposal of sticking these entries in >>>>> cn=sysaccounts. >>>>> >>>>> However we could have something in cn=config maybe ? >>>>> So that each server can: >>>>> A) use the same name/DN >>>>> B) have ids that match exactly the local named account no matter how >>>>> many different variants we have >>>>> C) no management issues when the server is killed from the >>>>> infrastructure as cn=config is local to that server and goes away with >>>>> it. >>>>> >>>>> What do you think ? >>>> This is what Petr proposed too. >>>> >>>> 389-ds autobind code searches starting from a base defined in cn=config. >>>> IPA defines it to be $SUFFIX. If we move these entries to cn=config, >>>> they will not be found by the code in >>>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a >>>> search base to something in cn=config, we wouldn't be able to use user >>>> accounts for autobind -- something which is possible right now. >>>> >>>> I'm not really concerned about user accounts' autobind but this is >>>> actually a behavior change for IPA. >>> >>> And I guess we can't list multiple bases for now ? >>> We do not use autobind for anything now though, and I do not see it as >>> useful for "normal" users on an IPA server, so I would be ok with the >>> change, even if it breaks backward compatibility on masters themselves. >> The only thing we use is root autobind which is handled by a separate >> mechanism, I think. >> >> Thus, it suits me. >> >> Petr, can you please make a ticket? > > How can you be sure that people do not already use the autobind feature? IMO, > it is a bad move to just break it because we have no better idea how to handle > named autobind. > > I would rather like to see improved autobind capability in 389-ds-base which > would allow us to do the autobind configuration in cn=config and do entries like: > > uidnumber=25+gidnumber=25,cn=autobind,cn=config > ... > binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... > > And thus have a per-server configuration without breaking existent functionality. That is my favorite! (Which is not surprising, I was proposing exactly that almost 5 hours ago :-)) Anyway, the ticket is https://fedorahosted.org/freeipa/ticket/4388 -- Petr^2 Spacek From pviktori at redhat.com Thu Jun 19 15:11:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Jun 2014 17:11:56 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2F8C9.4060005@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> <53A2ECD1.9080906@redhat.com> <53A2F8C9.4060005@redhat.com> Message-ID: <53A2FDBC.4060300@redhat.com> On 06/19/2014 04:50 PM, Martin Kosek wrote: > On 06/19/2014 03:59 PM, Petr Viktorin wrote: >> On 06/19/2014 02:19 PM, Martin Kosek wrote: >>> On 06/19/2014 01:39 PM, Petr Viktorin wrote: >>>> See commit message. >>>> >>>> This was found in the review of host write permissions (my patches 0578-0579). >>> >>> Wouldn't it be better to filter based on objectclass? I.e.: >>> >>> (targetfilter="(!(objectclass=ipaConfigObject))" >>> >>> instead of DN based target filter? It seems to me that it is more resilient to >>> changes in LDAP structure, in case we change RDN or make one more level like >>> (just example): >>> >>> cn=DNSSEC,cn=DNS,cn=ipa.master.test,... >> >> Sure, fixed patch attached. > > /me sighs. I took the information for granted and I did not read the ACI > carefully and did not notice you sent wrong patch which I pushed... Could we > please fix the filter and remove the target part now? > > Thanks, > Martin Sorry for that :( Here is a fix patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0590.fix-Allow-read-access-to-masters-but-not-their-servi.patch Type: text/x-patch Size: 1493 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jun 19 15:16:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 18:16:13 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2FC73.3060509@redhat.com> References: <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> Message-ID: <20140619151613.GT7233@redhat.com> On Thu, 19 Jun 2014, Martin Kosek wrote: >On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: >> On Thu, 19 Jun 2014, Simo Sorce wrote: >>> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >>>> On Thu, 19 Jun 2014, Simo Sorce wrote: >>>> >> I may need to revive my sysaccounts module... >>>> > >>>> >There is one more issue though, and this one really concerns me. >>>> >If you need to put there multiple accounts because different servers >>>> >have different local accounts, then you open up access to unrelated >>>> >services. Because all these uids are shared on all systems. >>>> > >>>> >I think this kills my own proposal of sticking these entries in >>>> >cn=sysaccounts. >>>> > >>>> >However we could have something in cn=config maybe ? >>>> >So that each server can: >>>> >A) use the same name/DN >>>> >B) have ids that match exactly the local named account no matter how >>>> >many different variants we have >>>> >C) no management issues when the server is killed from the >>>> >infrastructure as cn=config is local to that server and goes away with >>>> >it. >>>> > >>>> >What do you think ? >>>> This is what Petr proposed too. >>>> >>>> 389-ds autobind code searches starting from a base defined in cn=config. >>>> IPA defines it to be $SUFFIX. If we move these entries to cn=config, >>>> they will not be found by the code in >>>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a >>>> search base to something in cn=config, we wouldn't be able to use user >>>> accounts for autobind -- something which is possible right now. >>>> >>>> I'm not really concerned about user accounts' autobind but this is >>>> actually a behavior change for IPA. >>> >>> And I guess we can't list multiple bases for now ? >>> We do not use autobind for anything now though, and I do not see it as >>> useful for "normal" users on an IPA server, so I would be ok with the >>> change, even if it breaks backward compatibility on masters themselves. >> The only thing we use is root autobind which is handled by a separate >> mechanism, I think. >> >> Thus, it suits me. >> >> Petr, can you please make a ticket? > >How can you be sure that people do not already use the autobind feature? IMO, >it is a bad move to just break it because we have no better idea how to handle >named autobind. autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it a violation of RFC4513 and if we limit who can use it I don't think anyone will be crying too much. >I would rather like to see improved autobind capability in 389-ds-base which >would allow us to do the autobind configuration in cn=config and do entries like: > >uidnumber=25+gidnumber=25,cn=autobind,cn=config >... >binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... > >And thus have a per-server configuration without breaking existent functionality. That would work too but the main ide is to simply change our, IPA, defaults, rather than implementing something new. If somebody relies on autobind to work for regular users on IPA masters without explicit authentication, it is already a question of a security breach. -- / Alexander Bokovoy From mkosek at redhat.com Thu Jun 19 15:16:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Jun 2014 17:16:31 +0200 Subject: [Freeipa-devel] [PATCH] 0590 Allow read access to masters, but not their services, to auth'd users In-Reply-To: <53A2FDBC.4060300@redhat.com> References: <53A2CC03.4010508@redhat.com> <53A2D538.2050704@redhat.com> <53A2ECD1.9080906@redhat.com> <53A2F8C9.4060005@redhat.com> <53A2FDBC.4060300@redhat.com> Message-ID: <53A2FECF.9060207@redhat.com> On 06/19/2014 05:11 PM, Petr Viktorin wrote: > On 06/19/2014 04:50 PM, Martin Kosek wrote: >> On 06/19/2014 03:59 PM, Petr Viktorin wrote: >>> On 06/19/2014 02:19 PM, Martin Kosek wrote: >>>> On 06/19/2014 01:39 PM, Petr Viktorin wrote: >>>>> See commit message. >>>>> >>>>> This was found in the review of host write permissions (my patches >>>>> 0578-0579). >>>> >>>> Wouldn't it be better to filter based on objectclass? I.e.: >>>> >>>> (targetfilter="(!(objectclass=ipaConfigObject))" >>>> >>>> instead of DN based target filter? It seems to me that it is more resilient to >>>> changes in LDAP structure, in case we change RDN or make one more level like >>>> (just example): >>>> >>>> cn=DNSSEC,cn=DNS,cn=ipa.master.test,... >>> >>> Sure, fixed patch attached. >> >> /me sighs. I took the information for granted and I did not read the ACI >> carefully and did not notice you sent wrong patch which I pushed... Could we >> please fix the filter and remove the target part now? >> >> Thanks, >> Martin > > Sorry for that :( > Here is a fix patch. Thanks. ACK, pushed (both) to master. Martin From rmeggins at redhat.com Thu Jun 19 15:23:35 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Jun 2014 09:23:35 -0600 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <20140619151613.GT7233@redhat.com> References: <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> <20140619151613.GT7233@redhat.com> Message-ID: <53A30077.8030300@redhat.com> On 06/19/2014 09:16 AM, Alexander Bokovoy wrote: > On Thu, 19 Jun 2014, Martin Kosek wrote: >> On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: >>> On Thu, 19 Jun 2014, Simo Sorce wrote: >>>> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >>>>> On Thu, 19 Jun 2014, Simo Sorce wrote: >>>>> >> I may need to revive my sysaccounts module... >>>>> > >>>>> >There is one more issue though, and this one really concerns me. >>>>> >If you need to put there multiple accounts because different servers >>>>> >have different local accounts, then you open up access to unrelated >>>>> >services. Because all these uids are shared on all systems. >>>>> > >>>>> >I think this kills my own proposal of sticking these entries in >>>>> >cn=sysaccounts. >>>>> > >>>>> >However we could have something in cn=config maybe ? >>>>> >So that each server can: >>>>> >A) use the same name/DN >>>>> >B) have ids that match exactly the local named account no matter how >>>>> >many different variants we have >>>>> >C) no management issues when the server is killed from the >>>>> >infrastructure as cn=config is local to that server and goes away >>>>> with >>>>> >it. >>>>> > >>>>> >What do you think ? >>>>> This is what Petr proposed too. >>>>> >>>>> 389-ds autobind code searches starting from a base defined in >>>>> cn=config. >>>>> IPA defines it to be $SUFFIX. If we move these entries to cn=config, >>>>> they will not be found by the code in >>>>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we >>>>> change a >>>>> search base to something in cn=config, we wouldn't be able to use >>>>> user >>>>> accounts for autobind -- something which is possible right now. >>>>> >>>>> I'm not really concerned about user accounts' autobind but this is >>>>> actually a behavior change for IPA. >>>> >>>> And I guess we can't list multiple bases for now ? >>>> We do not use autobind for anything now though, and I do not see it as >>>> useful for "normal" users on an IPA server, so I would be ok with the >>>> change, even if it breaks backward compatibility on masters >>>> themselves. >>> The only thing we use is root autobind which is handled by a separate >>> mechanism, I think. >>> >>> Thus, it suits me. >>> >>> Petr, can you please make a ticket? >> >> How can you be sure that people do not already use the autobind >> feature? IMO, >> it is a bad move to just break it because we have no better idea how >> to handle >> named autobind. > autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it > a violation of RFC4513 A violation even when using EXTERNAL bind? > and if we limit who can use it I don't think > anyone will be crying too much. If we change it to be incompatible, we may break existing _389_ customers, even if they are potentially using something that violates RFC4513. > >> I would rather like to see improved autobind capability in >> 389-ds-base which >> would allow us to do the autobind configuration in cn=config and do >> entries like: >> >> uidnumber=25+gidnumber=25,cn=autobind,cn=config >> ... >> binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... >> >> And thus have a per-server configuration without breaking existent >> functionality. > That would work too but the main ide is to simply change our, IPA, > defaults, rather than implementing something new. If somebody relies on > autobind to work for regular users on IPA masters without explicit > authentication, By explicit authentication do you mean using EXTERNAL bind? > it is already a question of a security breach. From tbordaz at redhat.com Thu Jun 19 15:32:58 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 19 Jun 2014 17:32:58 +0200 Subject: [Freeipa-devel] User life cycle: authentication and preserved attributes In-Reply-To: <1403185308.12884.89.camel@willson.usersys.redhat.com> References: <53A2E671.6060108@redhat.com> <1403185308.12884.89.camel@willson.usersys.redhat.com> Message-ID: <53A302AA.4010105@redhat.com> On 06/19/2014 03:41 PM, Simo Sorce wrote: > On Thu, 2014-06-19 at 15:32 +0200, thierry bordaz wrote: >> (those values must be active DN entries) >> userPassword/krb keys: copied from source entry if >> they >> exists > Uhmm this may actually fail, as we prevent storing pre-hashed > passwords :/ > We'll have to somehow detect that krbprincipalkeys are also being added > at the same time and allow pre-hashed password in that case, I guess. Oppss that is right, (ipapwd_pre_add I think) in that case there is no entry extension to retrieve the unhash password. > > > Also I realized one thing for deleted users, should we preserve password > History (should we put the last used password there) ? do you mean attribute krbPwdHistory or passwordHistory? keeping passwordHistory would improve security. This prevents reuse the same set of passwords just by doing user-delete/user-undelete. good to add the current password to this history. thierry > > Simo. > From abokovoy at redhat.com Thu Jun 19 15:39:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Jun 2014 18:39:14 +0300 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A30077.8030300@redhat.com> References: <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> <20140619151613.GT7233@redhat.com> <53A30077.8030300@redhat.com> Message-ID: <20140619153914.GU7233@redhat.com> On Thu, 19 Jun 2014, Rich Megginson wrote: >On 06/19/2014 09:16 AM, Alexander Bokovoy wrote: >>On Thu, 19 Jun 2014, Martin Kosek wrote: >>>On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: >>>>On Thu, 19 Jun 2014, Simo Sorce wrote: >>>>>On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: >>>>>>On Thu, 19 Jun 2014, Simo Sorce wrote: >>>>>>>> I may need to revive my sysaccounts module... >>>>>>> >>>>>>>There is one more issue though, and this one really concerns me. >>>>>>>If you need to put there multiple accounts because different servers >>>>>>>have different local accounts, then you open up access to unrelated >>>>>>>services. Because all these uids are shared on all systems. >>>>>>> >>>>>>>I think this kills my own proposal of sticking these entries in >>>>>>>cn=sysaccounts. >>>>>>> >>>>>>>However we could have something in cn=config maybe ? >>>>>>>So that each server can: >>>>>>>A) use the same name/DN >>>>>>>B) have ids that match exactly the local named account no matter how >>>>>>>many different variants we have >>>>>>>C) no management issues when the server is killed from the >>>>>>>infrastructure as cn=config is local to that server and >>>>>>goes away with >>>>>>>it. >>>>>>> >>>>>>>What do you think ? >>>>>>This is what Petr proposed too. >>>>>> >>>>>>389-ds autobind code searches starting from a base defined >>>>>>in cn=config. >>>>>>IPA defines it to be $SUFFIX. If we move these entries to cn=config, >>>>>>they will not be found by the code in >>>>>>ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If >>>>>>we change a >>>>>>search base to something in cn=config, we wouldn't be able >>>>>>to use user >>>>>>accounts for autobind -- something which is possible right now. >>>>>> >>>>>>I'm not really concerned about user accounts' autobind but this is >>>>>>actually a behavior change for IPA. >>>>> >>>>>And I guess we can't list multiple bases for now ? >>>>>We do not use autobind for anything now though, and I do not see it as >>>>>useful for "normal" users on an IPA server, so I would be ok with the >>>>>change, even if it breaks backward compatibility on masters >>>>>themselves. >>>>The only thing we use is root autobind which is handled by a separate >>>>mechanism, I think. >>>> >>>>Thus, it suits me. >>>> >>>>Petr, can you please make a ticket? >>> >>>How can you be sure that people do not already use the autobind >>>feature? IMO, >>>it is a bad move to just break it because we have no better idea >>>how to handle >>>named autobind. >>autobind is a feature of 389-ds only. Howard Chu (OpenLDAP) considers it >>a violation of RFC4513 > >A violation even when using EXTERNAL bind? Howard's line of thought was that RFC4513 requires to have anonymous bind when no credentials were provided. Autobind makes implicit conversion to authenticated bind here. I know that at the time of discussion (~2007) 389-ds team's approach was that LDAPI is not really LDAP protocol wise and it could deviate here. > >>and if we limit who can use it I don't think >>anyone will be crying too much. > >If we change it to be incompatible, we may break existing _389_ >customers, even if they are potentially using something that violates >RFC4513. > >> >>>I would rather like to see improved autobind capability in >>>389-ds-base which >>>would allow us to do the autobind configuration in cn=config and >>>do entries like: >>> >>>uidnumber=25+gidnumber=25,cn=autobind,cn=config >>>... >>>binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... >>> >>>And thus have a per-server configuration without breaking existent >>>functionality. >>That would work too but the main ide is to simply change our, IPA, >>defaults, rather than implementing something new. If somebody relies on >>autobind to work for regular users on IPA masters without explicit >>authentication, > >By explicit authentication do you mean using EXTERNAL bind? I mean that by becoming a non-privileged user on a 389-ds server that has anonymous bind disabled will give you non-authenticated access to LDAP store through autobind+LDAPI. Non-authenticated in terms of not providing any authentication data to LDAP store. So breaking a user account is enough to get data (subject to ACIs, of course), you don't need to have any idea of what credentials the user should have. It is question of policies to be set and for FreeIPA masters I would argue that the policy should be to prevent non-privileged users to do autobind+LDAPI unless it is explicitly allowed by the configuration for that specific user. -- / Alexander Bokovoy From npmccallum at redhat.com Thu Jun 19 16:36:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 19 Jun 2014 12:36:26 -0400 Subject: [Freeipa-devel] [PATCH] [IMPORTANT] Make otptoken use os.urandom() for random data Message-ID: <1403195786.6477.22.camel@ipa.example.com> This also fixes an error where the default value was not respecting the KEY_LENGTH variable. (NOTE: the os.urandom() change should not change the security properties of the existing code. However, the failure of the previous code to respect KEY_LENGTH causes us to violate the RFC.) -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0057-Make-otptoken-use-os.urandom-for-random-data.patch Type: text/x-patch Size: 1303 bytes Desc: not available URL: From mbasti at redhat.com Thu Jun 19 16:37:10 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 19 Jun 2014 18:37:10 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0063 Update DNSSEC attributes/record types In-Reply-To: <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> Message-ID: <1403195830.2295.22.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-13 at 09:55 +0200, Martin Basti wrote: > On Thu, 2014-06-12 at 16:20 +0200, Martin Basti wrote: > > On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: > > > On 9.6.2014 17:28, Martin Basti wrote: > > > > Ticket: https://fedorahosted.org/freeipa/ticket/4328 > > > > > > > > Petr please make the WebUI patch review (0062) :-) > > > > > > > > Patches attached. > > > > > > > > > > Patch #0059: LGTM > > > > > > Patch #0060: > > > > > > 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise > > > you get general "Text does not match field pattern" error message in Web UI. > > > > > I will add the message. > > > > > 2. Could be in one if: > > > + if nsec3params is not None: > > > + if len(nsec3params) > 1: > > > > > > Maybe I'm missing something. But why does the dns plugin code use > > > following all over the place: > > > > > > try: > > > nsec3params = rrattrs['nsec3paramrecord'] > > > except KeyError: > > > pass > > > else: > > > if nsec3params is not None: > > > > > > instead of: > > > > > > nsec3params = rrattrs.get('nsec3paramrecord') > > > if nsec3params is not None: > > > > > > btw you use both patterns in the patch. > > I will use shorten form, I wrote it in the same way as the other code in > > the block was written, that's why. > > > > > > > > Patch #0061: ACK > > > > > > > > > Patch #0062: > > > > > > 3. Why are there the idnafsdbrec1 variables? > > > > > It was replace for NSEC records, which are not supported anymore. > > Now I realize, there is wrong description, so the idnafsbrec1 variable > > is not needed. > > I will remove it. > > > > > 4. related to ^^: > > > ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing > > > whitespace after ',' > > > > > > > > > Patch #0063: LGTM > > > IDK if they work because I'm experiencing some weird issues with > > > xmlrpc_tests in general. > > I had troubles only with permission tests, but all DNS test worked fine for me. > > > > Thank you for review. > > > Updated patches attached. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rebased patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0059-3-DNSSEC-remove-unsuported-records.patch Type: text/x-patch Size: 22388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0060-3-DNSSEC-added-NSEC3PARAM-record-type.patch Type: text/x-patch Size: 19102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0061-3-DNSSEC-webui-update-DNSSEC-attributes.patch Type: text/x-patch Size: 6106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0062-3-Tests-remove-unused-records-from-tests.patch Type: text/x-patch Size: 4534 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0063-3-Tests-tests-for-NSEC3PARAM-records.patch Type: text/x-patch Size: 3186 bytes Desc: not available URL: From ssorce at redhat.com Thu Jun 19 16:40:11 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 12:40:11 -0400 Subject: [Freeipa-devel] User life cycle: authentication and preserved attributes In-Reply-To: <53A302AA.4010105@redhat.com> References: <53A2E671.6060108@redhat.com> <1403185308.12884.89.camel@willson.usersys.redhat.com> <53A302AA.4010105@redhat.com> Message-ID: <1403196011.12884.109.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:32 +0200, thierry bordaz wrote: > On 06/19/2014 03:41 PM, Simo Sorce wrote: > > On Thu, 2014-06-19 at 15:32 +0200, thierry bordaz wrote: > >> (those values must be active DN entries) > >> userPassword/krb keys: copied from source entry if > >> they > >> exists > > Uhmm this may actually fail, as we prevent storing pre-hashed > > passwords :/ > > We'll have to somehow detect that krbprincipalkeys are also being added > > at the same time and allow pre-hashed password in that case, I guess. > Oppss that is right, (ipapwd_pre_add I think) in that case there is no > entry extension to retrieve the unhash password. Yeah we would need to change the logic there, to allow this specific case. > > Also I realized one thing for deleted users, should we preserve password > > History (should we put the last used password there) ? > do you mean attribute krbPwdHistory or passwordHistory? We do not use krbPwdHistory > keeping passwordHistory would improve security. This prevents reuse the > same set of passwords just by doing user-delete/user-undelete. > good to add the current password to this history. Right, but should we add there the current password being deleted ? I think we should, unless we want to allow a user to pick up the same password he had before deletion, which could be clearly expired by the time a user is reactivated. Simo. From ssorce at redhat.com Thu Jun 19 16:43:35 2014 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 12:43:35 -0400 Subject: [Freeipa-devel] [PATCH] [IMPORTANT] Make otptoken use os.urandom() for random data In-Reply-To: <1403195786.6477.22.camel@ipa.example.com> References: <1403195786.6477.22.camel@ipa.example.com> Message-ID: <1403196215.12884.111.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 12:36 -0400, Nathaniel McCallum wrote: > This also fixes an error where the default value was not respecting > the KEY_LENGTH variable. > > (NOTE: the os.urandom() change should not change the security properties > of the existing code. However, the failure of the previous code to > respect KEY_LENGTH causes us to violate the RFC.) LGTM! I do prefer using os.urandom() directly, as random.SystemRandom uses it under the hood anyway. Simo. From simo at redhat.com Thu Jun 19 16:47:37 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 12:47:37 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A2FC73.3060509@redhat.com> References: <20140619134128.GL7233@redhat.com> <1403186540.12884.92.camel@willson.usersys.redhat.com> <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> Message-ID: <1403196457.12884.113.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 17:06 +0200, Martin Kosek wrote: > On 06/19/2014 04:58 PM, Alexander Bokovoy wrote: > > On Thu, 19 Jun 2014, Simo Sorce wrote: > >> On Thu, 2014-06-19 at 17:47 +0300, Alexander Bokovoy wrote: > >>> On Thu, 19 Jun 2014, Simo Sorce wrote: > >>> >> I may need to revive my sysaccounts module... > >>> > > >>> >There is one more issue though, and this one really concerns me. > >>> >If you need to put there multiple accounts because different servers > >>> >have different local accounts, then you open up access to unrelated > >>> >services. Because all these uids are shared on all systems. > >>> > > >>> >I think this kills my own proposal of sticking these entries in > >>> >cn=sysaccounts. > >>> > > >>> >However we could have something in cn=config maybe ? > >>> >So that each server can: > >>> >A) use the same name/DN > >>> >B) have ids that match exactly the local named account no matter how > >>> >many different variants we have > >>> >C) no management issues when the server is killed from the > >>> >infrastructure as cn=config is local to that server and goes away with > >>> >it. > >>> > > >>> >What do you think ? > >>> This is what Petr proposed too. > >>> > >>> 389-ds autobind code searches starting from a base defined in cn=config. > >>> IPA defines it to be $SUFFIX. If we move these entries to cn=config, > >>> they will not be found by the code in > >>> ds/ldap/servers/slapd/daemon.c:slapd_bind_local_user(). If we change a > >>> search base to something in cn=config, we wouldn't be able to use user > >>> accounts for autobind -- something which is possible right now. > >>> > >>> I'm not really concerned about user accounts' autobind but this is > >>> actually a behavior change for IPA. > >> > >> And I guess we can't list multiple bases for now ? > >> We do not use autobind for anything now though, and I do not see it as > >> useful for "normal" users on an IPA server, so I would be ok with the > >> change, even if it breaks backward compatibility on masters themselves. > > The only thing we use is root autobind which is handled by a separate > > mechanism, I think. > > > > Thus, it suits me. > > > > Petr, can you please make a ticket? > > How can you be sure that people do not already use the autobind feature? Regular users should nto really log into the master anyway, so unless we are using this feature in one of the IPA components I would say it is an "unsupported" usage (and highly unlikely anyway as it is not a well know feature). > IMO, > it is a bad move to just break it because we have no better idea how to handle > named autobind. Oh but we do have a better idea :) > I would rather like to see improved autobind capability in 389-ds-base which > would allow us to do the autobind configuration in cn=config and do entries like: > > uidnumber=25+gidnumber=25,cn=autobind,cn=config > ... > binddn: krbprincipalname=DNS/ipa.server.test,cn=computers... > > And thus have a per-server configuration without breaking existent functionality. I do not think it is worth it. Yes we could maintain the feature, but I would worry about adding code only if we have someone with a good use case for using regular shared users and autobind and not being able to migrate to add an entry in cn=config. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Jun 19 16:59:47 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Jun 2014 12:59:47 -0400 Subject: [Freeipa-devel] LDAPI + autobind instead of Kerberos (for named)? In-Reply-To: <53A30077.8030300@redhat.com> References: <20140619141024.GN7233@redhat.com> <1403187375.12884.98.camel@willson.usersys.redhat.com> <20140619142412.GO7233@redhat.com> <1403187969.12884.100.camel@willson.usersys.redhat.com> <20140619143334.GP7233@redhat.com> <1403188653.12884.102.camel@willson.usersys.redhat.com> <20140619144702.GR7233@redhat.com> <1403189577.12884.104.camel@willson.usersys.redhat.com> <20140619145850.GS7233@redhat.com> <53A2FC73.3060509@redhat.com> <20140619151613.GT7233@redhat.com> <53A30077.8030300@redhat.com> Message-ID: <1403197187.12884.115.camel@willson.usersys.redhat.com> On Thu, 2014-06-19 at 09:23 -0600, Rich Megginson wrote: > > and if we limit who can use it I don't think > > anyone will be crying too much. > > If we change it to be incompatible, we may break existing _389_ > customers, even if they are potentially using something that violates > RFC4513. I am not proposing to change anything in 389ds, just the configuration of the suffix to look at so we are not breaking any _389_ customer. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Jun 19 20:30:51 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 19 Jun 2014 16:30:51 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command Message-ID: <1403209851.6477.25.camel@ipa.example.com> This command behaves almost exactly like otptoken-add except: 1. The new token data is written directly to a YubiKey 2. The vendor/model/serial fields are populated from the YubiKey === NOTE === 1. This patch depends on the new Fedora package: python-yubico. If you would like to help with the package review, please assign yourself here: https://bugzilla.redhat.com/show_bug.cgi?id=1111334 2. This patch doesn't actually work and I could use some help. The call to api.Command.otptoken_add() fails with: ipa: ERROR: non-public: AttributeError: no context.rpcclient in thread 'MainThread' Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 471, in forward **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 874, in forward command = getattr(self.conn, name) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' ipa: ERROR: an internal error has occurred -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058-Add-the-otptoken-add-yubikey-command.patch Type: text/x-patch Size: 4466 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 20 08:32:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Jun 2014 10:32:12 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> Message-ID: <53A3F18C.60903@redhat.com> On 18.6.2014 16:49, Martin Basti wrote: > Due to compability with older versions, only IDNA domains should be > checked > Patch attached. I'm not particularly happy about the u'\xdf' special case. Isn't there a better way to do this check? (BTW I really think this should be a warning, not an error, but that would require larger amount of work, so I guess it's OK for now.) -- Jan Cholasta From mbasti at redhat.com Fri Jun 20 08:48:23 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 10:48:23 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53A3F18C.60903@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> Message-ID: <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: > On 18.6.2014 16:49, Martin Basti wrote: > > Due to compability with older versions, only IDNA domains should be > > checked > > Patch attached. > > I'm not particularly happy about the u'\xdf' special case. Isn't there a > better way to do this check? I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN string. Or just remove this validation. > (BTW I really think this should be a warning, not an error, but that > would require larger amount of work, so I guess it's OK for now.) (More pain than gain) -- Martin^2 Basti From jcholast at redhat.com Fri Jun 20 08:50:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Jun 2014 10:50:48 +0200 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403209851.6477.25.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> Message-ID: <53A3F5E8.4050804@redhat.com> Hi, On 19.6.2014 22:30, Nathaniel McCallum wrote: > This command behaves almost exactly like otptoken-add except: > 1. The new token data is written directly to a YubiKey > 2. The vendor/model/serial fields are populated from the YubiKey > > === NOTE === > 1. This patch depends on the new Fedora package: python-yubico. If you > would like to help with the package review, please assign yourself here: > https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > > 2. This patch doesn't actually work and I could use some help. The call > to api.Command.otptoken_add() fails with: > ipa: ERROR: non-public: AttributeError: no context.rpcclient in thread > 'MainThread' > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, > in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", > line 471, in forward > **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, > in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, > in forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 874, in > forward > command = getattr(self.conn, name) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in > __get_conn > self.id, threading.currentThread().getName()) > AttributeError: no context.rpcclient in thread 'MainThread' > ipa: ERROR: an internal error has occurred > This happens because when you use frontend.Local, no connection to the server is created (see cli.run()). Instead of using frontend.Local and overriding forward(), use frontend.Command and override execute(). Honza -- Jan Cholasta From mbasti at redhat.com Fri Jun 20 09:06:37 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 11:06:37 +0200 Subject: [Freeipa-devel] [PATCH 0019] Clarify LDAPClient docstrings about get_entry, get_entries and find_entrie In-Reply-To: <53A1B1E2.3030108@redhat.com> References: <53A1B1E2.3030108@redhat.com> Message-ID: <1403255197.2336.10.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-18 at 17:36 +0200, Petr Spacek wrote: > Hello, > > Clarify LDAPClient docstrings about get_entry, get_entries and find_entries. > > > BTW what is the purpose of size_limit in LDAPClient.get_entry()? > > def get_entry(self, dn, attrs_list=None, time_limit=None, > size_limit=None) > I dont know, IMHO LDAP should return only one or no entry. ACK -- Martin^2 Basti From tbordaz at redhat.com Fri Jun 20 09:40:36 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 20 Jun 2014 11:40:36 +0200 Subject: [Freeipa-devel] [PATCH 0019] Clarify LDAPClient docstrings about get_entry, get_entries and find_entrie In-Reply-To: <1403255197.2336.10.camel@unused-4-145.brq.redhat.com> References: <53A1B1E2.3030108@redhat.com> <1403255197.2336.10.camel@unused-4-145.brq.redhat.com> Message-ID: <53A40194.1060904@redhat.com> On 06/20/2014 11:06 AM, Martin Basti wrote: > On Wed, 2014-06-18 at 17:36 +0200, Petr Spacek wrote: >> Hello, >> >> Clarify LDAPClient docstrings about get_entry, get_entries and find_entries. >> >> >> BTW what is the purpose of size_limit in LDAPClient.get_entry()? >> >> def get_entry(self, dn, attrs_list=None, time_limit=None, >> size_limit=None) >> > I dont know, IMHO LDAP should return only one or no entry. I agree get_entry is a base search so setting a size limit (max entres to get) does not bring any value. > > ACK From mkosek at redhat.com Fri Jun 20 10:39:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 12:39:45 +0200 Subject: [Freeipa-devel] [PATCH 0019] Clarify LDAPClient docstrings about get_entry, get_entries and find_entrie In-Reply-To: <1403255197.2336.10.camel@unused-4-145.brq.redhat.com> References: <53A1B1E2.3030108@redhat.com> <1403255197.2336.10.camel@unused-4-145.brq.redhat.com> Message-ID: <53A40F71.9030401@redhat.com> On 06/20/2014 11:06 AM, Martin Basti wrote: > On Wed, 2014-06-18 at 17:36 +0200, Petr Spacek wrote: >> Hello, >> >> Clarify LDAPClient docstrings about get_entry, get_entries and find_entries. >> >> >> BTW what is the purpose of size_limit in LDAPClient.get_entry()? >> >> def get_entry(self, dn, attrs_list=None, time_limit=None, >> size_limit=None) >> > I dont know, IMHO LDAP should return only one or no entry. > > ACK > Pushed to master: e821576129907d89a812edde45121d365a1f696d Martin From mbasti at redhat.com Fri Jun 20 11:06:45 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 13:06:45 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix - handle python-dns UnicodeError Message-ID: <1403262405.2336.13.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0071-Fix-handle-python-dns-UnicodeError.patch Type: text/x-patch Size: 1231 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 20 11:16:08 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Jun 2014 13:16:08 +0200 Subject: [Freeipa-devel] [PATCHES] 0052-0055 Separate master and forward DNS zones to separate objectClasses In-Reply-To: <1403189735.2295.19.camel@unused-4-145.brq.redhat.com> References: <1401295689.2263.9.camel@unused-4-145.brq.redhat.com> <1401297106.2263.20.camel@unused-4-145.brq.redhat.com> <1401710263.2253.2.camel@unused-4-145.brq.redhat.com> <1402501307.2280.1.camel@unused-4-145.brq.redhat.com> <1402562855.2280.2.camel@unused-4-145.brq.redhat.com> <1403091728.20101.5.camel@unused-4-145.brq.redhat.com> <53A2E2C3.1010703@redhat.com> <1403189735.2295.19.camel@unused-4-145.brq.redhat.com> Message-ID: <53A417F8.306@redhat.com> On 19.6.2014 16:55, Martin Basti wrote: > On Thu, 2014-06-19 at 15:16 +0200, Petr Vobornik wrote: >> On 18.6.2014 13:42, Martin Basti wrote: >>> Rebased patches with pep8 fixes attached >> >> git diff HEAD~4 -U0 | pep8 --diff --ignore=E501,E126,E128,E124 >> ./ipalib/plugins/dns.py:1754:9: E265 block comment should start with '# ' >> ./ipalib/plugins/dns.py:1755:9: E265 block comment should start with '# ' >> ./ipalib/plugins/dns.py:2550:13: E265 block comment should start with '# ' >> ./ipalib/plugins/dns.py:2551:16: E713 test for membership should be 'not in' >> ./ipalib/plugins/dns.py:3516:9: E265 block comment should start with '# ' >> ./ipalib/plugins/dns.py:3686:12: E713 test for membership should be 'not in' > Thanks, I had an older pep8 version which didn't show me that >> >> I don't like how the patches are structured. It's hard to review. IMHO >> you should have started with creation of the base class and then build >> the forward zone on top of it. Reading a bunch of copy-pasted code with >> minor changes which is then removed in the next patch is a waste of >> time. Current approach is acceptable if the patch set is huge and >> rebases would be really difficult. Or if it's sent and reviewed >> separately. But what's done is done. > Sorry for that. > >> >> 1. Is it possible to disable the interactive wizard for dnsrecord-add >> forward.zone.? It would be nice to show the error right at the beginning. > It is partially possible. It requires to change interactive wizard for > dnsrecord-mod, dnsrecord-del too. > I vote for don't change it. > >> Patch 54-5: >> 2. You forgot to remove the 'execute' method from 'dnszone_disable' and >> 'dnszone_enable' >> >> 3. 'pre_callback' in 'dnsforwardzone_find' seems to be redundant, it >> just calls the parent's pre_callback with no additional logic > Thank you, I will remove it >> >> General question: >> >> Looking at the help text, especially the `--name=DNSNAMEPARAM`, I wonder >> if have somewhere documented the formats of various param types. > I dont know, I found nothing. > I'm thinking about, rename it to DNSNAME only > > Rebased and fixed patches attached > Thank you. > ACK, pushed to master: * 49068ade92b3fa4874b3107923bbd5b84e1a04f3 Separate master and forward DNS zones * 266015c3e28c04894cd3a52ea2f99c25eef2c6a9 Prevent commands to modify different type of a zone * 727f5f33732df252fa99d5c168d6727589ee6076 Create BASE zone class * 11c250a6125da300f85880e090e5db1659078daa Tests DNS: forward zones -- Petr Vobornik From jcholast at redhat.com Fri Jun 20 11:28:36 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Jun 2014 13:28:36 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix - handle python-dns UnicodeError In-Reply-To: <1403262405.2336.13.camel@unused-4-145.brq.redhat.com> References: <1403262405.2336.13.camel@unused-4-145.brq.redhat.com> Message-ID: <53A41AE4.1000208@redhat.com> On 20.6.2014 13:06, Martin Basti wrote: > Patch attached > ACK. -- Jan Cholasta From mkosek at redhat.com Fri Jun 20 11:29:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 13:29:33 +0200 Subject: [Freeipa-devel] [PATCH 0071] Fix - handle python-dns UnicodeError In-Reply-To: <53A41AE4.1000208@redhat.com> References: <1403262405.2336.13.camel@unused-4-145.brq.redhat.com> <53A41AE4.1000208@redhat.com> Message-ID: <53A41B1D.8010205@redhat.com> On 06/20/2014 01:28 PM, Jan Cholasta wrote: > On 20.6.2014 13:06, Martin Basti wrote: >> Patch attached >> > > ACK. > Pushed to master: 9f5e77f686a974b837da6eb92cec741fcbb33603 Martin From pviktori at redhat.com Fri Jun 20 12:14:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Jun 2014 14:14:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0591-0593 Change group permission object filter In-Reply-To: <53997BC5.6000901@redhat.com> References: <53997BA0.50608@redhat.com> <53997BC5.6000901@redhat.com> Message-ID: <53A42598.7020507@redhat.com> My patch 0580 was wrong; non-POSIX groups obviously lack the posixgroup objectclass. Actually the only objectclasses that all groups share are top and ipaobject. This makes permission plugin & updater join multiple permission_filter_objectclasses filters with OR, and changes the --type group filter to (|(objectclass=ipausergroup)(objectclass=posixgroup)). The first patch has some unrelated test fixes. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0591-Test-and-docstring-fixes.patch Type: text/x-patch Size: 6957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0592-permission-plugin-Join-type-objectclass-filters-with.patch Type: text/x-patch Size: 5671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0593-Add-posixgroup-to-groups-permission-object-filter.patch Type: text/x-patch Size: 10816 bytes Desc: not available URL: From mbasti at redhat.com Fri Jun 20 12:35:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 14:35:12 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0063 Update DNSSEC attributes/record types In-Reply-To: <1403195830.2295.22.camel@unused-4-145.brq.redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> <1403195830.2295.22.camel@unused-4-145.brq.redhat.com> Message-ID: <1403267712.2336.14.camel@unused-4-145.brq.redhat.com> On Thu, 2014-06-19 at 18:37 +0200, Martin Basti wrote: > On Fri, 2014-06-13 at 09:55 +0200, Martin Basti wrote: > > On Thu, 2014-06-12 at 16:20 +0200, Martin Basti wrote: > > > On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: > > > > On 9.6.2014 17:28, Martin Basti wrote: > > > > > Ticket: https://fedorahosted.org/freeipa/ticket/4328 > > > > > > > > > > Petr please make the WebUI patch review (0062) :-) > > > > > > > > > > Patches attached. > > > > > > > > > > > > > Patch #0059: LGTM > > > > > > > > Patch #0060: > > > > > > > > 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise > > > > you get general "Text does not match field pattern" error message in Web UI. > > > > > > > I will add the message. > > > > > > > 2. Could be in one if: > > > > + if nsec3params is not None: > > > > + if len(nsec3params) > 1: > > > > > > > > Maybe I'm missing something. But why does the dns plugin code use > > > > following all over the place: > > > > > > > > try: > > > > nsec3params = rrattrs['nsec3paramrecord'] > > > > except KeyError: > > > > pass > > > > else: > > > > if nsec3params is not None: > > > > > > > > instead of: > > > > > > > > nsec3params = rrattrs.get('nsec3paramrecord') > > > > if nsec3params is not None: > > > > > > > > btw you use both patterns in the patch. > > > I will use shorten form, I wrote it in the same way as the other code in > > > the block was written, that's why. > > > > > > > > > > > Patch #0061: ACK > > > > > > > > > > > > Patch #0062: > > > > > > > > 3. Why are there the idnafsdbrec1 variables? > > > > > > > It was replace for NSEC records, which are not supported anymore. > > > Now I realize, there is wrong description, so the idnafsbrec1 variable > > > is not needed. > > > I will remove it. > > > > > > > 4. related to ^^: > > > > ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing > > > > whitespace after ',' > > > > > > > > > > > > Patch #0063: LGTM > > > > IDK if they work because I'm experiencing some weird issues with > > > > xmlrpc_tests in general. > > > I had troubles only with permission tests, but all DNS test worked fine for me. > > > > > > Thank you for review. > > > > > Updated patches attached. > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Rebased patches attached > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patch attached, fixed missing update permission -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0060-4-DNSSEC-added-NSEC3PARAM-record-type.patch Type: text/x-patch Size: 22741 bytes Desc: not available URL: From mbasti at redhat.com Fri Jun 20 13:23:19 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 15:23:19 +0200 Subject: [Freeipa-devel] [PATCHES 0072-0075] Add DLV record (Update DNSSEC attributes in LDAP schema) Message-ID: <1403270599.2336.17.camel@unused-4-145.brq.redhat.com> Patches attached Petr please review WebUI patch. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0072-DNSSEC-DLVRecord-type-added.patch Type: text/x-patch Size: 20632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0073-DNSSEC-Test-DLV-record.patch Type: text/x-patch Size: 2589 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0074-Digest-part-in-DLV-DS-records-allows-only-heaxadecim.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0075-DNSSEC-WebUI-add-DLV-record-type.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: From mbasti at redhat.com Fri Jun 20 13:28:08 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 15:28:08 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix incompatible DNS permission Message-ID: <1403270888.2336.19.camel@unused-4-145.brq.redhat.com> Patch attached. Ticket:https://fedorahosted.org/freeipa/ticket/4383 -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0076-Fix-incompatible-DNS-permission.patch Type: text/x-patch Size: 2439 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 20 13:30:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Jun 2014 15:30:03 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0063 Update DNSSEC attributes/record types In-Reply-To: <1403267712.2336.14.camel@unused-4-145.brq.redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> <1403195830.2295.22.camel@unused-4-145.brq.redhat.com> <1403267712.2336.14.camel@unused-4-145.brq.redhat.com> Message-ID: <53A4375B.5020607@redhat.com> On 20.6.2014 14:35, Martin Basti wrote: > On Thu, 2014-06-19 at 18:37 +0200, Martin Basti wrote: >> On Fri, 2014-06-13 at 09:55 +0200, Martin Basti wrote: >>> On Thu, 2014-06-12 at 16:20 +0200, Martin Basti wrote: >>>> On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: >>>>> On 9.6.2014 17:28, Martin Basti wrote: >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4328 >>>>>> >>>>>> Petr please make the WebUI patch review (0062) :-) >>>>>> >>>>>> Patches attached. >>>>>> >>>>> >>>>> Patch #0059: LGTM >>>>> >>>>> Patch #0060: >>>>> >>>>> 1. Please add `pattern_errmsg` to `salt` part of nsec3param. Otherwise >>>>> you get general "Text does not match field pattern" error message in Web UI. >>>>> >>>> I will add the message. >>>> >>>>> 2. Could be in one if: >>>>> + if nsec3params is not None: >>>>> + if len(nsec3params) > 1: >>>>> >>>>> Maybe I'm missing something. But why does the dns plugin code use >>>>> following all over the place: >>>>> >>>>> try: >>>>> nsec3params = rrattrs['nsec3paramrecord'] >>>>> except KeyError: >>>>> pass >>>>> else: >>>>> if nsec3params is not None: >>>>> >>>>> instead of: >>>>> >>>>> nsec3params = rrattrs.get('nsec3paramrecord') >>>>> if nsec3params is not None: >>>>> >>>>> btw you use both patterns in the patch. >>>> I will use shorten form, I wrote it in the same way as the other code in >>>> the block was written, that's why. >>>> >>>>> >>>>> Patch #0061: ACK >>>>> >>>>> >>>>> Patch #0062: >>>>> >>>>> 3. Why are there the idnafsdbrec1 variables? >>>>> >>>> It was replace for NSEC records, which are not supported anymore. >>>> Now I realize, there is wrong description, so the idnafsbrec1 variable >>>> is not needed. >>>> I will remove it. >>>> >>>>> 4. related to ^^: >>>>> ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing >>>>> whitespace after ',' >>>>> >>>>> >>>>> Patch #0063: LGTM >>>>> IDK if they work because I'm experiencing some weird issues with >>>>> xmlrpc_tests in general. >>>> I had troubles only with permission tests, but all DNS test worked fine for me. >>>> >>>> Thank you for review. >>>> >>> Updated patches attached. >>> >> >> Rebased patches attached > > Updated patch attached, fixed missing update permission > ACK -- Petr Vobornik From mbasti at redhat.com Fri Jun 20 13:32:17 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Jun 2014 15:32:17 +0200 Subject: [Freeipa-devel] [PATCH 0077] Add dnssecinlinesigning attribute to ACI Message-ID: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> Required patches: mbasti-0060, mbasti-0073 Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0077-Fix-add-dnssecinlinesigning-attribute-to-ACI.patch Type: text/x-patch Size: 12217 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 20 13:43:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Jun 2014 15:43:20 +0200 Subject: [Freeipa-devel] [PATCH] 0059-0063 Update DNSSEC attributes/record types In-Reply-To: <53A4375B.5020607@redhat.com> References: <1402327713.2279.14.camel@unused-4-145.brq.redhat.com> <53998C4A.1060804@redhat.com> <1402582814.2280.12.camel@unused-4-145.brq.redhat.com> <1402646145.2292.2.camel@unused-4-145.brq.redhat.com> <1403195830.2295.22.camel@unused-4-145.brq.redhat.com> <1403267712.2336.14.camel@unused-4-145.brq.redhat.com> <53A4375B.5020607@redhat.com> Message-ID: <53A43A78.7020509@redhat.com> On 20.6.2014 15:30, Petr Vobornik wrote: > On 20.6.2014 14:35, Martin Basti wrote: >> On Thu, 2014-06-19 at 18:37 +0200, Martin Basti wrote: >>> On Fri, 2014-06-13 at 09:55 +0200, Martin Basti wrote: >>>> On Thu, 2014-06-12 at 16:20 +0200, Martin Basti wrote: >>>>> On Thu, 2014-06-12 at 13:17 +0200, Petr Vobornik wrote: >>>>>> On 9.6.2014 17:28, Martin Basti wrote: >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/4328 >>>>>>> >>>>>>> Petr please make the WebUI patch review (0062) :-) >>>>>>> >>>>>>> Patches attached. >>>>>>> >>>>>> >>>>>> Patch #0059: LGTM >>>>>> >>>>>> Patch #0060: >>>>>> >>>>>> 1. Please add `pattern_errmsg` to `salt` part of nsec3param. >>>>>> Otherwise >>>>>> you get general "Text does not match field pattern" error message >>>>>> in Web UI. >>>>>> >>>>> I will add the message. >>>>> >>>>>> 2. Could be in one if: >>>>>> + if nsec3params is not None: >>>>>> + if len(nsec3params) > 1: >>>>>> >>>>>> Maybe I'm missing something. But why does the dns plugin code use >>>>>> following all over the place: >>>>>> >>>>>> try: >>>>>> nsec3params = rrattrs['nsec3paramrecord'] >>>>>> except KeyError: >>>>>> pass >>>>>> else: >>>>>> if nsec3params is not None: >>>>>> >>>>>> instead of: >>>>>> >>>>>> nsec3params = rrattrs.get('nsec3paramrecord') >>>>>> if nsec3params is not None: >>>>>> >>>>>> btw you use both patterns in the patch. >>>>> I will use shorten form, I wrote it in the same way as the other >>>>> code in >>>>> the block was written, that's why. >>>>> >>>>>> >>>>>> Patch #0061: ACK >>>>>> >>>>>> >>>>>> Patch #0062: >>>>>> >>>>>> 3. Why are there the idnafsdbrec1 variables? >>>>>> >>>>> It was replace for NSEC records, which are not supported anymore. >>>>> Now I realize, there is wrong description, so the idnafsbrec1 variable >>>>> is not needed. >>>>> I will remove it. >>>>> >>>>>> 4. related to ^^: >>>>>> ./ipatests/test_xmlrpc/test_dns_plugin.py:199:33: E231 missing >>>>>> whitespace after ',' >>>>>> >>>>>> >>>>>> Patch #0063: LGTM >>>>>> IDK if they work because I'm experiencing some weird issues with >>>>>> xmlrpc_tests in general. >>>>> I had troubles only with permission tests, but all DNS test worked >>>>> fine for me. >>>>> >>>>> Thank you for review. >>>>> >>>> Updated patches attached. >>>> >>> >>> Rebased patches attached >> >> Updated patch attached, fixed missing update permission >> > > ACK Pushed to master: * 48865aed5f15ae94db664c4cebed125ef8f223cc DNSSEC: remove unsuported records * 5b95be802c6aa12b9464813441f85eaee3e3e82b DNSSEC: added NSEC3PARAM record type * 4d90d3d572caedfd8813ccef0fe44551aed80d2b DNSSEC: webui update DNSSEC attributes * cbc64454b026993d3724c9640e6ec738f549fdcd Tests: remove unused records from tests * 4c88fdd9046c682c4b2cdce760e4c5440f2d41de Tests: tests for NSEC3PARAM records -- Petr Vobornik From mkosek at redhat.com Fri Jun 20 14:06:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 16:06:16 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring Message-ID: <53A43FD8.5010403@redhat.com> Hello all, I would like to discuss what should we do with the latest issue we found in SSSD-DS communication which is broken after the ACI refactoring. I was working with Ludwig, there is a problem in the way how deref plugin checks the access to the referenced entry. Instead of checking the target entry itself, Ludwig found out that the deref plugin checks a dummy entry created from the dereferenced DN, not the real entry. Details in DS ticket: https://fedorahosted.org/389/ticket/47821 Previously, we allowed read access globally so it worked fine. Now, when we have targeted ACIs using objectclass targetfilter, the access control goes wrong, deref plugin does not return all attributes and SSSD does not work (see 4389). Question is, what should we do in 4.0. We could have the DS team to fix the deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x replicas which would not have the fix. So we need to be cautious about this one. I see couple ways: 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This option is a bit clumsy. 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref calls. I tested it with Jakub's example call and it fixed this query: # ipa permission-add --subtree cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com --right={read,search,compare} --attrs={objectclass,memberof,managedby} --bindtype all deref_managedby # kinit -kt /etc/krb5.keytab # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com -E 'deref=managedBy:objectClass' ... dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, dc=eng,dc=brq,dc=redhat,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz # managedBy: ;;;;;;;;;;;fqdn=vm-086.idm .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= redhat,dc=com Jakub, what else would we need to allow? After this change, login/sudo seemed to work for me on F20. The ACIs would be removed when all our supported DS versions have the deref plugin fixed. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From jhrozek at redhat.com Fri Jun 20 14:24:39 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Jun 2014 16:24:39 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <53A43FD8.5010403@redhat.com> References: <53A43FD8.5010403@redhat.com> Message-ID: <20140620142439.GG9583@hendrix.brq.redhat.com> On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: > Hello all, > > I would like to discuss what should we do with the latest issue we found in > SSSD-DS communication which is broken after the ACI refactoring. It's not just SSSD-DS communication, any client, including ldapsearch currently fails. > > I was working with Ludwig, there is a problem in the way how deref plugin > checks the access to the referenced entry. Instead of checking the target entry > itself, Ludwig found out that the deref plugin checks a dummy entry created > from the dereferenced DN, not the real entry. Details in DS ticket: > https://fedorahosted.org/389/ticket/47821 > > Previously, we allowed read access globally so it worked fine. Now, when we > have targeted ACIs using objectclass targetfilter, the access control goes > wrong, deref plugin does not return all attributes and SSSD does not work (see > 4389). > > Question is, what should we do in 4.0. We could have the DS team to fix the > deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x > replicas which would not have the fix. So we need to be cautious about this one. Why? SSSD Simply uses a client control. See http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the details. > > I see couple ways: > 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as > minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This > option is a bit clumsy. The fact that this 'fix' seems to be backwards incompatible sounds strange to me. How exactly did you intend to fix the plugin? If the fix was about changing DS to check the target entry instead of some dummy entry, then I see no impact on the client. > > 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref > calls. I tested it with Jakub's example call and it fixed this query: > > # ipa permission-add --subtree > cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > --right={read,search,compare} --attrs={objectclass,memberof,managedby} > --bindtype all deref_managedby > # kinit -kt /etc/krb5.keytab > > # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b > fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > -E 'deref=managedBy:objectClass' > ... > dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, > dc=eng,dc=brq,dc=redhat,dc=com > control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ > G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG > RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt > vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl > cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc > GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz > # managedBy: ;; =nshost>;;; >;;; shhost>;;;fqdn=vm-086.idm > .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= > redhat,dc=com > > Jakub, what else would we need to allow? After this change, login/sudo seemed > to work for me on F20. Are you asking about the list of attributes we dereference or the list of attributes we read from the dereferenced entries? For IPA we only care about memberof, but keep in mind that attribute maps in SSSD are configurable. > > The ACIs would be removed when all our supported DS versions have the deref > plugin fixed. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. From lkrispen at redhat.com Fri Jun 20 14:34:01 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 20 Jun 2014 16:34:01 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <20140620142439.GG9583@hendrix.brq.redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> Message-ID: <53A44659.40601@redhat.com> On 06/20/2014 04:24 PM, Jakub Hrozek wrote: > On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: >> Hello all, >> >> I would like to discuss what should we do with the latest issue we found in >> SSSD-DS communication which is broken after the ACI refactoring. > It's not just SSSD-DS communication, any client, including ldapsearch > currently fails. > >> I was working with Ludwig, there is a problem in the way how deref plugin >> checks the access to the referenced entry. Instead of checking the target entry >> itself, Ludwig found out that the deref plugin checks a dummy entry created >> from the dereferenced DN, not the real entry. Details in DS ticket: >> https://fedorahosted.org/389/ticket/47821 >> >> Previously, we allowed read access globally so it worked fine. Now, when we >> have targeted ACIs using objectclass targetfilter, the access control goes >> wrong, deref plugin does not return all attributes and SSSD does not work (see >> 4389). >> >> Question is, what should we do in 4.0. We could have the DS team to fix the >> deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x >> replicas which would not have the fix. So we need to be cautious about this one. > Why? SSSD Simply uses a client control. See > http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the > details. > >> I see couple ways: >> 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as >> minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This >> option is a bit clumsy. > The fact that this 'fix' seems to be backwards incompatible sounds > strange to me. How exactly did you intend to fix the plugin? If the fix > was about changing DS to check the target entry instead of some dummy > entry, then I see no impact on the client. The DS fix will be in checking the target entry, but martins concern seem to be that this fix will not be automatically present in all deployments > >> 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref >> calls. I tested it with Jakub's example call and it fixed this query: >> >> # ipa permission-add --subtree >> cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> --right={read,search,compare} --attrs={objectclass,memberof,managedby} >> --bindtype all deref_managedby >> # kinit -kt /etc/krb5.keytab >> >> # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b >> fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> -E 'deref=managedBy:objectClass' >> ... >> dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, >> dc=eng,dc=brq,dc=redhat,dc=com >> control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ >> G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG >> RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt >> vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl >> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc >> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz >> # managedBy: ;;> =nshost>;;;> >;;;> shhost>;;;fqdn=vm-086.idm >> .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= >> redhat,dc=com >> >> Jakub, what else would we need to allow? After this change, login/sudo seemed >> to work for me on F20. > Are you asking about the list of attributes we dereference or the list > of attributes we read from the dereferenced entries? > > For IPA we only care about memberof, but keep in mind that attribute > maps in SSSD are configurable. > >> The ACIs would be removed when all our supported DS versions have the deref >> plugin fixed. >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Fri Jun 20 14:45:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 16:45:45 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <20140620142439.GG9583@hendrix.brq.redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> Message-ID: <53A44919.1020205@redhat.com> On 06/20/2014 04:24 PM, Jakub Hrozek wrote: > On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: >> Hello all, >> >> I would like to discuss what should we do with the latest issue we found in >> SSSD-DS communication which is broken after the ACI refactoring. > > It's not just SSSD-DS communication, any client, including ldapsearch > currently fails. Sure. >> I was working with Ludwig, there is a problem in the way how deref plugin >> checks the access to the referenced entry. Instead of checking the target entry >> itself, Ludwig found out that the deref plugin checks a dummy entry created >> from the dereferenced DN, not the real entry. Details in DS ticket: >> https://fedorahosted.org/389/ticket/47821 >> >> Previously, we allowed read access globally so it worked fine. Now, when we >> have targeted ACIs using objectclass targetfilter, the access control goes >> wrong, deref plugin does not return all attributes and SSSD does not work (see >> 4389). >> >> Question is, what should we do in 4.0. We could have the DS team to fix the >> deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x >> replicas which would not have the fix. So we need to be cautious about this one. > > Why? SSSD Simply uses a client control. See > http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the > details. Because this bug affects all client machines enrolled in FreeIPA. >> I see couple ways: >> 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as >> minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This >> option is a bit clumsy. > > The fact that this 'fix' seems to be backwards incompatible sounds > strange to me. How exactly did you intend to fix the plugin? If the fix > was about changing DS to check the target entry instead of some dummy > entry, then I see no impact on the client. There is no impact on clients connected to the "fixed DS". This is the scenario I am concerned about: User has RHEL/CentOS 6.x IPA server and wants to try the new nice and shiny FreeIPA 4.0. He installs the FreeIPA 4.0 replica (with fixed DS), the replica upgrades the ACIs to the new model. SSSD connected to FreeIPA 4.0 replica will work, SSSD connected to the old RHEL-6.x replica will not. >> 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref >> calls. I tested it with Jakub's example call and it fixed this query: >> >> # ipa permission-add --subtree >> cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> --right={read,search,compare} --attrs={objectclass,memberof,managedby} >> --bindtype all deref_managedby >> # kinit -kt /etc/krb5.keytab >> >> # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b >> fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> -E 'deref=managedBy:objectClass' >> ... >> dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, >> dc=eng,dc=brq,dc=redhat,dc=com >> control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ >> G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG >> RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt >> vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl >> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc >> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz >> # managedBy: ;;> =nshost>;;;> >;;;> shhost>;;;fqdn=vm-086.idm >> .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= >> redhat,dc=com >> >> Jakub, what else would we need to allow? After this change, login/sudo seemed >> to work for me on F20. > > Are you asking about the list of attributes we dereference or the list > of attributes we read from the dereferenced entries? Actually both, so that we know for what type of objects and what attributes we would need to allow access. > For IPA we only care about memberof, but keep in mind that attribute > maps in SSSD are configurable. Hm, makes the option 2) even more challenging... Martin From pvoborni at redhat.com Fri Jun 20 14:46:42 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Jun 2014 16:46:42 +0200 Subject: [Freeipa-devel] [PATCHES 0072-0075] Add DLV record (Update DNSSEC attributes in LDAP schema) In-Reply-To: <1403270599.2336.17.camel@unused-4-145.brq.redhat.com> References: <1403270599.2336.17.camel@unused-4-145.brq.redhat.com> Message-ID: <53A44952.7080205@redhat.com> On 20.6.2014 15:23, Martin Basti wrote: > Patches attached > > Petr please review WebUI patch. > Patch 72: ACK Patch 73: ACK Patch 74: ACK Patch 75: ACK pushed to master: * 7cdc4178b0fb0972a7aed3e0604a835fc45ac7a8 DNSSEC: DLVRecord type added * ee6e634c28b7261930c8cee556c8ebef9a01603e DNSSEC: Test: DLV record * 2229e89bbb2b89ad72e467de83f735b308a7bca1 Digest part in DLV/DS records allows only heaxadecimal characters * 0eef37908c580f4550618244e661594138f7b382 DNSSEC: WebUI add DLV record type -- Petr Vobornik From pviktori at redhat.com Fri Jun 20 14:49:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Jun 2014 16:49:41 +0200 Subject: [Freeipa-devel] [PATCH] 0593 Allow anonymous read access to virtual operation entries (Re: Virtual operation ACIs) In-Reply-To: <53A2D3D9.6000906@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> <53A2D3D9.6000906@redhat.com> Message-ID: <53A44A05.4060805@redhat.com> On 06/19/2014 02:13 PM, Martin Kosek wrote: > On 06/19/2014 12:52 PM, Petr Viktorin wrote: >> I'll address the other issues separately. >> >> On 06/18/2014 05:46 PM, Martin Kosek wrote: >>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: >>> No such virtual command" error triggered by "cert-show" command. >>> >>> We will need to add the permission "System: Read Virtual Operations" that Honza >>> is creating also to "Host Administrators" to fix that part. >> >> I'm not familiar with Honza's effort, but that seems right. >> I'm curious, why don't we just allow reading virtual operations by anybody? It >> seems to me they're the same in every IPA installation, what's there to hide? > > They are indeed the same. This is an old (very old) mean to check access when > ACI cannot be used. I admit it is a bit clumsy. > > I agree that we should indeed allow reading the list of virtual operations as > the list can be retrieved from our git anyway. The virtual operations do not > even show list of it's members as permissions hold it, so it really should not > leak any sensitive information. > >> Anyway, I poked around in how it works now: for cert-show you need write access >> to the objectClass of the "retrieve certificate" virt op entry. So that right >> you can actually remove the "ipaVirtualOperation" objectClass. >> Aand the new "Anonymous read access to containers" ACI has a >> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for a virt >> op can allow everyone see that virt op). >> Shouldn't we base the check on some other attribute instead? >> >> And curiously, for cert-find there is no virt op based access check. > > I think we should eventually invent something better than current virtual > operations. For now (4.0), we should do something simple and straightforward. > The simplest thing to do is stick to the old behavior, i.e.: > > 1) Remove the (!(objectclass=ipaVirtualOperation)) part of the filter (should > improve performance, right?) > 2) Remove the ipaVirtualOperation objectclass again from the virtual operations > as it would be useless after change 1) Patch attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0593-Allow-anonymous-read-access-to-virtual-operation-ent.patch Type: text/x-patch Size: 4344 bytes Desc: not available URL: From lkrispen at redhat.com Fri Jun 20 14:57:57 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 20 Jun 2014 16:57:57 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <53A44919.1020205@redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> <53A44919.1020205@redhat.com> Message-ID: <53A44BF5.7080808@redhat.com> On 06/20/2014 04:45 PM, Martin Kosek wrote: > On 06/20/2014 04:24 PM, Jakub Hrozek wrote: >> On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: >>> Hello all, >>> >>> I would like to discuss what should we do with the latest issue we found in >>> SSSD-DS communication which is broken after the ACI refactoring. >> It's not just SSSD-DS communication, any client, including ldapsearch >> currently fails. > Sure. > >>> I was working with Ludwig, there is a problem in the way how deref plugin >>> checks the access to the referenced entry. Instead of checking the target entry >>> itself, Ludwig found out that the deref plugin checks a dummy entry created >>> from the dereferenced DN, not the real entry. Details in DS ticket: >>> https://fedorahosted.org/389/ticket/47821 >>> >>> Previously, we allowed read access globally so it worked fine. Now, when we >>> have targeted ACIs using objectclass targetfilter, the access control goes >>> wrong, deref plugin does not return all attributes and SSSD does not work (see >>> 4389). >>> >>> Question is, what should we do in 4.0. We could have the DS team to fix the >>> deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x >>> replicas which would not have the fix. So we need to be cautious about this one. >> Why? SSSD Simply uses a client control. See >> http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the >> details. > Because this bug affects all client machines enrolled in FreeIPA. > >>> I see couple ways: >>> 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as >>> minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This >>> option is a bit clumsy. >> The fact that this 'fix' seems to be backwards incompatible sounds >> strange to me. How exactly did you intend to fix the plugin? If the fix >> was about changing DS to check the target entry instead of some dummy >> entry, then I see no impact on the client. > There is no impact on clients connected to the "fixed DS". This is the scenario > I am concerned about: > > User has RHEL/CentOS 6.x IPA server and wants to try the new nice and shiny > FreeIPA 4.0. He installs the FreeIPA 4.0 replica (with fixed DS), the replica > upgrades the ACIs to the new model. SSSD connected to FreeIPA 4.0 replica will > work, SSSD connected to the old RHEL-6.x replica will not. About the options, I think 1] is mandatory: fix DS and then, in a mixed environment, we could either request to either upgrade DS to a version including the fix or to add an aci the way you did. > >>> 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref >>> calls. I tested it with Jakub's example call and it fixed this query: >>> >>> # ipa permission-add --subtree >>> cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> --right={read,search,compare} --attrs={objectclass,memberof,managedby} >>> --bindtype all deref_managedby >>> # kinit -kt /etc/krb5.keytab >>> >>> # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b >>> fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> -E 'deref=managedBy:objectClass' >>> ... >>> dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, >>> dc=eng,dc=brq,dc=redhat,dc=com >>> control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ >>> G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG >>> RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt >>> vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl >>> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc >>> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz >>> # managedBy: ;;>> =nshost>;;;>> >;;;>> shhost>;;;fqdn=vm-086.idm >>> .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= >>> redhat,dc=com >>> >>> Jakub, what else would we need to allow? After this change, login/sudo seemed >>> to work for me on F20. >> Are you asking about the list of attributes we dereference or the list >> of attributes we read from the dereferenced entries? > Actually both, so that we know for what type of objects and what attributes we > would need to allow access. > >> For IPA we only care about memberof, but keep in mind that attribute >> maps in SSSD are configurable. > Hm, makes the option 2) even more challenging... > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From ssorce at redhat.com Fri Jun 20 14:56:47 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 10:56:47 -0400 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <53A44919.1020205@redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> <53A44919.1020205@redhat.com> Message-ID: <1403276207.12884.137.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 16:45 +0200, Martin Kosek wrote: > There is no impact on clients connected to the "fixed DS". This is the > scenario > I am concerned about: > > User has RHEL/CentOS 6.x IPA server and wants to try the new nice and > shiny FreeIPA 4.0. He installs the FreeIPA 4.0 replica (with fixed > DS), the replica upgrades the ACIs to the new model. SSSD connected to > FreeIPA 4.0 replica will work, SSSD connected to the old RHEL-6.x > replica will not. This is the only "issue", and I do not think we can/should jump through many hoops here. The best way IMO, is to fix DS in RHEL6, and make a release note that before migrating to FreeIPA 4.0, you must make sure all replicas have an updated DS version (list versions for all major distros we know about). I do not think we should add any special detection code in 4.0, if the admin fails to update DS on an older replica he has 2 choices: 1. update DS 2. decommission the old replica Simo. From alee at redhat.com Fri Jun 20 14:32:27 2014 From: alee at redhat.com (Ade Lee) Date: Fri, 20 Jun 2014 22:32:27 +0800 Subject: [Freeipa-devel] Design for new top level DN functionality in Dogtag Message-ID: <1403274747.4156.28.camel@localhost.localdomain> Design at: http://pki.fedoraproject.org/wiki/Top-Level_Tree This is a feature to change the tree structure of the Dogtag internal database so that a new top level baseDN is available. This will simplify the replication topology by allowing one to replicate all subsystems in a tomcat instance with a single replication agreement, instead of needing a separate replication agreement for each subsystem. This is a feature that I plan to start implementing very shortly for Dogtag 10.2 -- ie. within the next couple of weeks. There are implications both for IPA (and how Dogtag is deployed within IPA) as well as implications for Dogtag. Please take a look and provide comments. Thanks, Ade From pviktori at redhat.com Fri Jun 20 15:06:49 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Jun 2014 17:06:49 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed Message-ID: <53A44E09.8010300@redhat.com> All these should be independent, except for conflicts in ACI.txt that are easily solved by running makeaci. -- Petr? I have replaced myself by a moderately long Python script. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0594-Convert-Automount-default-permissions-to-managed.patch Type: text/x-patch Size: 16387 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0595-Convert-Group-default-permissions-to-managed.patch Type: text/x-patch Size: 11829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0596-Convert-HBAC-Rule-default-permissions-to-managed.patch Type: text/x-patch Size: 9471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0597-Convert-HBAC-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 6264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0598-Convert-HBAC-Service-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0599-Convert-Hostgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 9289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0600-Convert-Netgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 9170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0601-Convert-the-Modify-privilege-membership-permission-t.patch Type: text/x-patch Size: 4621 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0602-Convert-Role-default-permissions-to-managed.patch Type: text/x-patch Size: 8667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0603-Convert-SELinux-User-Map-default-permissions-to-mana.patch Type: text/x-patch Size: 7774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0604-Convert-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 9851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0605-Convert-Sudo-Command-default-permissions-to-managed.patch Type: text/x-patch Size: 8615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0606-Convert-Sudo-Command-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6719 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 20 15:18:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Jun 2014 17:18:05 +0200 Subject: [Freeipa-devel] [PATCH] 659-666 Support of password reset with OTP In-Reply-To: <5398577C.8090605@redhat.com> References: <5398577C.8090605@redhat.com> Message-ID: <53A450AD.9020908@redhat.com> On 11.6.2014 15:19, Petr Vobornik wrote: > Patch set contains both API/server and Web UI parts. > > [PATCH] 659 ldap2: add otp support to modify_password > [PATCH] 660 rpcserver: add otp support to change_password handler > [PATCH] 661 ipa-passwd: add OTP support > [PATCH] 662 webui: support password change with OTP in login screen > [PATCH] 663 webui: placeholder attribute support in textbox and textarea > [PATCH] 664 webui: add placeholders to login screen > [PATCH] 665 webui: rebase user password dialog on password dialog and > add otp support > [PATCH] 666 webui: support otp in reset_password.html > > https://fedorahosted.org/freeipa/ticket/4262 attaching rebased patches (mainly because of VERSION conflict) -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0663-1-webui-placeholder-attribute-support-in-textbox-and-t.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0664-1-webui-add-placeholders-to-login-screen.patch Type: text/x-patch Size: 4753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0665-1-webui-rebase-user-password-dialog-on-password-dialog.patch Type: text/x-patch Size: 12482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0666-1-webui-support-otp-in-reset_password.html.patch Type: text/x-patch Size: 3033 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0659-1-ldap2-add-otp-support-to-modify_password.patch Type: text/x-patch Size: 1496 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0660-1-rpcserver-add-otp-support-to-change_password-handler.patch Type: text/x-patch Size: 2608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0661-1-ipa-passwd-add-OTP-support.patch Type: text/x-patch Size: 2697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0662-1-webui-support-password-change-with-OTP-in-login-scre.patch Type: text/x-patch Size: 6041 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jun 20 15:46:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 11:46:59 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403209851.6477.25.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> Message-ID: <1403279219.4808.1.camel@ipa.example.com> On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: > This command behaves almost exactly like otptoken-add except: > 1. The new token data is written directly to a YubiKey > 2. The vendor/model/serial fields are populated from the YubiKey > > === NOTE === > 1. This patch depends on the new Fedora package: python-yubico. If you > would like to help with the package review, please assign yourself here: > https://bugzilla.redhat.com/show_bug.cgi?id=1111334 New version of the patch. This one works (yay!). 1. Because of the dependency on python-yubico, is this feature something we want in core FreeIPA? As a subpackage? Separate project altogether? The only dependency for python-yubico is pyusb. 2. Should the "import yubico" statement be inside of the otptoken_add_yubikey.forward() method to reduce server dependencies? 3. This code currently emits a warning from the call to otptoken-add: WARNING: API Version number was not sent, forward compatibility not guaranteed. Assuming server's API version, 2.89 How do I fix this? 4. I am not sure why I have to delete the summary and value keys from the return dictionary. It would be nice to display this summary message just like otptoken-add. 5. Am I doing the ipatoken(vendor|model|serial) options correctly? These aren't user settable, but we need to pass them from the yubikey (client-side) to the server. 6. I'm not sure my use of assert or ValueError are correct. What should I do here? 7. Considering that this is just a specialized invocation of otptoken-add, can't we do this all on the client-side? This is why I had originally used frontend.Local rather than frontend.Command. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058.1-Add-the-otptoken-add-yubikey-command.patch Type: text/x-patch Size: 5707 bytes Desc: not available URL: From jhrozek at redhat.com Fri Jun 20 15:51:05 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Jun 2014 17:51:05 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <53A44919.1020205@redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> <53A44919.1020205@redhat.com> Message-ID: <20140620155105.GH9583@hendrix.brq.redhat.com> On Fri, Jun 20, 2014 at 04:45:45PM +0200, Martin Kosek wrote: > On 06/20/2014 04:24 PM, Jakub Hrozek wrote: > > On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: > >> Hello all, > >> > >> I would like to discuss what should we do with the latest issue we found in > >> SSSD-DS communication which is broken after the ACI refactoring. > > > > It's not just SSSD-DS communication, any client, including ldapsearch > > currently fails. > > Sure. > > >> I was working with Ludwig, there is a problem in the way how deref plugin > >> checks the access to the referenced entry. Instead of checking the target entry > >> itself, Ludwig found out that the deref plugin checks a dummy entry created > >> from the dereferenced DN, not the real entry. Details in DS ticket: > >> https://fedorahosted.org/389/ticket/47821 > >> > >> Previously, we allowed read access globally so it worked fine. Now, when we > >> have targeted ACIs using objectclass targetfilter, the access control goes > >> wrong, deref plugin does not return all attributes and SSSD does not work (see > >> 4389). > >> > >> Question is, what should we do in 4.0. We could have the DS team to fix the > >> deref plugin, but this would break SSSD connected to old RHEL/CentOs 6.x > >> replicas which would not have the fix. So we need to be cautious about this one. > > > > Why? SSSD Simply uses a client control. See > > http://tools.ietf.org/html/draft-masarati-ldap-deref-00 for all the > > details. > > Because this bug affects all client machines enrolled in FreeIPA. > > >> I see couple ways: > >> 1) Fix DS deref plugin in F20 and next RHEL 6.x and specify the RHEL-6.x as > >> minimal version of FreeIPA/DS required when replicating with FreeIPA 4.0. This > >> option is a bit clumsy. > > > > The fact that this 'fix' seems to be backwards incompatible sounds > > strange to me. How exactly did you intend to fix the plugin? If the fix > > was about changing DS to check the target entry instead of some dummy > > entry, then I see no impact on the client. > > There is no impact on clients connected to the "fixed DS". This is the scenario > I am concerned about: > > User has RHEL/CentOS 6.x IPA server and wants to try the new nice and shiny > FreeIPA 4.0. He installs the FreeIPA 4.0 replica (with fixed DS), the replica > upgrades the ACIs to the new model. SSSD connected to FreeIPA 4.0 replica will > work, SSSD connected to the old RHEL-6.x replica will not. Ah, I didn't realize the bug could propagate to released versions via replicas, sorry. > > >> 2) Add temporary ACIs allowing access to attributes that SSSD needs for deref > >> calls. I tested it with Jakub's example call and it fixed this query: > >> > >> # ipa permission-add --subtree > >> cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > >> --right={read,search,compare} --attrs={objectclass,memberof,managedby} > >> --bindtype all deref_managedby > >> # kinit -kt /etc/krb5.keytab > >> > >> # ldapsearch -Y GSSAPI -h vm-236.idm.lab.eng.brq.redhat.com -b > >> fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > >> -E 'deref=managedBy:objectClass' > >> ... > >> dn: fqdn=vm-086.idm.lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab, > >> dc=eng,dc=brq,dc=redhat,dc=com > >> control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEgMIQAAAEaBAltYW5hZ2VkQnkEaGZxZ > >> G49dm0tMDg2LmlkbS5sYWIuYm9zLnJlZGhhdC5jb20sY249Y29tcHV0ZXJzLGNuPWFjY291bnRzLG > >> RjPWlkbSxkYz1sYWIsZGM9ZW5nLGRjPWJycSxkYz1yZWRoYXQsZGM9Y29toIQAAACfMIQAAACZBAt > >> vYmplY3RDbGFzczGEAAAAhgQJaXBhb2JqZWN0BA1pZWVlODAyZGV2aWNlBAZuc2hvc3QECmlwYXNl > >> cnZpY2UEB3BraXVzZXIEB2lwYWhvc3QEDGtyYnByaW5jaXBhbAQPa3JicHJpbmNpcGFsYXV4BAppc > >> GFzc2hob3N0BAN0b3AEFGlwYVNzaEdyb3VwT2ZQdWJLZXlz > >> # managedBy: ;; >> =nshost>;;; >> >;;; >> shhost>;;;fqdn=vm-086.idm > >> .lab.bos.redhat.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc= > >> redhat,dc=com > >> > >> Jakub, what else would we need to allow? After this change, login/sudo seemed > >> to work for me on F20. > > > > Are you asking about the list of attributes we dereference or the list > > of attributes we read from the dereferenced entries? > > Actually both, so that we know for what type of objects and what attributes we > would need to allow access. I think we should just make a note to self to allow users to fix the ACIs manually should they run into the problem while being unable to upgrade for whatever reason. So we only seem to dereference member and memberof. We dereference either user groups to get users, host groups to get hosts. For hosts we are interested about these attributes: "ipa_host_object_class" "ipa_host_name" "ipa_host_fqdn" "ipa_host_serverhostname" "ipa_host_member_of" "ipa_host_ssh_public_key" "ipa_host_uuid" For users and groups, the list is longer and can be found here: https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ipa/ipa_opts.h#n166 Look for ipa_user_map and ipa_group_map. But in general I agree with Simo that we shouldn't spend too much time on this when the DS is fixed. > > > For IPA we only care about memberof, but keep in mind that attribute > > maps in SSSD are configurable. > > Hm, makes the option 2) even more challenging... > But because the ACIs would only be applied on IPA servers, I think we can limit ourselves to the IPA schema only for the workaround. From npmccallum at redhat.com Fri Jun 20 15:56:42 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 11:56:42 -0400 Subject: [Freeipa-devel] [PATCH] [IMPORTANT] Make otptoken use os.urandom() for random data In-Reply-To: <1403196215.12884.111.camel@willson.usersys.redhat.com> References: <1403195786.6477.22.camel@ipa.example.com> <1403196215.12884.111.camel@willson.usersys.redhat.com> Message-ID: <1403279802.4808.2.camel@ipa.example.com> On Thu, 2014-06-19 at 12:43 -0400, Simo Sorce wrote: > On Thu, 2014-06-19 at 12:36 -0400, Nathaniel McCallum wrote: > > This also fixes an error where the default value was not respecting > > the KEY_LENGTH variable. > > > > (NOTE: the os.urandom() change should not change the security properties > > of the existing code. However, the failure of the previous code to > > respect KEY_LENGTH causes us to violate the RFC.) > > LGTM! > I do prefer using os.urandom() directly, as random.SystemRandom uses it > under the hood anyway. Is that an ACK? Because we need to merge a fix of some kind soon. Nathaniel From ssorce at redhat.com Fri Jun 20 15:59:10 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 11:59:10 -0400 Subject: [Freeipa-devel] [PATCH] [IMPORTANT] Make otptoken use os.urandom() for random data In-Reply-To: <1403279802.4808.2.camel@ipa.example.com> References: <1403195786.6477.22.camel@ipa.example.com> <1403196215.12884.111.camel@willson.usersys.redhat.com> <1403279802.4808.2.camel@ipa.example.com> Message-ID: <1403279950.12884.142.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 11:56 -0400, Nathaniel McCallum wrote: > On Thu, 2014-06-19 at 12:43 -0400, Simo Sorce wrote: > > On Thu, 2014-06-19 at 12:36 -0400, Nathaniel McCallum wrote: > > > This also fixes an error where the default value was not respecting > > > the KEY_LENGTH variable. > > > > > > (NOTE: the os.urandom() change should not change the security properties > > > of the existing code. However, the failure of the previous code to > > > respect KEY_LENGTH causes us to violate the RFC.) > > > > LGTM! > > I do prefer using os.urandom() directly, as random.SystemRandom uses it > > under the hood anyway. > > Is that an ACK? Because we need to merge a fix of some kind soon. If someone can actually test it I would prefer, as I did not, and I am not sure I will find the time today, that's why I did not give a full ACK. Simo. From edewata at redhat.com Fri Jun 20 16:18:57 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 20 Jun 2014 11:18:57 -0500 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <53A173CB.3060203@redhat.com> References: <538473E0.6070702@redhat.com> <5399C659.30109@redhat.com> <53A173CB.3060203@redhat.com> Message-ID: <53A45EF1.6080209@redhat.com> On 6/18/2014 6:11 AM, Petr Vobornik wrote: >> 1. As discussed on IRC, the plugin is causing an error due to missing >> extend.js. This needs to be fixed. > > Fixed >> 4. I agree that the facet shouldn't define the hash. The hash should be >> part of the plugin declaration. > > Ideally, facet should be router agnostic. We need a mechanism of mapping > facet's state to hash and vice versa. > > Originally I did not want to do it now because it requires bigger > refactoring of a router. > > While I was designing it, I ended up with a patch - attached. > > It's a replacement for original patch #649. Patch #651 and example > plugin are updated accordingly. > > Basically I refactored router's `navigate_to_*`, `_create_*_hash` and > `*_route_handler` methods into separate classes which are registered and > mapped to facets. All in navigation.routing module. > > Btw, can you think of some better name(s)/placement for the module? ACK. Some comments below, but I think they can be addressed later. 1. I'm not sure if we really need a HashCreator. Ideally the router should map a hash to a page. Links to another page can be hardcoded too (and substitute the parameters). 2. Ideally there should be no entity-specific navigation code. All routing should be handled in a generic way. This probably depends on the entity-facet separation that we discussed previously. So routes like this: /e/:entity/:facet/:pkeys/*args should be replaced by individual routes for each entity: /user/:facet/:pkeys/*args /group/:facet/:pkeys/*args Probably the entities should be written like plugins. 3. If we fix #1 and #2, is the "routing" module still necessary? The "routing" object probably should have been a "router", but are you concerned about conflicting with Dojo's router and the existing Router module? 4. The args/query in the navigation paths should be separated by a more standard delimiter "?" instead of "//". For example: /ipa/ui/#/e/user/search//filter=test should be replaced with: /ipa/ui/#/e/user/search?filter=test -- Endi S. Dewata From pspacek at redhat.com Fri Jun 20 18:04:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 Jun 2014 20:04:04 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <5399B7F5.1040306@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> Message-ID: <53A47794.6060704@redhat.com> On 12.6.2014 16:23, Petr Spacek wrote: > On 30.4.2014 18:19, Petr Spacek wrote: >> following text summarizes schema & DIT layout for DNSSEC key storage in LDAP. > > I have added object classes and default values for attributes I consider > important. This is final proposal for implementation. Please review it ASAP. > >> This is subset of full PKCS#11 schema [0]. It stores bare keys with few >> metadata attributes when necessary. >> >> The intention is to make transition to full PKCS#11-in-LDAP schema [0] as easy >> as possible. This transition should happen in next minor version of FreeIPA. >> >> In theory, the transition should be just adding few object classes to existing >> objects and populating few new metadata attributes. Related object classes are >> marked below with "(in long-term)". >> >> Please comment on it soon. We want to implement it ASAP :-) >> >> >> DNSSEC key >> ========== >> - Asymmetric >> - Private key is stored in LDAP as encrypted PKCS#8 blob >> - Public key is published in LDAP >> - Encrypted with symmetric "DNSSEC master key" (see below) >> - Private key - represented as LDAP object with object classes: >> ipaEPrivateKey [1] # encrypted data >> ipaWrappedKey [2] # pointer to master key, outside scope of pure PKCS#11 >> ipk11PrivateKey [3] (in long-term) # PKCS#11 metadata >> - Public key - represented as LDAP object with object classes: >> ipaPublicKey [1] # public key data >> ipk11PublicKey [3] (in long-term) # PKCS#11 metadata >> >> >> Master key >> ========== >> - Symmetric >> - Stored in LDAP as encrypted blob >> - Encrypted with asymmetric "replica key" (see below) >> - 1 replica = 1 blob, n replicas = n blobs encrypted with different keys >> - A replica uses it's own key for master key en/decryption >> - Represented as LDAP object with object classes: >> ipaESecretKey [1] >> ipk11SecretKey [3] (in long-term) >> >> Replica key >> =========== >> - Asymmetric >> - Private key is stored on replica's disk only >> - Public key for all replicas is stored in LDAP >> - Represented as LDAP object with object classes: >> ipaPublicKey [1] >> ipk11PublicKey [3] (in long-term) >> >> >> DIT layout >> ========== >> DNSSEC key material >> ------------------- >> - Container: cn=keys, cn=sec, cn=dns, dc=example >> - Private and public keys are stored as separate objects to accommodate all >> PKCS#11 metadata. >> - We need to decide about object naming: >> - One obvious option for RDN is to use uniqueID but I don't like it. It is >> hard to read for humans. >> - Other option is to use uniqueID+PKCS#11 label or other attributes to make >> it more readable. Can we use multi-valued RDN? If not, why? What are technical >> reasons behind it? >> >> It is question if we like: >> nsUniqID = 0b0b7e53-957d11e3-a51dc0e5-9a05ecda >> nsUniqID = 8ae4190d-957a11e3-a51dc0e5-9a05ecda >> more than: >> ipk11Label=meaningful_label+ipk11Private=TRUE >> ipk11Label=meaningful_label+ipk11Private=FALSE > > dn: ipk11Label=zone1_keyid123_public, cn=keys, cn=sec, cn=dns, dc=example > objectClass: ipk11Object > objectClass: ipk11PublicKey > objectClass: ipaPublicKeyObject > ipk11UniqueId: > ipk11Label: zone1_keyid123_public > ipk11Wrap: FALSE > ipk11Verify: TRUE > ipaPublicKey: > > dn: ipk11Label=zone1_keyid123_private, cn=keys, cn=sec, cn=dns, dc=example > objectClass: ipk11Object > objectClass: ipk11PrivateKey > objectClass: ipaPrivateKeyObject > objectClass: ipaWrappedKey > ipaWrappingKey:ipk11Label=dnssec_m1,cn=master,cn=keys,cn=sec,cn=dns,dc=example > ipk11Sign: TRUE > ipk11Decrypt: FALSE > ipk11Unwrap: FALSE > ipaPrivateKey: > > >> DNSSEC key metadata >> ------------------- >> - Container (per-zone): cn=keys, idnsname=example.net, cn=dns >> - Key metadata can be linked to key material via DN or ipk11Id. >> - This allows key sharing between zones. >> (DNSSEC-metadata will be specified later. That is not important for key >> storage.) > This will be sorted out in separate thread. > >> >> Replica public keys >> ------------------- >> - Container: cn=DNS,cn=,cn=masters,cn=ipa,cn=etc,dc=example >> - or it's child object like cn=wrappingKey > > - Please note that private part of this key is stored on disk. > > dn: ipk11Label=wrapkey_replica1,cn=DNS,cn= FQDN>,cn=masters,cn=ipa,cn=etc,dc=example > objectClass: ipk11Object > objectClass: ipk11PublicKey > objectClass: ipaPublicKeyObject > ipk11UniqueId: > ipk11Label: wrapkey_replica1 > ipk11Wrap: TRUE > ipk11Encrypt: FALSE > ipk11Verify: FALSE > ipaPublicKey: > >> Master keys >> ----------- >> - Container: cn=master, cn=keys, cn=sec, cn=dns, dc=example >> - Single key = single object. >> - We can use ipk11Label or ipk11Id for naming: >> ipk11Label=dnssecMaster1, ipk11Label=dnssecMaster2, etc. > > dn: ipk11Label=dnssec_m1, cn=master, cn=keys, cn=sec, cn=dns, dc=example > objectClass: ipk11Object > objectClass: ipk11SecretKey > objectClass: ipaWrappedKey > objectClass: ipaSecretKeyObject > ipk11UniqueId: > ipk11Label: dnssec_m1 > ipk11Wrap: TRUE > ipk11UnWrap: TRUE > ipk11Encrypt: FALSE > ipk11Decrypt: FALSE > ipk11Sign: FALSE > ipk11Verify: FALSE > ipaWrappingAlgo: > ipaSecretKeyWrappedData: > ipaSecretKeyWrappedData: > ipaWrappingKey: > ipaWrappingKey: Today it turned out that storing private and public keys in separate LDAP objects is probably not necessary and makes things harder to manage. (Risk of dangling objects, you have to do LDAP searches all the time, keep PKCS#11 metadata in sync between objects etc.) In fact, IPA clients should never see none of those key objects. Clients will work only with DNSKEY records in DNS tree but never with raw keys. Raw keys are useless to clients anyway because raw keys do not contain necessary DNSSEC metadata (as one key can be, in theory, shared among multiple DNS zones etc). Honza proposed to combine ipk11PublicKey and ipk11PrivateKey objects under single object which makes perfect sense because almost all PKCS#11 data can be shared (label, ID, PKCS#11 timestamps etc.). If I'm not wrong, the only problem is that two of PKCS#11 attributes can have different value for public and private part of the key. The complete list of "shared" attributes between the ipk11PublicKey and ipk11PrivateKey object classes contains 13 attributes. However, it doesn't make sense to store different values for most of them. I looked into it a bit. It seems that following attributes are shared but they should always have the same value (i.e. they probably have to be copied from one object to the other if we decide to stay with separate objects): ipk11AllowedMechanisms ipk11Destroyable ipk11KeyGenMechanism ipk11KeyType ipk11Label ipk11Id ipk11Local ipk11Modifiable ipk11StartDate ipk11EndDate ipk11Derive Remaining two attributes are common for all PKCS#11 objects but it makes sense to have different values for private/public keys (or certificates): ipk11Private ipk11Copyable Honza proposed to use LDAP subtypes for those "conflicting" attributes and store attribute values for private/public key/certificate in sub-types with names defined by object class (without ipk11 prefix). Example: Public key is represented as ipk11PublicKey object class, private key as ipk11PrivateKey. All-on-one-object can look like: dn: ipk11Label=zone2-ksk,cn=keys,cn=sec,cn=dns,dc=ipa,dc=example objectClass: ipaWrappedKey objectClass: ipaPrivateKeyObject objectClass: ipaPublicKeyObject objectClass: ipk11Object objectClass: ipk11PrivateKey objectClass: top objectClass: ipk11StorageObject objectClass: ipk11Key objectClass: ipk11PublicKey ipaWrappingKey: ipk11Label=dnssec-master-2,cn=master,cn=keys,cn=sec,cn=dns,d c=ipa,dc=example ipk11UniqueId: UUID4 ipaPrivateKey:: ZW5jcnlwdGVkIGJsb2I= ipaPublicKey:: cHVibGljIGtleSBkYXRh ipk11Decrypt: FALSE ipk11Encrypt: FALSE ipk11Label: zone2-allinone ipk11Private;privatekey: TRUE ipk11Private;publickey: FALSE ipk11Sign: TRUE ipk11Unwrap: FALSE ipk11Verify: TRUE ipk11Wrap: FALSE What do you think about it? Given that there are only two really conflicting attributes, I think it is easier to deal with sub-types for these two and do not add complexity and overhead connected with managing multiple objects, pairing of them, error handling if write to one object succeeds but fails for the other etc. If we later discover that this "object sharing" limits us we can migrate to fully separate objects. This part of the tree will be visible only to IPA servers so no client changes will be required. I'm attaching LDIF with example how DIT for DNSSEC keys will look like. It contains one example with key pair split between two objects and one example with keypair stored in one object. In also contains DNSSEC metadata objects, master key and replica key. Have a nice weekend! Petr^2 Spacek >> Work flows >> ========== >> Read DNSSEC private key >> ----------------------- >> 1) read DNSSEC private key from LDAP >> 2) ipaWrappedKey objectClass is present - key is encrypted >> 3) read master key denoted by ipaWrappingKey attribute in DNSSEC key object >> 4) use local replica key to decrypt master key >> 5) use decrypted master key to decrypt DNSSEC private key >> >> Add DNSSEC private key >> ---------------------- >> 1) use local replica key to decrypt master key >> 2) encrypt DNSSEC private key with master key >> 3) add ipaWrappingKey attribute pointing to master key >> 4) store encrypted blob in a new LDAP object >> >> Add a replica >> ------------- >> ipa-replica-prepare: >> 1) generate a new replica-key pair for the new replica >> 2) store key pair to replica-file (don't scream yet :-) >> 4) add public key for the new replica to LDAP >> 3) fetch master key from LDAP >> 4) encrypt master key with new replica public key >> 5) store resulting master key blob to LDAP >> ipa-replica-install: >> 6) generate a new replica-key pair (!) >> 7) store new public key to LDAP >> 8) remove old public key (from replica-file) from LDAP >> 9) fetch master key >> 10) decrypt master key using old private key (from replica-file) >> 11) encrypt master key using new private key (generated locally) >> 12) replace old master key blob in LDAP with new blob (from step 11) >> >> Delete a replica >> ---------------- >> This is the tricky part. New master key has to be generated on some other >> replica. What should we do if the ipa-replica-manage command was run on >> deleted replica? >> >> I propose to split replica master key roll-over to two phases: >> Any machine in IPA domain (including to-be deleted replica): >> 1) Delete public key associated with replica from LDAP >> 2) Flip a bit in master key metadata and say "this key needs to be >> re-generated" >> (Maybe we can disable ipk11Wrap boolean to indicate that this key should >> not be used for key wrapping.) >> >> Remaining replicas: >> 3) Periodically check that master key is obsolete >> 4) Wait for (random period of time) to limit probability of collision >> 5) Check that master key is really obsolete and new one is not present >> 6) Generate a new master key >> 7) Encrypt new master key with all replica-public-keys stored in LDAP >> 8) Store new master key blobs to a new LDAP object >> (Conflicts are not a problem up to now because we are not deleting old >> key. In worst case, we will have multiple new master keys.) >> *What should we do now?* >> 9) ??? Re-encrypt all DNSSEC keys with a new master key? (What if we have >> write conflict now?) >> ??? Let old keys there and wait until key rotation mechanism replaces >> all old DNSSEC keys with new DNSSEC keys encrypted with a new master key (~ >> one year)? >> 10) Old master key can be deleted when no other object is referencing to it. >> >> >> Congratulations to people who reached this line and didn't skip anything :-) >> >> [0] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema >> [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 >> [2] >> http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#FreeIPA_specifics_-_key_wrapping >> >> >> [3] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Storage_objects -------------- next part -------------- A non-text attachment was scrubbed... Name: dnssec.ldif Type: text/x-ldif Size: 4543 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jun 20 18:05:38 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 14:05:38 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1402932870.22737.113.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> Message-ID: <1403287538.4808.5.camel@ipa.example.com> On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > Although the code is all done it would be nice to have a review of the > feature, to see if it has all been captured: > http://www.freeipa.org/page/V4/Keytab_Retrieval I'm a bit confused about the behavior of enctypes in the Request. "A list of enctypes is always necessary in input when a new keytab is requested. However the list is filtered though the allowable enctypes list and if nothing is left the operation is refused." +1. However, the generated keys should be the set of allowed enctypes, not the intersection between allowed and requested enctypes. This would permit the later requesting of enctypes that were allowed at the time of creation, but not requested. "If the getNew attribute is false, then the existing key is being requested. In this case password and enctypes MUST NOT be set." I don't get this. Shouldn't the return value of this request include only the intersection between allowed and requested enctypes? There is no point in responding with enctypes the client has not requested. And indeed, this provides extra data points to attack. Having this proposed behavior also means you can remove OPTIONAL from enctypes. So as it stands, enctypes currently controls what keys are generated. I would prefer that enctypes controls what keys are returned. Am I missing something? Nathaniel From simo at redhat.com Fri Jun 20 18:10:42 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 14:10:42 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403287538.4808.5.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> Message-ID: <1403287842.12884.157.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 14:05 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > Although the code is all done it would be nice to have a review of the > > feature, to see if it has all been captured: > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > I'm a bit confused about the behavior of enctypes in the Request. > > "A list of enctypes is always necessary in input when a new keytab is > requested. However the list is filtered though the allowable enctypes > list and if nothing is left the operation is refused." > > +1. However, the generated keys should be the set of allowed enctypes, > not the intersection between allowed and requested enctypes. This would > permit the later requesting of enctypes that were allowed at the time of > creation, but not requested. Which you absolutely do not want. If your service understands only RC4-HMAC and you provide it with AES keys then communication from a third party client will fail because the KDC will give that client an AES encrypted ticket that the service does not know how to decrypt. This is particularly important for old NFS Servers (like RHEL5) that understand only DES (sigh!) > "If the getNew attribute is false, then the existing key is being > requested. In this case password and enctypes MUST NOT be set." > > I don't get this. Shouldn't the return value of this request include > only the intersection between allowed and requested enctypes? Not when you are retrieving existing keys. Only when you are creating new keys. > There is no point in responding with enctypes the client has not requested. > And indeed, this provides extra data points to attack. ?? > Having this proposed behavior also means you can remove OPTIONAL from > enctypes. OPTIONAL is there because when you request existing keys it makes no sense to send a lit of enctypes, you get what the KDC has, the whole package, because you must be able to decrypt any ticket you get, getting a subset of keys would make no sense. > So as it stands, enctypes currently controls what keys are generated. I > would prefer that enctypes controls what keys are returned. Am I missing > something? I most definitely think you are :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jun 20 18:23:06 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 14:23:06 -0400 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <53A47794.6060704@redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> Message-ID: <1403288586.12884.161.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: > ipk11Private;privatekey: TRUE > ipk11Private;publickey: FALSE can these two ever hold a different value ? ie a privatekey be FALSE and a publickey be TRUE ? If not I suggest you do not add this attribute at all and assume their value ? (btw I forgot what's the point of that attribute) Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Jun 20 18:30:46 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 14:30:46 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403287842.12884.157.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> Message-ID: <1403289046.4808.7.camel@ipa.example.com> On Fri, 2014-06-20 at 14:10 -0400, Simo Sorce wrote: > On Fri, 2014-06-20 at 14:05 -0400, Nathaniel McCallum wrote: > > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > > Although the code is all done it would be nice to have a review of the > > > feature, to see if it has all been captured: > > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > I'm a bit confused about the behavior of enctypes in the Request. > > > > "A list of enctypes is always necessary in input when a new keytab is > > requested. However the list is filtered though the allowable enctypes > > list and if nothing is left the operation is refused." > > > > +1. However, the generated keys should be the set of allowed enctypes, > > not the intersection between allowed and requested enctypes. This would > > permit the later requesting of enctypes that were allowed at the time of > > creation, but not requested. > > Which you absolutely do not want. > If your service understands only RC4-HMAC and you provide it with AES > keys then communication from a third party client will fail because the > KDC will give that client an AES encrypted ticket that the service does > not know how to decrypt. > > This is particularly important for old NFS Servers (like RHEL5) that > understand only DES (sigh!) > > > "If the getNew attribute is false, then the existing key is being > > requested. In this case password and enctypes MUST NOT be set." > > > > I don't get this. Shouldn't the return value of this request include > > only the intersection between allowed and requested enctypes? > > Not when you are retrieving existing keys. Only when you are creating > new keys. > > > There is no point in responding with enctypes the client has not requested. > > And indeed, this provides extra data points to attack. > > ?? > > > Having this proposed behavior also means you can remove OPTIONAL from > > enctypes. > > OPTIONAL is there because when you request existing keys it makes no > sense to send a lit of enctypes, you get what the KDC has, the whole > package, because you must be able to decrypt any ticket you get, getting > a subset of keys would make no sense. > > > So as it stands, enctypes currently controls what keys are generated. I > > would prefer that enctypes controls what keys are returned. Am I missing > > something? > > I most definitely think you are :-) Ah, right. This boils down to the KDC not having any way to know what enctypes the destination principal supports. Thanks for clarifying that. In this case, the ASN.1 provided is confusing. I think something like this would be clearer and less error prone: KeytabGetMessage ::= CHOICE { fetch [0] Fetch, create [1] Create reply [2] Reply } Fetch ::= SEQUENCE { serviceIdentity [0] OCTET STRING } Create ::= SEQUENCE { serviceIdentity [0] OCTET STRING, enctypes [1] SEQUENCE OF Int16, password [2] OCTET STRING OPTIONAL } This would also, I think, result in a cleaner implementation where the type of operation is logically built into the decoding step. Nathaniel From simo at redhat.com Fri Jun 20 18:38:36 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 14:38:36 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403289046.4808.7.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> Message-ID: <1403289516.12884.165.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 14:30 -0400, Nathaniel McCallum wrote: > On Fri, 2014-06-20 at 14:10 -0400, Simo Sorce wrote: > > On Fri, 2014-06-20 at 14:05 -0400, Nathaniel McCallum wrote: > > > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > > > Although the code is all done it would be nice to have a review of the > > > > feature, to see if it has all been captured: > > > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > > > I'm a bit confused about the behavior of enctypes in the Request. > > > > > > "A list of enctypes is always necessary in input when a new keytab is > > > requested. However the list is filtered though the allowable enctypes > > > list and if nothing is left the operation is refused." > > > > > > +1. However, the generated keys should be the set of allowed enctypes, > > > not the intersection between allowed and requested enctypes. This would > > > permit the later requesting of enctypes that were allowed at the time of > > > creation, but not requested. > > > > Which you absolutely do not want. > > If your service understands only RC4-HMAC and you provide it with AES > > keys then communication from a third party client will fail because the > > KDC will give that client an AES encrypted ticket that the service does > > not know how to decrypt. > > > > This is particularly important for old NFS Servers (like RHEL5) that > > understand only DES (sigh!) > > > > > "If the getNew attribute is false, then the existing key is being > > > requested. In this case password and enctypes MUST NOT be set." > > > > > > I don't get this. Shouldn't the return value of this request include > > > only the intersection between allowed and requested enctypes? > > > > Not when you are retrieving existing keys. Only when you are creating > > new keys. > > > > > There is no point in responding with enctypes the client has not requested. > > > And indeed, this provides extra data points to attack. > > > > ?? > > > > > Having this proposed behavior also means you can remove OPTIONAL from > > > enctypes. > > > > OPTIONAL is there because when you request existing keys it makes no > > sense to send a lit of enctypes, you get what the KDC has, the whole > > package, because you must be able to decrypt any ticket you get, getting > > a subset of keys would make no sense. > > > > > So as it stands, enctypes currently controls what keys are generated. I > > > would prefer that enctypes controls what keys are returned. Am I missing > > > something? > > > > I most definitely think you are :-) > > Ah, right. This boils down to the KDC not having any way to know what > enctypes the destination principal supports. Thanks for clarifying that. > > In this case, the ASN.1 provided is confusing. I think something like > this would be clearer and less error prone: > > KeytabGetMessage ::= CHOICE { > fetch [0] Fetch, > create [1] Create > reply [2] Reply > } > > Fetch ::= SEQUENCE { > serviceIdentity [0] OCTET STRING > } > > Create ::= SEQUENCE { > serviceIdentity [0] OCTET STRING, > enctypes [1] SEQUENCE OF Int16, > password [2] OCTET STRING OPTIONAL > } > > This would also, I think, result in a cleaner implementation where the > type of operation is logically built into the decoding step. Well yes this looks better, but honestly, I think it is a bit late for this kind of feedback, given I have a working patchset, and asked months ago if people wanted to review the logical design. How strongly do you feel we absolutely need to change this and go through a new review cycle ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Fri Jun 20 18:47:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 14:47:35 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403289516.12884.165.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> Message-ID: <1403290055.4808.9.camel@ipa.example.com> On Fri, 2014-06-20 at 14:38 -0400, Simo Sorce wrote: > On Fri, 2014-06-20 at 14:30 -0400, Nathaniel McCallum wrote: > > On Fri, 2014-06-20 at 14:10 -0400, Simo Sorce wrote: > > > On Fri, 2014-06-20 at 14:05 -0400, Nathaniel McCallum wrote: > > > > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > > > > Although the code is all done it would be nice to have a review of the > > > > > feature, to see if it has all been captured: > > > > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > > > > > I'm a bit confused about the behavior of enctypes in the Request. > > > > > > > > "A list of enctypes is always necessary in input when a new keytab is > > > > requested. However the list is filtered though the allowable enctypes > > > > list and if nothing is left the operation is refused." > > > > > > > > +1. However, the generated keys should be the set of allowed enctypes, > > > > not the intersection between allowed and requested enctypes. This would > > > > permit the later requesting of enctypes that were allowed at the time of > > > > creation, but not requested. > > > > > > Which you absolutely do not want. > > > If your service understands only RC4-HMAC and you provide it with AES > > > keys then communication from a third party client will fail because the > > > KDC will give that client an AES encrypted ticket that the service does > > > not know how to decrypt. > > > > > > This is particularly important for old NFS Servers (like RHEL5) that > > > understand only DES (sigh!) > > > > > > > "If the getNew attribute is false, then the existing key is being > > > > requested. In this case password and enctypes MUST NOT be set." > > > > > > > > I don't get this. Shouldn't the return value of this request include > > > > only the intersection between allowed and requested enctypes? > > > > > > Not when you are retrieving existing keys. Only when you are creating > > > new keys. > > > > > > > There is no point in responding with enctypes the client has not requested. > > > > And indeed, this provides extra data points to attack. > > > > > > ?? > > > > > > > Having this proposed behavior also means you can remove OPTIONAL from > > > > enctypes. > > > > > > OPTIONAL is there because when you request existing keys it makes no > > > sense to send a lit of enctypes, you get what the KDC has, the whole > > > package, because you must be able to decrypt any ticket you get, getting > > > a subset of keys would make no sense. > > > > > > > So as it stands, enctypes currently controls what keys are generated. I > > > > would prefer that enctypes controls what keys are returned. Am I missing > > > > something? > > > > > > I most definitely think you are :-) > > > > Ah, right. This boils down to the KDC not having any way to know what > > enctypes the destination principal supports. Thanks for clarifying that. > > > > In this case, the ASN.1 provided is confusing. I think something like > > this would be clearer and less error prone: > > > > KeytabGetMessage ::= CHOICE { > > fetch [0] Fetch, > > create [1] Create > > reply [2] Reply > > } > > > > Fetch ::= SEQUENCE { > > serviceIdentity [0] OCTET STRING > > } > > > > Create ::= SEQUENCE { > > serviceIdentity [0] OCTET STRING, > > enctypes [1] SEQUENCE OF Int16, > > password [2] OCTET STRING OPTIONAL > > } > > > > This would also, I think, result in a cleaner implementation where the > > type of operation is logically built into the decoding step. > > Well yes this looks better, but honestly, I think it is a bit late for > this kind of feedback, given I have a working patchset, and asked months > ago if people wanted to review the logical design. You asked for a design review on Monday of this week. I am providing that review. Do you want it or not? > How strongly do you feel we absolutely need to change this and go > through a new review cycle ? This change would have very small impact on your patch set, but would be much clearer for the future consumers of this protocol. Code can be changed; protocols can't. I am finishing the design doc now and will move to your patch set shortly. I'd be happy to provide a quick code review for this change. Nathaniel From mkosek at redhat.com Fri Jun 20 19:12:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 21:12:31 +0200 Subject: [Freeipa-devel] #4389: DS deref broken after ACI refactoring In-Reply-To: <20140620155105.GH9583@hendrix.brq.redhat.com> References: <53A43FD8.5010403@redhat.com> <20140620142439.GG9583@hendrix.brq.redhat.com> <53A44919.1020205@redhat.com> <20140620155105.GH9583@hendrix.brq.redhat.com> Message-ID: <53A4879F.7060902@redhat.com> On 06/20/2014 05:51 PM, Jakub Hrozek wrote: > On Fri, Jun 20, 2014 at 04:45:45PM +0200, Martin Kosek wrote: >> On 06/20/2014 04:24 PM, Jakub Hrozek wrote: >>> On Fri, Jun 20, 2014 at 04:06:16PM +0200, Martin Kosek wrote: ... > I think we should just make a note to self to allow users to fix the > ACIs manually should they run into the problem while being unable to > upgrade for whatever reason. > > So we only seem to dereference member and memberof. We dereference either user > groups to get users, host groups to get hosts. For hosts we are > interested about these attributes: > "ipa_host_object_class" > "ipa_host_name" > "ipa_host_fqdn" > "ipa_host_serverhostname" > "ipa_host_member_of" > "ipa_host_ssh_public_key" > "ipa_host_uuid" > > For users and groups, the list is longer and can be found here: > https://git.fedorahosted.org/cgit/sssd.git/tree/src/providers/ipa/ipa_opts.h#n166 > > Look for ipa_user_map and ipa_group_map. > > But in general I agree with Simo that we shouldn't spend too much time > on this when the DS is fixed. Ok, makes sense. > > >> >>> For IPA we only care about memberof, but keep in mind that attribute >>> maps in SSSD are configurable. >> >> Hm, makes the option 2) even more challenging... >> > > But because the ACIs would only be applied on IPA servers, I think we > can limit ourselves to the IPA schema only for the workaround. Thanks all for responses. It seems that plan is clear: 1) Prepare a fix for DS deref access control issue (https://fedorahosted.org/389/ticket/47821). Ludwig, could you now please start working on this one? It takes precedence before 4.1 or 4.2 work you were working on. 2) Backport the fix to supported platforms along with other ACI fixes that Ludwig already found - Fedora 19 (?), Fedora 20, next RHEL-6.x. 3) 4.0 release note will contain a warning about the minimal DS version of the replicas. We will have a workaround ready based on the data that Jakub provided in case someone hit the issue and cannot update to fixes DS version. Martin From mkosek at redhat.com Fri Jun 20 19:28:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 21:28:38 +0200 Subject: [Freeipa-devel] [PATCH] [IMPORTANT] Make otptoken use os.urandom() for random data In-Reply-To: <1403279950.12884.142.camel@willson.usersys.redhat.com> References: <1403195786.6477.22.camel@ipa.example.com> <1403196215.12884.111.camel@willson.usersys.redhat.com> <1403279802.4808.2.camel@ipa.example.com> <1403279950.12884.142.camel@willson.usersys.redhat.com> Message-ID: <53A48B66.7020708@redhat.com> On 06/20/2014 05:59 PM, Simo Sorce wrote: > On Fri, 2014-06-20 at 11:56 -0400, Nathaniel McCallum wrote: >> On Thu, 2014-06-19 at 12:43 -0400, Simo Sorce wrote: >>> On Thu, 2014-06-19 at 12:36 -0400, Nathaniel McCallum wrote: >>>> This also fixes an error where the default value was not respecting >>>> the KEY_LENGTH variable. >>>> >>>> (NOTE: the os.urandom() change should not change the security properties >>>> of the existing code. However, the failure of the previous code to >>>> respect KEY_LENGTH causes us to violate the RFC.) >>> >>> LGTM! >>> I do prefer using os.urandom() directly, as random.SystemRandom uses it >>> under the hood anyway. >> >> Is that an ACK? Because we need to merge a fix of some kind soon. > > If someone can actually test it I would prefer, as I did not, and I am > not sure I will find the time today, that's why I did not give a full > ACK. > > Simo. > > I tested at least the lambda and it worked as expected. Pushed to master: cf8f143e9823c06ed069c6a031c0c4aa80288840 Martin From npmccallum at redhat.com Fri Jun 20 19:50:23 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 15:50:23 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1402932870.22737.113.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> Message-ID: <1403293823.4808.11.camel@ipa.example.com> On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > Although the code is all done it would be nice to have a review of the > feature, to see if it has all been captured: > http://www.freeipa.org/page/V4/Keytab_Retrieval Is there any need to create different permissions for password generation vs random generation? I think the answer is no because the only risk is a substandard password which you can control with password policy. I just wanted to bring it up. Nathaniel From npmccallum at redhat.com Fri Jun 20 19:55:24 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 15:55:24 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403293823.4808.11.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403293823.4808.11.camel@ipa.example.com> Message-ID: <1403294124.4808.13.camel@ipa.example.com> On Fri, 2014-06-20 at 15:50 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > Although the code is all done it would be nice to have a review of the > > feature, to see if it has all been captured: > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > Is there any need to create different permissions for password > generation vs random generation? I think the answer is no because the > only risk is a substandard password which you can control with password > policy. I just wanted to bring it up. Other than this question and the ASN.1 issue, I am very happy with the design. The new permissions ACI style looks very useful. Nathaniel From simo at redhat.com Fri Jun 20 20:00:36 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 16:00:36 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403293823.4808.11.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403293823.4808.11.camel@ipa.example.com> Message-ID: <1403294436.19579.0.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 15:50 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > Although the code is all done it would be nice to have a review of the > > feature, to see if it has all been captured: > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > Is there any need to create different permissions for password > generation vs random generation? I think the answer is no because the > only risk is a substandard password which you can control with password > policy. I just wanted to bring it up. Indeed we do not differentiate, password policy is what you want to use if you want minimum guarantees, for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Jun 20 20:05:45 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 16:05:45 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403290055.4808.9.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> Message-ID: <1403294745.19579.2.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > This change would have very small impact on your patch set, but would > be > much clearer for the future consumers of this protocol. Code can be > changed; protocols can't. Ok this new patchset implements the requested change. Initial testing seem to indicate it all works as expected. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 36281 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5298 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 32156 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 16608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2017 bytes Desc: not available URL: From simo at redhat.com Fri Jun 20 20:08:53 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 16:08:53 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403294124.4808.13.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403293823.4808.11.camel@ipa.example.com> <1403294124.4808.13.camel@ipa.example.com> Message-ID: <1403294933.19579.3.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 15:55 -0400, Nathaniel McCallum wrote: > On Fri, 2014-06-20 at 15:50 -0400, Nathaniel McCallum wrote: > > On Mon, 2014-06-16 at 11:34 -0400, Simo Sorce wrote: > > > Although the code is all done it would be nice to have a review of the > > > feature, to see if it has all been captured: > > > http://www.freeipa.org/page/V4/Keytab_Retrieval > > > > Is there any need to create different permissions for password > > generation vs random generation? I think the answer is no because the > > only risk is a substandard password which you can control with password > > policy. I just wanted to bring it up. > > Other than this question and the ASN.1 issue, I am very happy with the > design. The new permissions ACI style looks very useful. Thanks, I changed the page to reflect the new controls too. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Jun 20 20:19:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 22:19:33 +0200 Subject: [Freeipa-devel] [PATCH] 0593 Allow anonymous read access to virtual operation entries (Re: Virtual operation ACIs) In-Reply-To: <53A44A05.4060805@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2C104.8070102@redhat.com> <53A2D3D9.6000906@redhat.com> <53A44A05.4060805@redhat.com> Message-ID: <53A49755.1060500@redhat.com> On 06/20/2014 04:49 PM, Petr Viktorin wrote: > On 06/19/2014 02:13 PM, Martin Kosek wrote: >> On 06/19/2014 12:52 PM, Petr Viktorin wrote: >>> I'll address the other issues separately. >>> >>> On 06/18/2014 05:46 PM, Martin Kosek wrote: >>>> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient >>>> access: >>>> No such virtual command" error triggered by "cert-show" command. >>>> >>>> We will need to add the permission "System: Read Virtual Operations" that >>>> Honza >>>> is creating also to "Host Administrators" to fix that part. >>> >>> I'm not familiar with Honza's effort, but that seems right. >>> I'm curious, why don't we just allow reading virtual operations by anybody? It >>> seems to me they're the same in every IPA installation, what's there to hide? >> >> They are indeed the same. This is an old (very old) mean to check access when >> ACI cannot be used. I admit it is a bit clumsy. >> >> I agree that we should indeed allow reading the list of virtual operations as >> the list can be retrieved from our git anyway. The virtual operations do not >> even show list of it's members as permissions hold it, so it really should not >> leak any sensitive information. >> >>> Anyway, I poked around in how it works now: for cert-show you need write access >>> to the objectClass of the "retrieve certificate" virt op entry. So that right >>> you can actually remove the "ipaVirtualOperation" objectClass. >>> Aand the new "Anonymous read access to containers" ACI has a >>> (!(objectclass=ipaVirtualOperation)) filter, so any user privileged for a virt >>> op can allow everyone see that virt op). >>> Shouldn't we base the check on some other attribute instead? >>> >>> And curiously, for cert-find there is no virt op based access check. >> >> I think we should eventually invent something better than current virtual >> operations. For now (4.0), we should do something simple and straightforward. >> The simplest thing to do is stick to the old behavior, i.e.: >> >> 1) Remove the (!(objectclass=ipaVirtualOperation)) part of the filter (should >> improve performance, right?) >> 2) Remove the ipaVirtualOperation objectclass again from the virtual operations >> as it would be useless after change 1) > > Patch attached. Yup, works fine. This will remove all the pain we had with hidden virtual operations. ACK. Pushed to master: f486d23ad67a7337c7633e4216c5a0b0374002fc Martin From mkosek at redhat.com Fri Jun 20 20:35:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 22:35:51 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed In-Reply-To: <53A2CC5D.9000708@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2CC5D.9000708@redhat.com> Message-ID: <53A49B27.1010307@redhat.com> On 06/19/2014 01:41 PM, Petr Viktorin wrote: > On 06/18/2014 05:46 PM, Martin Kosek wrote: >> On 06/11/2014 06:39 PM, Petr Viktorin wrote: >>> Patch 0578 does the conversion >>> >>> Patch 0579 fixes https://fedorahosted.org/freeipa/ticket/4252 and provides >>> permissions needed for automatic enrollment (from >>> http://projects.theforeman.org/projects/foreman/wiki/IPASmartProxyUser) >> >> 1) Inconsistent casing in permission names: >> >> System: Add Hosts >> System: Add krbPrincipalName to a host >> System: Enroll a host >> System: Manage Host SSH Public Keys >> System: Manage host keytab >> System: Modify Hosts >> System: Remove Hosts > > Fixed > >> 2) This ACI does not look right, missing enrolledby: >> >> + 'System: Enroll a host': { >> + 'ipapermright': {'write'}, >> + 'ipapermdefaultattr': {'objectclass'}, >> >> When I fixed 2) via permission-mod, client enrollment with user with "Host >> Administrators" privilege worked fine. > > Added > >> 3) I hit one issue when I open the Web UI host tab, I get "Insufficient access: >> No such virtual command" error triggered by "cert-show" command. > > Virtual operations seem to be quite a can of worms. > I've sent a separate reply for these. > >> We will need to add the permission "System: Read Virtual Operations" that Honza >> is creating also to "Host Administrators" to fix that part. >> >> >> 4) I ran unit tests and few missing attributes: >> - update hosts ACI should get "macaddress" attribute > > Added > >> 5) I hit one nasty issue when running the unit tests (when my master stopped >> working as host account was deleted) - host_is_master function in baseldap no >> longer works as we hid cn=masters from regular users: >> >> def host_is_master(ldap, fqdn): >> """ >> Check to see if this host is a master. >> >> Raises an exception if a master, otherwise returns nothing. >> """ >> master_dn = DN(('cn', fqdn), ('cn', 'masters'), ('cn', 'ipa'), ('cn', >> 'etc'), api. env.basedn) >> try: >> ldap.get_entry(master_dn, ['objectclass']) >> raise errors.ValidationError(name='hostname', error=_('An IPA master >> host cannot be deleted or disabled')) >> except errors.NotFound: >> # Good, not a master >> return >> >> This means, that host-del on a master machine or service-del on master service >> happily passes. >> >> We need to make sure this functionality is still working after the permission >> refactoring. Should we reconsider the cn=masters tree and allow authenticated >> users see the list of IPA servers (without digging into any other detail like >> services) then? > > Nasty indeed, thanks for the catch! > > Sent as patch 0590, since it's a different issue than converting the host > permissions. Everything worked as expected, I tested both enrollments with privileged user and setting the OTP/class. I have just one request (you will not like this) - before pushing please also fix casing for the new host permissions to match others: + 'System: Manage host certificates': { + 'System: Manage host enrollment password': { When this is fixed (and ACI.txt properly updated), it is an ACK. Martin From npmccallum at redhat.com Fri Jun 20 20:50:59 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Jun 2014 16:50:59 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403294745.19579.2.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> Message-ID: <1403297459.4808.15.camel@ipa.example.com> On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote: > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > > This change would have very small impact on your patch set, but would > > be > > much clearer for the future consumers of this protocol. Code can be > > changed; protocols can't. > > Ok this new patchset implements the requested change. > Initial testing seem to indicate it all works as expected. 0001: Line 555 has very wrong indentation. Other than that, I have looked over 0001 and 0002 very closely and built and tested them. Everything works. So conditional (indent fix) ACK on both of these. I don't see any reason to avoid merging these as soon as the indent fix is completed. It should substantially reduce your differential from master. In the new ASN.1, "Newkeys" has the wrong capitalization. This affects patches 0003 and 0005. I think patch 0003 may still have a permissions problem. For instance, this works for me with no error: $ ipa user-find --whoami -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1569600000 GID: 1569600000 Account disabled: False Password: True Kerberos keys available: True ---------------------------- Number of entries returned 1 ---------------------------- $ ipa-getkeytab -s ipa.example.com -p foo/ipa.example.com -r -k bar Keytab successfully retrieved and stored in: bar Is that really correct behavior or did I screw something up? I thought we had restricted the admin user from reading keys without changing them... Nathaniel From mkosek at redhat.com Fri Jun 20 21:17:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 20 Jun 2014 23:17:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A44E09.8010300@redhat.com> References: <53A44E09.8010300@redhat.com> Message-ID: <53A4A4E9.9070304@redhat.com> On 06/20/2014 05:06 PM, Petr Viktorin wrote: > All these should be independent, except for conflicts in ACI.txt that are > easily solved by running makeaci. Umh, now the fun begins as I see :) There will probably need to be some rebase, it clashed with some other ACI patches in my tree (namely Hosts which I acked). 594: we miss permissions for Automount Locations. Permissions for keys&maps look ok. 595: "System: Modify Group Membership" is probably waiting for the group objectclass fix - the filter is different. Otherwise it looks ok. 596-598: HBAC is ok 599: hostgroup is OK 600: there must have been some DS problem on my side as my regular user could not see any netgroup 601: privileges - we miss CRUD ACIs 602: roles were ok 603: ok I got this far today, the rest will need to wait for the next week. Thanks, Martin From simo at redhat.com Fri Jun 20 23:55:59 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Jun 2014 19:55:59 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403297459.4808.15.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> Message-ID: <1403308559.19579.5.camel@willson.usersys.redhat.com> On Fri, 2014-06-20 at 16:50 -0400, Nathaniel McCallum wrote: > On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote: > > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > > > This change would have very small impact on your patch set, but would > > > be > > > much clearer for the future consumers of this protocol. Code can be > > > changed; protocols can't. > > > > Ok this new patchset implements the requested change. > > Initial testing seem to indicate it all works as expected. > > 0001: Line 555 has very wrong indentation. > > Other than that, I have looked over 0001 and 0002 very closely and built > and tested them. Everything works. So conditional (indent fix) ACK on > both of these. I don't see any reason to avoid merging these as soon as > the indent fix is completed. It should substantially reduce your > differential from master. > > In the new ASN.1, "Newkeys" has the wrong capitalization. This affects > patches 0003 and 0005. > > I think patch 0003 may still have a permissions problem. For instance, > this works for me with no error: > > $ ipa user-find --whoami > -------------- > 1 user matched > -------------- > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1569600000 > GID: 1569600000 > Account disabled: False > Password: True > Kerberos keys available: True > ---------------------------- > Number of entries returned 1 > ---------------------------- > > $ ipa-getkeytab -s ipa.example.com -p foo/ipa.example.com -r -k bar > Keytab successfully retrieved and stored in: bar > > Is that really correct behavior or did I screw something up? I thought > we had restricted the admin user from reading keys without changing > them... Can you check if ipaProtectedOperation is in the aci attribute in the base tree object ? It should be there as excluded, and that should cause admin to not be able to retrieve keytabs. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Jun 23 07:29:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Jun 2014 10:29:39 +0300 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403279219.4808.1.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> Message-ID: <20140623072939.GV7233@redhat.com> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: >> This command behaves almost exactly like otptoken-add except: >> 1. The new token data is written directly to a YubiKey >> 2. The vendor/model/serial fields are populated from the YubiKey >> >> === NOTE === >> 1. This patch depends on the new Fedora package: python-yubico. If you >> would like to help with the package review, please assign yourself here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > >New version of the patch. This one works (yay!). > >1. Because of the dependency on python-yubico, is this feature something >we want in core FreeIPA? As a subpackage? Separate project altogether? >The only dependency for python-yubico is pyusb. I'd prefer to have it integrated but have a separate dummy subpackage that pulls in all required dependencies, like, freeipa-tools-yubico. Instead of failing when 'ipa otptoken-add-yubikey' is called, please wrap the python-yubico import into a code that allows reporting a message back to the user advising to install the package. Who is a supposed user for this command? IPA command line interface isn't usually available on enrolled machines even though underlying Python modules are all there. Are we talking about admins or just users? >2. Should the "import yubico" statement be inside of the >otptoken_add_yubikey.forward() method to reduce server dependencies? Here is how we do it in ipalibs/plugins/trust.py: ==================================================================== try: import pysss_murmur #pylint: disable=F0401 _murmur_installed = True except Exception, e: _murmur_installed = False try: import pysss_nss_idmap #pylint: disable=F0401 _nss_idmap_installed = True except Exception, e: _nss_idmap_installed = False if api.env.in_server and api.env.context in ['lite', 'server']: try: import ipaserver.dcerpc #pylint: disable=F0401 _bindings_installed = True except ImportError: _bindings_installed = False ==================================================================== and then in the actual code we do if not _bindings_installed: raise errors.NotFound( name=_('AD Trust setup'), reason=_( 'Cannot perform join operation without Samba 4 support ' 'installed. Make sure you have installed server-trust-ad ' 'sub-package of IPA' ) ) >3. This code currently emits a warning from the call to otptoken-add: >WARNING: API Version number was not sent, forward compatibility not >guaranteed. Assuming server's API version, 2.89 > >How do I fix this? Do not filter 'version' field in options in execute(). >4. I am not sure why I have to delete the summary and value keys from >the return dictionary. It would be nice to display this summary message >just like otptoken-add. > >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These >aren't user settable, but we need to pass them from the yubikey >(client-side) to the server. > >6. I'm not sure my use of assert or ValueError are correct. What should >I do here? > >7. Considering that this is just a specialized invocation of >otptoken-add, can't we do this all on the client-side? This is why I had >originally used frontend.Local rather than frontend.Command. You don't need to implement execute then, only forward, where you'll forward your call to the server under otptoken_add name. Typically in #forward we call super's forward but that is because we in Command.forward() we simply forward the command to the remote backend, using the self.name. In your case we shouldn't really have a separate command on the server under the same name, so you'll need to avoid calling So, it should look like this: def forward(self, *args, **kw): perform yubikey initialization filter out kw and args, if needed return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) See service_show implementation for an example. -- / Alexander Bokovoy From mkosek at redhat.com Mon Jun 23 07:42:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 09:42:15 +0200 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <20140623072939.GV7233@redhat.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> Message-ID: <53A7DA57.1030301@redhat.com> On 06/23/2014 09:29 AM, Alexander Bokovoy wrote: > On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >> On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: >>> This command behaves almost exactly like otptoken-add except: >>> 1. The new token data is written directly to a YubiKey >>> 2. The vendor/model/serial fields are populated from the YubiKey >>> >>> === NOTE === >>> 1. This patch depends on the new Fedora package: python-yubico. If you >>> would like to help with the package review, please assign yourself here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 >> >> New version of the patch. This one works (yay!). >> >> 1. Because of the dependency on python-yubico, is this feature something >> we want in core FreeIPA? As a subpackage? Separate project altogether? >> The only dependency for python-yubico is pyusb. > I'd prefer to have it integrated but have a separate dummy subpackage > that pulls in all required dependencies, like, freeipa-tools-yubico. Instead of > failing when 'ipa otptoken-add-yubikey' is called, please wrap the > python-yubico import into a code that allows reporting a message back to > the user advising to install the package. +1. For 4.0, I would just fail cleanly and keep functioning if python-yubico is not configured, just like in Alexander's trust example. For 4.2, we plan to introduce subpackages (https://fedorahosted.org/freeipa/ticket/4058). This is the right time and place to introduce something like "freeipa-server-otp" which would contain the files and requirements for OTP. It would also give is time to get it to standard Fedora repositories if we want this functionality by default. Martin From pviktori at redhat.com Mon Jun 23 08:00:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 10:00:34 +0200 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <20140623072939.GV7233@redhat.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> Message-ID: <53A7DEA2.90405@redhat.com> On 06/23/2014 09:29 AM, Alexander Bokovoy wrote: > On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >> 3. This code currently emits a warning from the call to otptoken-add: >> WARNING: API Version number was not sent, forward compatibility not >> guaranteed. Assuming server's API version, 2.89 >> >> How do I fix this? > Do not filter 'version' field in options in execute(). Please hardcode the API version instead of reusing it. This will be important when otptoken_add_yubikey is put in a separate package. i.e.: + answer = self.api.Command.otptoken_add(*args, + type=u'hotp', + ipatokenotpalgorithm=u'sha1', + ipatokenhotpcounter=0, + version='2.89', + **options) This way even if otptoken_add changes in the future, the fixed version string will trigger behavior compatible with what otptoken_add_yubikey expects now. -- Petr? From mkosek at redhat.com Mon Jun 23 08:01:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 10:01:12 +0200 Subject: [Freeipa-devel] [PATCHES] 0591-0593 Change group permission object filter In-Reply-To: <53A42598.7020507@redhat.com> References: <53997BA0.50608@redhat.com> <53997BC5.6000901@redhat.com> <53A42598.7020507@redhat.com> Message-ID: <53A7DEC8.1080707@redhat.com> On 06/20/2014 02:14 PM, Petr Viktorin wrote: > My patch 0580 was wrong; non-POSIX groups obviously lack the posixgroup > objectclass. Actually the only objectclasses that all groups share are top and > ipaobject. > > This makes permission plugin & updater join multiple > permission_filter_objectclasses filters with OR, and changes the --type group > filter to (|(objectclass=ipausergroup)(objectclass=posixgroup)). > > The first patch has some unrelated test fixes. This looks as the right thing to do, thanks. Access to group was restored, group type also worked fine. I found just one typo in 593 - "Retreive". When you fix this, it's an ACK. Martin From mkosek at redhat.com Mon Jun 23 08:07:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 10:07:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A4A4E9.9070304@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> Message-ID: <53A7E03C.7020101@redhat.com> On 06/20/2014 11:17 PM, Martin Kosek wrote: > On 06/20/2014 05:06 PM, Petr Viktorin wrote: >> All these should be independent, except for conflicts in ACI.txt that are >> easily solved by running makeaci. > > Umh, now the fun begins as I see :) There will probably need to be some rebase, > it clashed with some other ACI patches in my tree (namely Hosts which I acked). > > 594: we miss permissions for Automount Locations. Permissions for keys&maps > look ok. > > 595: "System: Modify Group Membership" is probably waiting for the group > objectclass fix - the filter is different. Otherwise it looks ok. > > 596-598: HBAC is ok > > 599: hostgroup is OK > > 600: there must have been some DS problem on my side as my regular user could > not see any netgroup > > 601: privileges - we miss CRUD ACIs > > 602: roles were ok > > 603: ok > > I got this far today, the rest will need to wait for the next week. 604: ok, I was able to create a service, get a keytab 605: Should we case the permissions as "Sudo Command instead of "Sudo command"? 606: we also miss Modify Sudo Command permission so that people can modify description. Otherwise ok. Martin From mkosek at redhat.com Mon Jun 23 08:32:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 10:32:19 +0200 Subject: [Freeipa-devel] freeipa and Debian multiarch triplet In-Reply-To: <53A29CBA.3020505@ubuntu.com> References: <53A29CBA.3020505@ubuntu.com> Message-ID: <53A7E613.5050901@redhat.com> On 06/19/2014 10:18 AM, Timo Aaltonen wrote: > > Hi > > While porting the client code for current master I noticed that there > are some hardcodings to use /usr/lib{,64} paths for various things. This > is problematic for Debian and it's derivatives, since we use "proper > multiarch(tm)" which means paths like > /usr/lib/{i386-linux-gnu,x86_64-linux-gnu} and other GNU triplets. I'd > need to force freeipa to build only on these two archs by setting FOO = > /usr/lib/i386-linux-gnu and FOO_64 = /usr/lib/x86_64-linux-gnu. > > Ideas for solving it cleanly so that at least freeipa-client would be > possible to build on other archs too? For the server at least 389 needs > updates too, since it hardcodes paths the same way. Apparently there were not many ideas on this topic. In case you have some idea how we could fix the ipaplatform package so that is serves you (or other platform consumers) better we are still open to changes - 4.0 is not released yet. Thanks, Martin From pviktori at redhat.com Mon Jun 23 08:55:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 10:55:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0591-0593 Change group permission object filter In-Reply-To: <53A7DEC8.1080707@redhat.com> References: <53997BA0.50608@redhat.com> <53997BC5.6000901@redhat.com> <53A42598.7020507@redhat.com> <53A7DEC8.1080707@redhat.com> Message-ID: <53A7EB77.3090608@redhat.com> On 06/23/2014 10:01 AM, Martin Kosek wrote: > On 06/20/2014 02:14 PM, Petr Viktorin wrote: >> My patch 0580 was wrong; non-POSIX groups obviously lack the posixgroup >> objectclass. Actually the only objectclasses that all groups share are top and >> ipaobject. >> >> This makes permission plugin & updater join multiple >> permission_filter_objectclasses filters with OR, and changes the --type group >> filter to (|(objectclass=ipausergroup)(objectclass=posixgroup)). >> >> The first patch has some unrelated test fixes. > > This looks as the right thing to do, thanks. Access to group was restored, > group type also worked fine. > > I found just one typo in 593 - "Retreive". When you fix this, it's an ACK. Thanks for the review! Typo fixed; pushed to master: ac8539bd344f2309f74efc6b42bddb3a925ff20f -- Petr? From pviktori at redhat.com Mon Jun 23 10:45:19 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 12:45:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0578-0579 Convert Host default permissions to managed In-Reply-To: <53A49B27.1010307@redhat.com> References: <5398864C.9020708@redhat.com> <53A1B45D.9020609@redhat.com> <53A2CC5D.9000708@redhat.com> <53A49B27.1010307@redhat.com> Message-ID: <53A8053F.7050109@redhat.com> On 06/20/2014 10:35 PM, Martin Kosek wrote: [...] > > Everything worked as expected, I tested both enrollments with privileged > user and setting the OTP/class. > > I have just one request (you will not like this) - before pushing please > also fix casing for the new host permissions to match others: > > + 'System: Manage host certificates': { > + 'System: Manage host enrollment password': { > > When this is fixed (and ACI.txt properly updated), it is an ACK. Oh the joys of rebasing. Fixed capitalization, pushed to master: 14e2eb9171c2cebff8efefac824edbe7dce1734c -- Petr? From mkosek at redhat.com Mon Jun 23 11:01:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 13:01:25 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53A18173.6060903@redhat.com> References: <52A0817E.2080002@redhat.com> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> <539EE99C.5010909@redhat.com> <539EFA64.3020005@redhat.com> <53A18173.6060903@redhat.com> Message-ID: <53A80905.1060706@redhat.com> On 06/18/2014 02:09 PM, Jan Cholasta wrote: ... >>>> 3) I am thinking why do we need to introduce all the ASN parsing? I am talking >>>> about _decode_krb5principalname and others. If we do not use the result >>>> anywhere, why should we include this part at all? >>> >>> To work around shortcomings of NSS/python-nss. In particular, >>> _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. >>> This is necessary because certmonger puts such SANs in certificate requests it >>> generates. >> >> I know, but we do not use the values besides DNS SAN type, right? I was just >> afraid that a decode error in a decoding of an unused SAN type would cause the >> entire CSR processing to crash. > > If we do not allow principal name SANs, requests from certmonger will fail. If > we allow them, but ignore them, you could request a certificate for an > arbitrary unrelated principal. Thus, the only thing we can do is allow them and > validate them, which is what the patch does and why decoding KRB5PrincipalName > is necessary. True, we need to make sure the principal type SANs match. ack on the intent. >>>> 4) I get crash in the certmonger request: >>>> >>>> ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>> test2.example.com >>>> -E mkosek at redhat.com >>>> >>>> # ipa-getcert list -i test-san-1 >>>> Number of certificates and requests being tracked: 8. >>>> Request ID 'test-san-1': >>>> status: CA_UNREACHABLE >>>> ca-error: Server failed request, will retry: -504 (HTTP response code is >>>> 500, >>>> not 200). >>>> stuck: yes >>>> >>>> >>>> HTTPD traceback >>>> [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote ... >>>> PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: >>>> _GeneralName() >>> >>> What version of certmonger are you using? >> >> Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access >> to my VM atm). Is this a bug in certmonger? > > No, it's bug in my code. Fixed. Works. > Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was > hitting with patch 234. > > Updated patches attached. > Thanks. Functionally, the patch looks ok to me, we are close to final ack. Just couple more minor changes need to happen: 1) We decided to drop ipaVirtualOperation concept in the end and allow people reading this list. This implies following changes: 234 - drop ipaVirtualOperation from cn=request certificate with subjectaltname,cn=virtual operations,cn=etc,$SUFFIX 300 - drop the entire patch (sorry) 2) I would like to have more confidence that no unauthorized SAN extension gets in. I know we have the + for name_type, name in subjectaltname: + if name_type not in (pkcs10.SAN_DNSNAME, loop, but I would also like to add "else" path to the SAN type validation loop, in case somebody just expands the part above, but forgot to also add validation. I want us to be explicit in this case: + for name_type, name in subjectaltname: + if name_type == pkcs10.SAN_DNSNAME: ... + elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, + pkcs10.SAN_OTHERNAME_UPN): ... > else: > raise errors.ACIError(info=_( > "Unauthorized subject alt name '%s'.") % name) When this is fixed, we should be done. Thanks, Martin From tbabej at redhat.com Mon Jun 23 11:41:59 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 23 Jun 2014 13:41:59 +0200 Subject: [Freeipa-devel] [PATCH 0232] trusts: Allow reading ipaNTSecurityIdentifier in user and Message-ID: <53A81287.1060402@redhat.com> Hi, this fixes initial findings of trust-after-aci-refactoring investigation. Consider this effort still WIP (not this patch though). https://fedorahosted.org/freeipa/ticket/4385 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0232-trusts-Allow-reading-ipaNTSecurityIdentifier-in-user.patch Type: text/x-patch Size: 5191 bytes Desc: not available URL: From rick at openfortress.nl Mon Jun 23 11:50:04 2014 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 23 Jun 2014 13:50:04 +0200 Subject: [Freeipa-devel] SoftHSMv2: key extraction (originally to OpenDNSSEC-user) References: <7D684B2E-A358-45BC-92A7-6456C91D5C30@openfortress.nl> Message-ID: <026DE9D2-0D33-40E7-B4CB-32E64F1182DD@openfortress.nl> Hi Petr, I have to be bold I fear? > You can read about the basic idea here: > https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html You are proposing to drag around the private keys between pieces of software, in a format encrypted to an externally generated, symmetric master key that is known to multiple pieces of infrastructure. That ranks as? functional thinking, but rather poor security practice. > (Discussion continues in next months, I'm sorry for mailman inability to create direct links across months.) Quickly browsing through the responses, there has only been discussion about directory formatting issues, but there are no security-minded responses. > Any comments on it are more than welcome! To be honest, I am shocked ? this is a *very* weak design from a security perspective. What you are doing undermines the concept of PKCS #11 completely, and it is *much* weaker than a SoftHSM-based implementation. The thing is, even with SoftHSM you have good control over where your private key material is copied to; think non-swappable memory, think avoidance of static bits burning into DRAM cells through ion displacement; I don?t know how far SoftHSMv2 goes, but at least it is in a position to care. The PKCS #11 API is the way to access private keys through using them, and anything that comes out of a signing operation is safe to publish. An HSM strongly limits the places where the (wrapped) private key is stored temporarily or for a long time, while you are proposing to drag the private key material through all sorts of functional / technical / networking tools, a lot of which has not been vetted for security like an HSM is. SoftHSMv2, is designed by knowledgeable cryptographers and should be considered a superb manner of key management relative to your own coding, unless you and all coders in the wrapped-private-key path also happen to be such knowledgeable cryptographers. The use of a master key, which I presume is used to decode the private key, is an even clearer misuse of PKCS #11; not only are you not using its private key encapsulation, you are even decrypting it outside of any HSM (?professional key management?) engine. You are effectively reducing PKCS #11 to a software library, indeed pretty much like an OpenSSL library that loads private keys into the rich / complex / dangerous functionality of an application, decrypts them for use in what may or may not be rock-solid signing code. You are basically saying that you don?t want or need PKCS #11 and that you would rather not have to deal with it at all, because it is obstructing you and its security model is not of interest to you.This means that your users wil not be able to upgrade from SoftHSMv2 to the higher level of security from a ?real? HSM because you are bypassing it anyway. This is indeed the type of problem in your architecture that I suspected from your question. So, please don?t do it this way. A much better way would be: 1. Distribute public key material through LDAP 2. Keep private keys behind PKCS #11 3. Access PKCS #11, possibly remotely, to create any signatures 4. Exercise strict access control over the HSM, and be very mindful about the PIN used to access it 5. If you must, encapsulate replication algorithms between HSM nodes into a small and very, very secure and very, very limited-task bit of code (PKCS #11 wrapper or SoftHSMv2 storage engine) and don?t treat it is a trivial bit of coding but as a security hazard I apologise if I?ve been bold in the above; that must then have been my desire for clarity. I hope that similar mistakes haven?t been made in other parts of FreeIPA? Hopefully useful, Cheers, Rick van Rein OpenFortress Digital signatures From pviktori at redhat.com Mon Jun 23 12:26:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 14:26:57 +0200 Subject: [Freeipa-devel] [PATCH] 0607 netgroup: Add objectclass attribute to read permissions Message-ID: <53A81D11.90405@redhat.com> A fix for the default read ACIs. See commit message. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0607-netgroup-Add-objectclass-attribute-to-read-permissio.patch Type: text/x-patch Size: 3685 bytes Desc: not available URL: From tjaalton at ubuntu.com Mon Jun 23 12:50:48 2014 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Mon, 23 Jun 2014 15:50:48 +0300 Subject: [Freeipa-devel] freeipa and Debian multiarch triplet In-Reply-To: <53A7E613.5050901@redhat.com> References: <53A29CBA.3020505@ubuntu.com> <53A7E613.5050901@redhat.com> Message-ID: <53A822A8.6010505@ubuntu.com> 23.06.2014 11:32, Martin Kosek kirjoitti: > On 06/19/2014 10:18 AM, Timo Aaltonen wrote: >> >> Hi >> >> While porting the client code for current master I noticed that there >> are some hardcodings to use /usr/lib{,64} paths for various things. This >> is problematic for Debian and it's derivatives, since we use "proper >> multiarch(tm)" which means paths like >> /usr/lib/{i386-linux-gnu,x86_64-linux-gnu} and other GNU triplets. I'd >> need to force freeipa to build only on these two archs by setting FOO = >> /usr/lib/i386-linux-gnu and FOO_64 = /usr/lib/x86_64-linux-gnu. >> >> Ideas for solving it cleanly so that at least freeipa-client would be >> possible to build on other archs too? For the server at least 389 needs >> updates too, since it hardcodes paths the same way. > > Apparently there were not many ideas on this topic. In case you have some idea > how we could fix the ipaplatform package so that is serves you (or other > platform consumers) better we are still open to changes - 4.0 is not released yet. Well, maybe I was worrying too much, since for instance the firefox path is always /usr/lib/firefox on debian, so LIB64_FIREFOX can be whatever since LIB_FIREFOX will always match the correct path.. but I need to check the rest too. Applying the remaining ipaplatform patches to master would allow me to finish Debian client support, first draft anyway :) -- t From pspacek at redhat.com Mon Jun 23 12:57:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Jun 2014 14:57:36 +0200 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed Message-ID: <53A82440.30000@redhat.com> Hello list, I'm working on key wrapping mechanism described in thread "LDAP schema for DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would really appreciate any suggestions or comments on this. - I have difficulties to pick and use proper wrapping mechanisms and their configuration/usage patterns. - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose of PKCS#11 by exporting raw keys from HSM. I can see his point and we should be able to do all crypto operations inside SoftHSM. I have asked him to describe his doubts on freeipa-devel list - stay tuned. We need to wrap =============== - asymmetric key (zone key) with symmetric key (master key) - symmetric key (master key) with asymmetric key (replica key) LDAP schema prescribes some storage formats but my question is about crypto algorithms (and padding!) used for key wrapping. Asymmetric keys =============== According to schema [1] wrapped asymmetric (i.e. private) key must be stored in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part of EncryptedPrivateKeyInfo structure so we only have to add algorithm identifier, DER-encode the whole thing, and we could be done. I'm not sure where should I stick IV or what happens if default (fixed) IV value is left in place...? Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). RFC 3394 works only on blocks of 64 bits, which is not our case because EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get proper padding etc. And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but OpenSSL doesn't support RFC 5649! The patch with this functionality was submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state "new" and there was no reply to the e-mail in the original thread [4]. What do we do? - Convince OpenSSL to review and accept the patch? - Hack it around #0: Use something else as key wrapping method? Other wrapping methods would require SoftHSM modification because SoftHSM supports only AES mechanisms now. - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream patch in SoftHSM? Do we have enough expertise to implement it correctly? - Hack it around #2: Implement raw key extraction from SoftHSM and do key wrapping somehow somewhere? (Please nooooooo.) Symmetric keys ============== should be stored in 'ipaSecretKey' attribute but detailed storage format definition is missing from schema [1] right now. Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with asymmetric key as *wrapping* key so we need to add this functionality. The first question is: What algorithm and padding scheme should we use? Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively easy to implement to SoftHSM because it is already there, just not handled in C_WrapKey (so we need to add appropriate 'glue' there). Another question is storage format of the wrapped key. PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: "For wrapping, the ?input? to the encryption operation is the value of the CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The mechanism does not wrap the key type or any other information about the key, except the key length; the application must convey these separately." AFAIK it means that it wraps raw secret key and nothing else. If I'm not wrong we should be able to take resulting blob and stick it into OneSymmetricKey structure from RFC 6031 [5]. Honza, is it correct assumption/idea? I would really appreciate any suggestions or comments on this. Thank you for your time. [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 [2] http://tools.ietf.org/html/rfc5958#section-3 [3] http://rt.openssl.org/Ticket/Display.html?id=2204 [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 [5] https://tools.ietf.org/html/rfc6031#section-2 [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html [7] http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 -- Petr^2 Spacek From pviktori at redhat.com Mon Jun 23 12:59:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 14:59:57 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A7E03C.7020101@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> Message-ID: <53A824CD.2040400@redhat.com> On 06/23/2014 10:07 AM, Martin Kosek wrote: > On 06/20/2014 11:17 PM, Martin Kosek wrote: >> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>> All these should be independent, except for conflicts in ACI.txt that are >>> easily solved by running makeaci. >> >> Umh, now the fun begins as I see :) There will probably need to be some rebase, >> it clashed with some other ACI patches in my tree (namely Hosts which I acked). Rebased on top of my patch 0607, please apply that first. Added a new patch, 0608, which adds missing write permissions. >> 594: we miss permissions for Automount Locations. Permissions for keys&maps >> look ok. Added in 0608. >> >> 595: "System: Modify Group Membership" is probably waiting for the group >> objectclass fix - the filter is different. Otherwise it looks ok. Right; rebased. >> 596-598: HBAC is ok >> >> 599: hostgroup is OK >> >> 600: there must have been some DS problem on my side as my regular user could >> not see any netgroup The problem is a bit closer to home this time. Fixed in patch 0607. >> 601: privileges - we miss CRUD ACIs Added in 0608. We also miss CRUD permissions on permissions, but since currently these need pretty much unlimited access to ACIs, it's better to keep them admin-only. >> 602: roles were ok >> >> 603: ok >> >> I got this far today, the rest will need to wait for the next week. > > 604: ok, I was able to create a service, get a keytab > > 605: Should we case the permissions as "Sudo Command instead of "Sudo command"? Yes, fixed > 606: we also miss Modify Sudo Command permission so that people can modify > description. Otherwise ok. Added in 0608. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0594.2-Convert-Automount-default-permissions-to-managed.patch Type: text/x-patch Size: 16366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0595.2-Convert-Group-default-permissions-to-managed.patch Type: text/x-patch Size: 11988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0596.2-Convert-HBAC-Rule-default-permissions-to-managed.patch Type: text/x-patch Size: 9525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0597.2-Convert-HBAC-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 6264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0598.2-Convert-HBAC-Service-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0599.2-Convert-Hostgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 8847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0600.2-Convert-Netgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 9239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0601.2-Convert-the-Modify-privilege-membership-permission-t.patch Type: text/x-patch Size: 4658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0602.2-Convert-Role-default-permissions-to-managed.patch Type: text/x-patch Size: 8689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0603.2-Convert-SELinux-User-Map-default-permissions-to-mana.patch Type: text/x-patch Size: 7888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0604.2-Convert-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 8890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0605.2-Convert-Sudo-Command-default-permissions-to-managed.patch Type: text/x-patch Size: 8615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0606.2-Convert-Sudo-Command-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0608.2-Add-several-CRUD-default-permissions.patch Type: text/x-patch Size: 10406 bytes Desc: not available URL: From abokovoy at redhat.com Mon Jun 23 13:00:05 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Jun 2014 16:00:05 +0300 Subject: [Freeipa-devel] [PATCH 0232] trusts: Allow reading ipaNTSecurityIdentifier in user and In-Reply-To: <53A81287.1060402@redhat.com> References: <53A81287.1060402@redhat.com> Message-ID: <20140623130005.GW7233@redhat.com> On Mon, 23 Jun 2014, Tomas Babej wrote: >Hi, > >this fixes initial findings of trust-after-aci-refactoring >investigation. Consider this effort still WIP (not this patch though). > >https://fedorahosted.org/freeipa/ticket/4385 ACK. With this fix we are able to establish trust with git master. There are some strange errors where Samba libraries may report protocol version mismatch or AD refuse operating with access denied while AD administrator account works and creates trusts with rpcclient. This patch should go in but we are looking to fix the rest. -- / Alexander Bokovoy From npmccallum at redhat.com Mon Jun 23 13:07:26 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Jun 2014 09:07:26 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403308559.19579.5.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> Message-ID: <1403528846.23272.3.camel@ipa.example.com> On Fri, 2014-06-20 at 19:55 -0400, Simo Sorce wrote: > On Fri, 2014-06-20 at 16:50 -0400, Nathaniel McCallum wrote: > > On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote: > > > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > > > > This change would have very small impact on your patch set, but would > > > > be > > > > much clearer for the future consumers of this protocol. Code can be > > > > changed; protocols can't. > > > > > > Ok this new patchset implements the requested change. > > > Initial testing seem to indicate it all works as expected. > > > > 0001: Line 555 has very wrong indentation. > > > > Other than that, I have looked over 0001 and 0002 very closely and built > > and tested them. Everything works. So conditional (indent fix) ACK on > > both of these. I don't see any reason to avoid merging these as soon as > > the indent fix is completed. It should substantially reduce your > > differential from master. > > > > In the new ASN.1, "Newkeys" has the wrong capitalization. This affects > > patches 0003 and 0005. > > > > I think patch 0003 may still have a permissions problem. For instance, > > this works for me with no error: > > > > $ ipa user-find --whoami > > -------------- > > 1 user matched > > -------------- > > User login: admin > > Last name: Administrator > > Home directory: /home/admin > > Login shell: /bin/bash > > UID: 1569600000 > > GID: 1569600000 > > Account disabled: False > > Password: True > > Kerberos keys available: True > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > > > $ ipa-getkeytab -s ipa.example.com -p foo/ipa.example.com -r -k bar > > Keytab successfully retrieved and stored in: bar > > > > Is that really correct behavior or did I screw something up? I thought > > we had restricted the admin user from reading keys without changing > > them... > > Can you check if ipaProtectedOperation is in the aci attribute in the > base tree object ? > It should be there as excluded, and that should cause admin to not be > able to retrieve keytabs. It was not. While running ipa-ldap-updater I got the following: InvalidSyntax: ACL Syntax Error(-5):(targetattr= \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are allowed to rekey any entity\22; allow(write) groupdn = \22ldap:///cn=admins: Invalid syntax. Nathaniel From pviktori at redhat.com Mon Jun 23 13:09:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 15:09:39 +0200 Subject: [Freeipa-devel] [PATCH 0232] trusts: Allow reading ipaNTSecurityIdentifier in user and In-Reply-To: <20140623130005.GW7233@redhat.com> References: <53A81287.1060402@redhat.com> <20140623130005.GW7233@redhat.com> Message-ID: <53A82713.30900@redhat.com> On 06/23/2014 03:00 PM, Alexander Bokovoy wrote: > On Mon, 23 Jun 2014, Tomas Babej wrote: >> Hi, >> >> this fixes initial findings of trust-after-aci-refactoring >> investigation. Consider this effort still WIP (not this patch though). >> >> https://fedorahosted.org/freeipa/ticket/4385 > ACK. With this fix we are able to establish trust with git master. > > There are some strange errors where Samba libraries may report protocol > version mismatch or AD refuse operating with access denied while AD > administrator account works and creates trusts with rpcclient. > > This patch should go in but we are looking to fix the rest. > Hi Tom??, I've rebased the patch; there was a change in group ACIs recently. I've also made the attributes lowercase for consistency. Does this version still look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0232+pviktori-trusts-Allow-reading-ipaNTSecurityIdentifier-in-user.patch Type: text/x-patch Size: 5271 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 23 13:15:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jun 2014 15:15:46 +0200 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <53A45EF1.6080209@redhat.com> References: <538473E0.6070702@redhat.com> <5399C659.30109@redhat.com> <53A173CB.3060203@redhat.com> <53A45EF1.6080209@redhat.com> Message-ID: <53A82882.8070302@redhat.com> On 20.6.2014 18:18, Endi Sukma Dewata wrote: > On 6/18/2014 6:11 AM, Petr Vobornik wrote: >>> 1. As discussed on IRC, the plugin is causing an error due to missing >>> extend.js. This needs to be fixed. >> >> Fixed > >>> 4. I agree that the facet shouldn't define the hash. The hash should be >>> part of the plugin declaration. >> >> Ideally, facet should be router agnostic. We need a mechanism of mapping >> facet's state to hash and vice versa. >> >> Originally I did not want to do it now because it requires bigger >> refactoring of a router. >> >> While I was designing it, I ended up with a patch - attached. >> >> It's a replacement for original patch #649. Patch #651 and example >> plugin are updated accordingly. >> >> Basically I refactored router's `navigate_to_*`, `_create_*_hash` and >> `*_route_handler` methods into separate classes which are registered and >> mapped to facets. All in navigation.routing module. >> >> Btw, can you think of some better name(s)/placement for the module? > > ACK. Some comments below, but I think they can be addressed later. pushed to master: * c6c7dfeefbb8b94f102aef6a04d828530e3ccb0f webui: fix excessive registration of state change event listeners * 27836cba9d865b1c912a65d0cd04562194f9e93f webui: support standalone facets in navigation module * 86898065b5e1d60168e2daff050853729b34f1ce webui: generic routing * 6f5e80b0cec57a89a68f2935b5fe01d919b11031 webui: add parent link to widgets in ContainerMixin * 6e43d01266f105cdf3cf27a1dbb87ac80da4a06d webui: plugin API > > 1. I'm not sure if we really need a HashCreator. Ideally the router > should map a hash to a page. Links to another page can be hardcoded too > (and substitute the parameters). The main purpose of a hash creator is to update hash when a facet state changes. This change can be initiated from the facet itself, e.g. when searching in a search facet. Removing the hash creator would make facets dependent on navigation specifics. I would agree if it was related only to links. But even then it would be better to have a method which would create the hash (for the one which shares the same pattern) to reduce code reuse. In any case, it's possible to hardcode hash parts in links if one needs to. > > 2. Ideally there should be no entity-specific navigation code. All > routing should be handled in a generic way. This probably depends on the > entity-facet separation that we discussed previously. So routes like this: > > /e/:entity/:facet/:pkeys/*args > > should be replaced by individual routes for each entity: > > /user/:facet/:pkeys/*args > /group/:facet/:pkeys/*args > Yes, but IMHO the hash prefix is a detail. It would be more important if it would be a REST API where it's a core aspect. > Probably the entities should be written like plugins. They are, in a way... I'm toying with the idea of moving them (user.js, group.js, ...) to plugins dir. > > 3. If we fix #1 and #2, is the "routing" module still necessary? The > "routing" object probably should have been a "router", but are you > concerned about conflicting with Dojo's router and the existing Router > module? Our 'Router' is just an encapsulation over the Dojo's router. It's true that with this refactoring, the encapsulation became so thin that the logic could be moved to 'routing' and 'routing' could be then renamed to 'router'. There would be no conflict since the modules are in different packages. If we want to do it, we should do it in 4.0 (ASAP). > > 4. The args/query in the navigation paths should be separated by a more > standard delimiter "?" instead of "//". For example: > > /ipa/ui/#/e/user/search//filter=test > > should be replaced with: > > /ipa/ui/#/e/user/search?filter=test > note that // is a result of /:pkeys/, where :pkeys is '' Therefore a simple replacement would lead to /ipa/ui/#/e/user/search/?filter=test Please file a ticket, if you think it's important. Lets say that we would implement #2 and #4. Would we also want to keep the old routes for backwards compatibility? (main purpose of hashes is to make the page bookmarkable). IMHO people don't care about #2 and #4 much, but they care about broken bookmarks. -- Petr Vobornik From npmccallum at redhat.com Mon Jun 23 13:16:36 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Jun 2014 09:16:36 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403308559.19579.5.camel@willson.usersys.redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> Message-ID: <1403529396.3263.1.camel@ipa.example.com> On Fri, 2014-06-20 at 19:55 -0400, Simo Sorce wrote: > On Fri, 2014-06-20 at 16:50 -0400, Nathaniel McCallum wrote: > > On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote: > > > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > > > > This change would have very small impact on your patch set, but would > > > > be > > > > much clearer for the future consumers of this protocol. Code can be > > > > changed; protocols can't. > > > > > > Ok this new patchset implements the requested change. > > > Initial testing seem to indicate it all works as expected. > > > > 0001: Line 555 has very wrong indentation. > > > > Other than that, I have looked over 0001 and 0002 very closely and built > > and tested them. Everything works. So conditional (indent fix) ACK on > > both of these. I don't see any reason to avoid merging these as soon as > > the indent fix is completed. It should substantially reduce your > > differential from master. > > > > In the new ASN.1, "Newkeys" has the wrong capitalization. This affects > > patches 0003 and 0005. > > > > I think patch 0003 may still have a permissions problem. For instance, > > this works for me with no error: > > > > $ ipa user-find --whoami > > -------------- > > 1 user matched > > -------------- > > User login: admin > > Last name: Administrator > > Home directory: /home/admin > > Login shell: /bin/bash > > UID: 1569600000 > > GID: 1569600000 > > Account disabled: False > > Password: True > > Kerberos keys available: True > > ---------------------------- > > Number of entries returned 1 > > ---------------------------- > > > > $ ipa-getkeytab -s ipa.example.com -p foo/ipa.example.com -r -k bar > > Keytab successfully retrieved and stored in: bar > > > > Is that really correct behavior or did I screw something up? I thought > > we had restricted the admin user from reading keys without changing > > them... > > Can you check if ipaProtectedOperation is in the aci attribute in the > base tree object ? > It should be there as excluded, and that should cause admin to not be > able to retrieve keytabs. Also, patch 0003 no longer applies cleanly to master. Nathaniel From pviktori at redhat.com Mon Jun 23 13:28:23 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Jun 2014 15:28:23 +0200 Subject: [Freeipa-devel] [PATCH 0232] trusts: Allow reading ipaNTSecurityIdentifier in user and In-Reply-To: <53A82713.30900@redhat.com> References: <53A81287.1060402@redhat.com> <20140623130005.GW7233@redhat.com> <53A82713.30900@redhat.com> Message-ID: <53A82B77.7050005@redhat.com> On 06/23/2014 03:09 PM, Petr Viktorin wrote: > On 06/23/2014 03:00 PM, Alexander Bokovoy wrote: >> On Mon, 23 Jun 2014, Tomas Babej wrote: >>> Hi, >>> >>> this fixes initial findings of trust-after-aci-refactoring >>> investigation. Consider this effort still WIP (not this patch though). >>> >>> https://fedorahosted.org/freeipa/ticket/4385 >> ACK. With this fix we are able to establish trust with git master. >> >> There are some strange errors where Samba libraries may report protocol >> version mismatch or AD refuse operating with access denied while AD >> administrator account works and creates trusts with rpcclient. >> >> This patch should go in but we are looking to fix the rest. >> > > Hi Tom??, > I've rebased the patch; there was a change in group ACIs recently. > I've also made the attributes lowercase for consistency. > > Does this version still look OK? Pushed to master: ef5309d3764390e0364db2e21568f525a18babb5 -- Petr? From npmccallum at redhat.com Mon Jun 23 13:29:58 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Jun 2014 09:29:58 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <53A7DA57.1030301@redhat.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <53A7DA57.1030301@redhat.com> Message-ID: <1403530198.3263.3.camel@ipa.example.com> On Mon, 2014-06-23 at 09:42 +0200, Martin Kosek wrote: > On 06/23/2014 09:29 AM, Alexander Bokovoy wrote: > > On Fri, 20 Jun 2014, Nathaniel McCallum wrote: > >> On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: > >>> This command behaves almost exactly like otptoken-add except: > >>> 1. The new token data is written directly to a YubiKey > >>> 2. The vendor/model/serial fields are populated from the YubiKey > >>> > >>> === NOTE === > >>> 1. This patch depends on the new Fedora package: python-yubico. If you > >>> would like to help with the package review, please assign yourself here: > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > >> > >> New version of the patch. This one works (yay!). > >> > >> 1. Because of the dependency on python-yubico, is this feature something > >> we want in core FreeIPA? As a subpackage? Separate project altogether? > >> The only dependency for python-yubico is pyusb. > > I'd prefer to have it integrated but have a separate dummy subpackage > > that pulls in all required dependencies, like, freeipa-tools-yubico. Instead of > > failing when 'ipa otptoken-add-yubikey' is called, please wrap the > > python-yubico import into a code that allows reporting a message back to > > the user advising to install the package. > > +1. For 4.0, I would just fail cleanly and keep functioning if python-yubico is > not configured, just like in Alexander's trust example. > > For 4.2, we plan to introduce subpackages > (https://fedorahosted.org/freeipa/ticket/4058). This is the right time and > place to introduce something like "freeipa-server-otp" which would contain the > files and requirements for OTP. It would also give is time to get it to > standard Fedora repositories if we want this functionality by default. python-yubico is already in F21 (as of yesterday). So, unless there is some other reason that matters, we can probably just add a hard dependency for now. Is that acceptable? Nathaniel From pspacek at redhat.com Mon Jun 23 15:12:56 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Jun 2014 17:12:56 +0200 Subject: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release Message-ID: <53A843F8.7000405@redhat.com> Hello, Bump NVR to 4.4. Update NEWS for upcoming 4.4 release. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0267-Update-NEWS-for-upcoming-4.4-release.patch Type: text/x-patch Size: 622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0268-Bump-NVR-to-4.4.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 23 15:42:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 17:42:46 +0200 Subject: [Freeipa-devel] [PATCH] 0607 netgroup: Add objectclass attribute to read permissions In-Reply-To: <53A81D11.90405@redhat.com> References: <53A81D11.90405@redhat.com> Message-ID: <53A84AF6.7040905@redhat.com> On 06/23/2014 02:26 PM, Petr Viktorin wrote: > A fix for the default read ACIs. See commit message. Thanks, works fine. ACK, pushed to master. Martin From mbasti at redhat.com Mon Jun 23 15:44:05 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Jun 2014 17:44:05 +0200 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade Message-ID: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> Hello, I have following issues: #1 Upgrading existing replicas to support DNSSEC won't work for current design (replica-file as storage for temporal replica key). Temporal private key needs to be copied to replica, and no encrypted master-key for replica is prepared in LDAP, because user doesn't need to run ipa-replica-prepare. After discussion with Petr2, the solution is: a) Each replica (except first - which generates master-key) generates replica public and private keys. b) Replica uploads public key to LDAP c) Replica with generated master key, use the public key (b) to encrypt master-key and store it to LDAP. Replica with master-key must detect, if there is any new public replica key. d) Replica (b) is now able to get master-key using own private replica key #2 We need to choose only one replica which will generate, (rotate, ...) DNSSEC keys. My proposal is to test during installation/upgrade if any dnssec/master keys are in LDAP. If no key was found, the first server is installed/upgraded and DNSSEC key generator is required. But there is issue with parallel upgrade multiple replicas (or if replication temporarily doesn't work). There is no guarantee if replicas will be able to detect if any replica became DNSSEC key generator. Please write me your opinions. -- Martin^2 Basti From mbasti at redhat.com Mon Jun 23 15:49:39 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Jun 2014 17:49:39 +0200 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> Message-ID: <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: > Hello, > I have following issues: > > #1 Upgrading existing replicas to support DNSSEC won't work for current > design (replica-file as storage for temporal replica key). > Temporal private key needs to be copied to replica, and no encrypted > master-key for replica is prepared in LDAP, because user doesn't need to > run ipa-replica-prepare. > > After discussion with Petr2, the solution is: > a) Each replica (except first - which generates master-key) generates > replica public and private keys. > b) Replica uploads public key to LDAP > c) Replica with generated master key, use the public key (b) to encrypt > master-key and store it to LDAP. Replica with master-key must detect, if > there is any new public replica key. > d) Replica (b) is now able to get master-key using own private replica > key > > > #2 We need to choose only one replica which will generate, (rotate, ...) > DNSSEC keys. and generate master key too > My proposal is to test during installation/upgrade if any dnssec/master > keys are in LDAP. If no key was found, the first server is > installed/upgraded and DNSSEC key generator is required. > > But there is issue with parallel upgrade multiple replicas (or if > replication temporarily doesn't work). There is no guarantee if replicas > will be able to detect if any replica became DNSSEC key generator. > > > Please write me your opinions. > -- Martin^2 Basti From mkosek at redhat.com Mon Jun 23 15:51:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Jun 2014 17:51:16 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A824CD.2040400@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> <53A824CD.2040400@redhat.com> Message-ID: <53A84CF4.8090501@redhat.com> On 06/23/2014 02:59 PM, Petr Viktorin wrote: > On 06/23/2014 10:07 AM, Martin Kosek wrote: >> On 06/20/2014 11:17 PM, Martin Kosek wrote: >>> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>>> All these should be independent, except for conflicts in ACI.txt that are >>>> easily solved by running makeaci. >>> >>> Umh, now the fun begins as I see :) There will probably need to be some rebase, >>> it clashed with some other ACI patches in my tree (namely Hosts which I acked). > > Rebased on top of my patch 0607, please apply that first. > > Added a new patch, 0608, which adds missing write permissions. > > >>> 594: we miss permissions for Automount Locations. Permissions for keys&maps >>> look ok. > > Added in 0608. > >>> >>> 595: "System: Modify Group Membership" is probably waiting for the group >>> objectclass fix - the filter is different. Otherwise it looks ok. > > Right; rebased. > >>> 596-598: HBAC is ok >>> >>> 599: hostgroup is OK >>> >>> 600: there must have been some DS problem on my side as my regular user could >>> not see any netgroup > > The problem is a bit closer to home this time. > Fixed in patch 0607. > >>> 601: privileges - we miss CRUD ACIs > > Added in 0608. > > We also miss CRUD permissions on permissions, but since currently these need > pretty much unlimited access to ACIs, it's better to keep them admin-only. > >>> 602: roles were ok >>> >>> 603: ok >>> >>> I got this far today, the rest will need to wait for the next week. >> >> 604: ok, I was able to create a service, get a keytab >> >> 605: Should we case the permissions as "Sudo Command instead of "Sudo command"? > > Yes, fixed > >> 606: we also miss Modify Sudo Command permission so that people can modify >> description. Otherwise ok. > > Added in 0608. > > 1) # ipa-server-install: ... Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing required attribute "objectclass" ... There is a problem in this pending update: dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' You apparently also need to make this permission also a member of "Modify Group membership" privilege. 2) We may not need "System: Modify Automount Locations" as there is just the CN and we do not support renames in automountlocation API. I am not insisting. When these 2 issues are resolved, we can push. Martin From pvoborni at redhat.com Mon Jun 23 16:09:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 23 Jun 2014 18:09:30 +0200 Subject: [Freeipa-devel] [PATCH] 669 webui: don't limit permission search in privileges Message-ID: <53A8513A.7040502@redhat.com> Search for privileges was limited to bindruletype==permission. There was no reason to do that. This patch removes the restriction. Related to: https://fedorahosted.org/freeipa/ticket/4079 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0669-webui-don-t-limit-permission-search-in-privileges.patch Type: text/x-patch Size: 1135 bytes Desc: not available URL: From edewata at redhat.com Mon Jun 23 16:35:47 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Jun 2014 11:35:47 -0500 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <53A82882.8070302@redhat.com> References: <538473E0.6070702@redhat.com> <5399C659.30109@redhat.com> <53A173CB.3060203@redhat.com> <53A45EF1.6080209@redhat.com> <53A82882.8070302@redhat.com> Message-ID: <53A85763.4050802@redhat.com> On 6/23/2014 8:15 AM, Petr Vobornik wrote: >> 1. I'm not sure if we really need a HashCreator. Ideally the router >> should map a hash to a page. Links to another page can be hardcoded too >> (and substitute the parameters). > > The main purpose of a hash creator is to update hash when a facet state > changes. This change can be initiated from the facet itself, e.g. when > searching in a search facet. Removing the hash creator would make facets > dependent on navigation specifics. I was thinking if the facet itself is changing the state, it will only change the query part of the URL. The base facet URL itself is assigned by the router. I think we used to put all UI states in the URL so that's why we needed a hash creator. > I would agree if it was related only to links. But even then it would be > better to have a method which would create the hash (for the one which > shares the same pattern) to reduce code reuse. In any case, it's > possible to hardcode hash parts in links if one needs to. It's more about removing dependencies between pages. For example, to link from one page to another we use something like this: navigation.show_entity(entity.name, facetname, [pkey]); This means we're explicitly handling the link. And this also puts additional restrictions such as the target page must be an entity page which has one level sub page called 'facetname' that takes one primary key. If the target page is not an entity page we'd have to use a different method. I think it would be cleaner if the link can be defined in a (future) template like this: Note that the template is used to generate the links only. When the user clicks the link we rely on the browser, or other routing libraries, to handle it so less code to maintain and it puts the UI workflow in the hands of UI designers. >> 2. Ideally there should be no entity-specific navigation code. All >> routing should be handled in a generic way. This probably depends on the >> entity-facet separation that we discussed previously. So routes like >> this: >> >> /e/:entity/:facet/:pkeys/*args >> >> should be replaced by individual routes for each entity: >> >> /user/:facet/:pkeys/*args >> /group/:facet/:pkeys/*args > > Yes, but IMHO the hash prefix is a detail. It would be more important if > it would be a REST API where it's a core aspect. Right, a REST URL probably would look like: /ipa/ui/users/{facet}/{pkey}?{query} And ideally if you open a REST URL in a browser you should get a UI. So anything that brings the UI closer to this would be great. >> 4. The args/query in the navigation paths should be separated by a more >> standard delimiter "?" instead of "//". For example: >> >> /ipa/ui/#/e/user/search//filter=test >> >> should be replaced with: >> >> /ipa/ui/#/e/user/search?filter=test > > note that // is a result of /:pkeys/, where :pkeys is '' Therefore a > simple replacement would lead to > /ipa/ui/#/e/user/search/?filter=test > > Please file a ticket, if you think it's important. I was originally thinking this to be a way to mimic the REST URL, but now I'm not sure if it would interfere with URL parsing because in this case the ? will be part of the URL hash, not URL query, so maybe we should just leave it for now. > Lets say that we would implement #2 and #4. Would we also want to keep > the old routes for backwards compatibility? (main purpose of hashes is > to make the page bookmarkable). IMHO people don't care about #2 and #4 > much, but they care about broken bookmarks. The hashes are probably more useful to make the browser's Back button functional. Bookmarking is probably a secondary benefit, but are there pages in the UI that people would likely to bookmark? An admin probably would just bookmark the main URL, not a particular page in the UI. Backward compatibility of routing is nice, but I don't think it's a hard requirement. -- Endi S. Dewata From simo at redhat.com Mon Jun 23 16:48:57 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Jun 2014 12:48:57 -0400 (EDT) Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403528846.23272.3.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> Message-ID: <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > Can you check if ipaProtectedOperation is in the aci attribute in the > > base tree object ? > > It should be there as excluded, and that should cause admin to not be > > able to retrieve keytabs. > > It was not. While running ipa-ldap-updater I got the following: > InvalidSyntax: ACL Syntax Error(-5):(targetattr= > \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > allowed to rekey any entity\22; allow(write) groupdn = > \22ldap:///cn=admins: Invalid syntax. Uhmm I do not see anything obviously wrong with ACI instruction, it looks just like the one I replace, Ideas ? Do you have ipaProtectedOperation in the schema ? (I rebased patch 3 but will wait to send a patchset until we understand (and fix) why this is failing to update. Simo. From simo at redhat.com Mon Jun 23 18:35:06 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Jun 2014 14:35:06 -0400 (EDT) Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> Message-ID: <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> ----- Original Message ----- > ----- Original Message ----- > > > Can you check if ipaProtectedOperation is in the aci attribute in the > > > base tree object ? > > > It should be there as excluded, and that should cause admin to not be > > > able to retrieve keytabs. > > > > It was not. While running ipa-ldap-updater I got the following: > > InvalidSyntax: ACL Syntax Error(-5):(targetattr= > > \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > > allowed to rekey any entity\22; allow(write) groupdn = > > \22ldap:///cn=admins: Invalid syntax. > > Uhmm I do not see anything obviously wrong with ACI instruction, it looks > just like the one I replace, Ideas ? > Do you have ipaProtectedOperation in the schema ? > > (I rebased patch 3 but will wait to send a patchset until we understand (and > fix) why this is failing to update. Ok, apparently it was a quoting issue in the .update files, hopefully that's the only issue (I am at a conference today and do not have my test env. handy). The attached patches are rebased on the latest master. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 36280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 32006 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 16607 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2016 bytes Desc: not available URL: From ssorce at redhat.com Mon Jun 23 20:47:00 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 23 Jun 2014 16:47:00 -0400 (EDT) Subject: [Freeipa-devel] SoftHSMv2: key extraction (originally to OpenDNSSEC-user) In-Reply-To: <026DE9D2-0D33-40E7-B4CB-32E64F1182DD@openfortress.nl> References: <7D684B2E-A358-45BC-92A7-6456C91D5C30@openfortress.nl> <026DE9D2-0D33-40E7-B4CB-32E64F1182DD@openfortress.nl> Message-ID: <852914519.29119644.1403556420949.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Petr, > > I have to be bold I fear? > > > You can read about the basic idea here: > > https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html > > You are proposing to drag around the private keys between pieces of software, > in a format encrypted to an externally generated, symmetric master key that > is known to multiple pieces of infrastructure. That ranks as? functional > thinking, but rather poor security practice. > > > (Discussion continues in next months, I'm sorry for mailman inability to > > create direct links across months.) > > Quickly browsing through the responses, there has only been discussion about > directory formatting issues, but there are no security-minded responses. > > > Any comments on it are more than welcome! > > To be honest, I am shocked ? this is a *very* weak design from a security > perspective. What you are doing undermines the concept of PKCS #11 > completely, and it is *much* weaker than a SoftHSM-based implementation. > > The thing is, even with SoftHSM you have good control over where your private > key material is copied to; think non-swappable memory, think avoidance of > static bits burning into DRAM cells through ion displacement; I don?t know > how far SoftHSMv2 goes, but at least it is in a position to care. The PKCS > #11 API is the way to access private keys through using them, and anything > that comes out of a signing operation is safe to publish. An HSM strongly > limits the places where the (wrapped) private key is stored temporarily or > for a long time, while you are proposing to drag the private key material > through all sorts of functional / technical / networking tools, a lot of > which has not been vetted for security like an HSM is. SoftHSMv2, is > designed by knowledgeable cryptographers and should be considered a superb > manner of key management relative to your own coding, unless you and all > coders in the wrapped-private-key path also happen to be such knowledgeable > cryptographers. > > The use of a master key, which I presume is used to decode the private key, > is an even clearer misuse of PKCS #11; not only are you not using its > private key encapsulation, you are even decrypting it outside of any HSM > (?professional key management?) engine. You are effectively reducing PKCS > #11 to a software library, indeed pretty much like an OpenSSL library that > loads private keys into the rich / complex / dangerous functionality of an > application, decrypts them for use in what may or may not be rock-solid > signing code. You are basically saying that you don?t want or need PKCS #11 > and that you would rather not have to deal with it at all, because it is > obstructing you and its security model is not of interest to you.This means > that your users wil not be able to upgrade from SoftHSMv2 to the higher > level of security from a ?real? HSM because you are bypassing it anyway. > > This is indeed the type of problem in your architecture that I suspected from > your question. > > So, please don?t do it this way. > > A much better way would be: > > 1. Distribute public key material through LDAP > 2. Keep private keys behind PKCS #11 > 3. Access PKCS #11, possibly remotely, to create any signatures > 4. Exercise strict access control over the HSM, and be very mindful about the > PIN used to access it > 5. If you must, encapsulate replication algorithms between HSM nodes into a > small and very, very secure and very, very limited-task bit of code (PKCS > #11 wrapper or SoftHSMv2 storage engine) and don?t treat it is a trivial bit > of coding but as a security hazard > > I apologise if I?ve been bold in the above; that must then have been my > desire for clarity. I hope that similar mistakes haven?t been made in other > parts of FreeIPA? > > > Hopefully useful, To be honest, no, this is not very useful, let me bold, and I am not being defensive here. You have not thought at all about the environment in which all this stuff is running, and what is the aim is here. There are certainly some compromises here, the compromise is between security and something practical. Now that doesn't mean we can't change something, and we welcome thoughtful input. Distribution of keys is a fundamental part of the design, it is clearly not as secure as a HSM can be by keeping the private key always in hardware, but a single point of failure is not useful in our model. We want to architect things so that each server can use an HSM in order to deal with the individual server keys, that is something we need to explore, and is in our pipeline, and not just for DNSSEC. But the server keys only wrap distributed master keys that other software will use. In some cases they can be feed back in to softHSM for sure, and we should make it possible for the system to work that way in the long term. so feedback in that direction will certainly help. Thank you. Simo. -- Simo Sorce * Red Hat, Inc. * New York From npmccallum at redhat.com Mon Jun 23 21:13:06 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Jun 2014 17:13:06 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <20140623072939.GV7233@redhat.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> Message-ID: <1403557986.3263.7.camel@ipa.example.com> On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: > On Fri, 20 Jun 2014, Nathaniel McCallum wrote: > >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: > >> This command behaves almost exactly like otptoken-add except: > >> 1. The new token data is written directly to a YubiKey > >> 2. The vendor/model/serial fields are populated from the YubiKey > >> > >> === NOTE === > >> 1. This patch depends on the new Fedora package: python-yubico. If you > >> would like to help with the package review, please assign yourself here: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > > > >New version of the patch. This one works (yay!). > > > >1. Because of the dependency on python-yubico, is this feature something > >we want in core FreeIPA? As a subpackage? Separate project altogether? > >The only dependency for python-yubico is pyusb. > I'd prefer to have it integrated but have a separate dummy subpackage > that pulls in all required dependencies, like, freeipa-tools-yubico. Instead > of failing when 'ipa otptoken-add-yubikey' is called, please wrap the > python-yubico import into a code that allows reporting a message back to > the user advising to install the package. > > Who is a supposed user for this command? IPA command line interface isn't > usually available on enrolled machines even though underlying Python > modules are all there. Are we talking about admins or just users? As discussed on IRC, we are currently hard-coding lots of optional dependencies. And breaking this apart into subpackages can be solved at a later point. YubiKey is also a unique case: we don't expect to be adding many more plugins like this. For these reasons, I have kept this as a hard dependency. To ease this transition, I have added python-yubico to F20 and EL6. You can help with the update review here: https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 > >3. This code currently emits a warning from the call to otptoken-add: > >WARNING: API Version number was not sent, forward compatibility not > >guaranteed. Assuming server's API version, 2.89 > > > >How do I fix this? > Do not filter 'version' field in options in execute(). I opted to not filter out version rather than hard-code it (pviktori's suggestion). This is based on the fact that otptoken-add-yubikey is tightly integrated with otptoken-add (even using some of the class attributes from otptoken). > >4. I am not sure why I have to delete the summary and value keys from > >the return dictionary. It would be nice to display this summary message > >just like otptoken-add. I still need help on this. > >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These > >aren't user settable, but we need to pass them from the yubikey > >(client-side) to the server. This is no longer needed since I am doing everything in forward(). However, listing these three as output params causes them to appear before the token's ID. I don't think this is the right way to output these. But this seems to me a framework issue. > >6. I'm not sure my use of assert or ValueError are correct. What should > >I do here? Still need help here. > >7. Considering that this is just a specialized invocation of > >otptoken-add, can't we do this all on the client-side? This is why I had > >originally used frontend.Local rather than frontend.Command. > You don't need to implement execute then, only forward, where you'll > forward your call to the server under otptoken_add name. > > Typically in #forward we call super's forward but that is because we > in Command.forward() we simply forward the command to the remote backend, > using the self.name. In your case we shouldn't really have a separate > command on the server under the same name, so you'll need to avoid > calling > > So, it should look like this: > > def forward(self, *args, **kw): > perform yubikey initialization > filter out kw and args, if needed > return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) > > See service_show implementation for an example. Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058.2-Add-the-otptoken-add-yubikey-command.patch Type: text/x-patch Size: 6457 bytes Desc: not available URL: From npmccallum at redhat.com Mon Jun 23 21:24:02 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 23 Jun 2014 17:24:02 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> Message-ID: <1403558642.3263.9.camel@ipa.example.com> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: > ----- Original Message ----- > > ----- Original Message ----- > > > > Can you check if ipaProtectedOperation is in the aci attribute in the > > > > base tree object ? > > > > It should be there as excluded, and that should cause admin to not be > > > > able to retrieve keytabs. > > > > > > It was not. While running ipa-ldap-updater I got the following: > > > InvalidSyntax: ACL Syntax Error(-5):(targetattr= > > > \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > > > allowed to rekey any entity\22; allow(write) groupdn = > > > \22ldap:///cn=admins: Invalid syntax. > > > > Uhmm I do not see anything obviously wrong with ACI instruction, it looks > > just like the one I replace, Ideas ? > > Do you have ipaProtectedOperation in the schema ? > > > > (I rebased patch 3 but will wait to send a patchset until we understand (and > > fix) why this is failing to update. > > Ok, apparently it was a quoting issue in the .update files, hopefully that's > the only issue (I am at a conference today and do not have my test env. handy). > > The attached patches are rebased on the latest master. 0001: Line 555 has very wrong indentation. I don't see anything else wrong in the other patches. I've tested everything and it works as designed. I have CC'd everyone who was involved with review at any point on these patches. This serves as my public notice that I'd like to ACK the next round of patches. If anyone has anything else to add, please do it before tomorrow evening. Thanks! Nathaniel From jcholast at redhat.com Tue Jun 24 06:43:02 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Jun 2014 08:43:02 +0200 Subject: [Freeipa-devel] LDAP schema for DNSSEC keys In-Reply-To: <1403288586.12884.161.camel@willson.usersys.redhat.com> References: <5361229A.7030303@redhat.com> <5399B7F5.1040306@redhat.com> <53A47794.6060704@redhat.com> <1403288586.12884.161.camel@willson.usersys.redhat.com> Message-ID: <53A91DF6.6050604@redhat.com> On 20.6.2014 20:23, Simo Sorce wrote: > On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote: >> ipk11Private;privatekey: TRUE >> ipk11Private;publickey: FALSE > > can these two ever hold a different value ? > ie a privatekey be FALSE and a publickey be TRUE ? > > If not I suggest you do not add this attribute at all and assume their > value ? +1, we can use default values for most, if not all of the boolean flag attributes. Personally, I would try to avoid using ipk11 attributes until the PKCS#11 module is designed/implemented. > (btw I forgot what's the point of that attribute) When it is true, a user may not access the object until the user has been authenticated to the token (what PKCS#11 spec says). > > Simo. > -- Jan Cholasta From jcholast at redhat.com Tue Jun 24 07:49:37 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Jun 2014 09:49:37 +0200 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <53A82440.30000@redhat.com> References: <53A82440.30000@redhat.com> Message-ID: <53A92D91.6030601@redhat.com> On 23.6.2014 14:57, Petr Spacek wrote: > Hello list, > > I'm working on key wrapping mechanism described in thread "LDAP schema > for DNSSEC keys" [0] and I'm really puzzled from the maze of crypto > here. I would really appreciate any suggestions or comments on this. > > - I have difficulties to pick and use proper wrapping mechanisms and > their configuration/usage patterns. > > - Rick van Rein from OpenDNSSEC-user list noted that we are defeating > purpose of PKCS#11 by exporting raw keys from HSM. I can see his point > and we should be able to do all crypto operations inside SoftHSM. > > I have asked him to describe his doubts on freeipa-devel list - stay tuned. > > > We need to wrap > =============== > - asymmetric key (zone key) with symmetric key (master key) > - symmetric key (master key) with asymmetric key (replica key) > > LDAP schema prescribes some storage formats but my question is about > crypto algorithms (and padding!) used for key wrapping. > > > Asymmetric keys > =============== > According to schema [1] wrapped asymmetric (i.e. private) key must be > stored in 'ipaPrivateKey' attribute as DER-encoded > EncryptedPrivateKeyInfo structure according to RFC 5958 [2]. > > It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData > part of EncryptedPrivateKeyInfo structure so we only have to add > algorithm identifier, DER-encode the whole thing, and we could be done. > > I'm not sure where should I stick IV or what happens if default (fixed) > IV value is left in place...? > > > Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted > with AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > > RFC 3394 works only on blocks of 64 bits, which is not our case because > EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > proper padding etc. > > And here is the problem: SoftHSM can use RFC 5649 using OpenSSL > functions but OpenSSL doesn't support RFC 5649! The patch with this > functionality was submitted back in 2010 to OpenSSL bug tracker [3] but > the ticket is in state "new" and there was no reply to the e-mail in the > original thread [4]. Does this mean SoftHSM does not support RFC 5649? > > What do we do? > - Convince OpenSSL to review and accept the patch? > - Hack it around #0: Use something else as key wrapping method? Other > wrapping methods would require SoftHSM modification because SoftHSM > supports only AES mechanisms now. > - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a > downstream patch in SoftHSM? Do we have enough expertise to implement it > correctly? > - Hack it around #2: Implement raw key extraction from SoftHSM and do > key wrapping somehow somewhere? (Please nooooooo.) > > > Symmetric keys > ============== > should be stored in 'ipaSecretKey' attribute but detailed storage format > definition is missing from schema [1] right now. I thought we already agreed on using raw encrypted blob. > > Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with > asymmetric key as *wrapping* key so we need to add this functionality. > > The first question is: > What algorithm and padding scheme should we use? I guess PKCS#1 RSA or PKCS#1 RSA OAEP. > > Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be > relatively easy to implement to SoftHSM because it is already there, > just not handled in C_WrapKey (so we need to add appropriate 'glue' there). > > Another question is storage format of the wrapped key. > PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" > algorithm: > "For wrapping, the ?input? to the encryption operation is the value of > the CKA_VALUE attribute of the key that is wrapped; similarly for > unwrapping. The mechanism does not wrap the key type or any other > information about the key, except the key length; the application must > convey these separately." > > AFAIK it means that it wraps raw secret key and nothing else. If I'm not > wrong we should be able to take resulting blob and stick it into > OneSymmetricKey structure from RFC 6031 [5]. Honza, is it correct > assumption/idea? What is the benefit of using OneSymmetricKey here? There is no wrapping algorithm identifier as in EncryptedPrivateKeyInfo and the whole thing looks very PSKC-specific. > > > I would really appreciate any suggestions or comments on this. > > Thank you for your time. > > [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html > [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 > [2] http://tools.ietf.org/html/rfc5958#section-3 > [3] http://rt.openssl.org/Ticket/Display.html?id=2204 > [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 > [5] https://tools.ietf.org/html/rfc6031#section-2 > [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html > [7] > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 > > -- Jan Cholasta From jcholast at redhat.com Tue Jun 24 09:30:47 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Jun 2014 11:30:47 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53A80905.1060706@redhat.com> References: <52A0817E.2080002@redhat.com> <1389276739.26102.215.camel@willson.li.ssimo.org> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> <539EE99C.5010909@redhat.com> <539EFA64.3020005@redhat.com> <53A18173.6060903@redhat.com> <53A80905.1060706@redhat.com> Message-ID: <53A94547.9040608@redhat.com> On 23.6.2014 13:01, Martin Kosek wrote: > On 06/18/2014 02:09 PM, Jan Cholasta wrote: > ... >>>>> 3) I am thinking why do we need to introduce all the ASN parsing? I am talking >>>>> about _decode_krb5principalname and others. If we do not use the result >>>>> anywhere, why should we include this part at all? >>>> >>>> To work around shortcomings of NSS/python-nss. In particular, >>>> _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a string. >>>> This is necessary because certmonger puts such SANs in certificate requests it >>>> generates. >>> >>> I know, but we do not use the values besides DNS SAN type, right? I was just >>> afraid that a decode error in a decoding of an unused SAN type would cause the >>> entire CSR processing to crash. >> >> If we do not allow principal name SANs, requests from certmonger will fail. If >> we allow them, but ignore them, you could request a certificate for an >> arbitrary unrelated principal. Thus, the only thing we can do is allow them and >> validate them, which is what the patch does and why decoding KRB5PrincipalName >> is necessary. > > True, we need to make sure the principal type SANs match. ack on the intent. > >>>>> 4) I get crash in the certmonger request: >>>>> >>>>> ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g 2048 -r >>>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>>> test2.example.com >>>>> -E mkosek at redhat.com >>>>> >>>>> # ipa-getcert list -i test-san-1 >>>>> Number of certificates and requests being tracked: 8. >>>>> Request ID 'test-san-1': >>>>> status: CA_UNREACHABLE >>>>> ca-error: Server failed request, will retry: -504 (HTTP response code is >>>>> 500, >>>>> not 200). >>>>> stuck: yes >>>>> >>>>> >>>>> HTTPD traceback >>>>> [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote > ... >>>>> PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in asn1Spec: >>>>> _GeneralName() >>>> >>>> What version of certmonger are you using? >>> >>> Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access >>> to my VM atm). Is this a bug in certmonger? >> >> No, it's bug in my code. Fixed. > > Works. > >> Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was >> hitting with patch 234. >> >> Updated patches attached. >> > > Thanks. Functionally, the patch looks ok to me, we are close to final ack. Just > couple more minor changes need to happen: > > 1) We decided to drop ipaVirtualOperation concept in the end and allow people > reading this list. This implies following changes: > > 234 - drop ipaVirtualOperation from cn=request certificate with > subjectaltname,cn=virtual operations,cn=etc,$SUFFIX > 300 - drop the entire patch (sorry) OK. > > 2) I would like to have more confidence that no unauthorized SAN extension gets > in. I know we have the > > + for name_type, name in subjectaltname: > + if name_type not in (pkcs10.SAN_DNSNAME, > > loop, but I would also like to add "else" path to the SAN type validation loop, > in case somebody just expands the part above, but forgot to also add > validation. I want us to be explicit in this case: > > + for name_type, name in subjectaltname: > + if name_type == pkcs10.SAN_DNSNAME: > ... > + elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, > + pkcs10.SAN_OTHERNAME_UPN): > ... >> else: >> raise errors.ACIError(info=_( >> "Unauthorized subject alt name '%s'.") % name) > Fixed. > > When this is fixed, we should be done. > > Thanks, > Martin > Updated and rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-210.8-Allow-SAN-in-IPA-certificate-profile.patch Type: text/x-patch Size: 5003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-234.8-Support-requests-with-SAN-in-cert-request.patch Type: text/x-patch Size: 16101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-301.1-Remove-GetEffectiveRights-control-when-ldap2.get_eff.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 24 09:49:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 11:49:11 +0200 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> Message-ID: <53A94997.1050103@redhat.com> On 23.6.2014 17:49, Martin Basti wrote: > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: >> Hello, >> I have following issues: >> >> #1 Upgrading existing replicas to support DNSSEC won't work for current >> design (replica-file as storage for temporal replica key). >> Temporal private key needs to be copied to replica, and no encrypted >> master-key for replica is prepared in LDAP, because user doesn't need to >> run ipa-replica-prepare. >> >> After discussion with Petr2, the solution is: >> a) Each replica (except first - which generates master-key) generates >> replica public and private keys. >> b) Replica uploads public key to LDAP >> c) Replica with generated master key, use the public key (b) to encrypt >> master-key and store it to LDAP. Replica with master-key must detect, if >> there is any new public replica key. >> d) Replica (b) is now able to get master-key using own private replica >> key >> >> >> #2 We need to choose only one replica which will generate, (rotate, ...) >> DNSSEC keys. > and generate master key too > >> My proposal is to test during installation/upgrade if any dnssec/master >> keys are in LDAP. If no key was found, the first server is >> installed/upgraded and DNSSEC key generator is required. >> >> But there is issue with parallel upgrade multiple replicas (or if >> replication temporarily doesn't work). There is no guarantee if replicas >> will be able to detect if any replica became DNSSEC key generator. Let me add that we are going to use syncrepl anyway so the overall latency should be minimal (if replication works). -- Petr^2 Spacek From mkosek at redhat.com Tue Jun 24 10:12:24 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 12:12:24 +0200 Subject: [Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile In-Reply-To: <53A94547.9040608@redhat.com> References: <52A0817E.2080002@redhat.com> <52CEB1B7.8050306@redhat.com> <52CEC3EA.7040401@redhat.com> <1389282598.26102.230.camel@willson.li.ssimo.org> <52CFE8BC.8010201@redhat.com> <52D9084B.20702@redhat.com> <52DCF568.9000508@redhat.com> <1390232170.2370.60.camel@willson.li.ssimo.org> <52DD5386.2090903@redhat.com> <1390239355.2370.72.camel@willson.li.ssimo.org> <52DE6FE6.5020901@redhat.com> <1390320748.15404.6.camel@willson.li.ssimo.org> <52DF9201.6090806@redhat.com> <1390401263.15404.37.camel@willson.li.ssimo.org> <52DFDE4B.5090401@redhat.com> <1390405407.15404.58.camel@willson.li.ssimo.org> <52E11A60.10901@redhat.com> <53919D09.20302@redhat.com> <5396B9E5.4050605@redhat.com> <53981A45.9090108@redhat.com> <53983D96.5080604@redhat.com> <539852A2.6040109@redhat.com> <539ED57F.4070402@redhat.com> <539EE99C.5010909@redhat.com> <539EFA64.3020005@redhat.com> <53A18173.6060903@redhat.com> <53A80905.1060706@redhat.com> <53A94547.9040608@redhat.com> Message-ID: <53A94F08.4090802@redhat.com> On 06/24/2014 11:30 AM, Jan Cholasta wrote: > On 23.6.2014 13:01, Martin Kosek wrote: >> On 06/18/2014 02:09 PM, Jan Cholasta wrote: >> ... >>>>>> 3) I am thinking why do we need to introduce all the ASN parsing? I am >>>>>> talking >>>>>> about _decode_krb5principalname and others. If we do not use the result >>>>>> anywhere, why should we include this part at all? >>>>> >>>>> To work around shortcomings of NSS/python-nss. In particular, >>>>> _decode_krb5principalname is used to decode KRB5PrincipalName SANs to a >>>>> string. >>>>> This is necessary because certmonger puts such SANs in certificate >>>>> requests it >>>>> generates. >>>> >>>> I know, but we do not use the values besides DNS SAN type, right? I was just >>>> afraid that a decode error in a decoding of an unused SAN type would cause the >>>> entire CSR processing to crash. >>> >>> If we do not allow principal name SANs, requests from certmonger will fail. If >>> we allow them, but ignore them, you could request a certificate for an >>> arbitrary unrelated principal. Thus, the only thing we can do is allow them and >>> validate them, which is what the patch does and why decoding KRB5PrincipalName >>> is necessary. >> >> True, we need to make sure the principal type SANs match. ack on the intent. >> >>>>>> 4) I get crash in the certmonger request: >>>>>> >>>>>> ipa-getcert request -d /etc/pki/nssdb/ -n test-san-1 -I test-san-1 -g >>>>>> 2048 -r >>>>>> -N "cn=`hostname`" -K host/`hostname` -D test1.example.com -D >>>>>> test2.example.com >>>>>> -E mkosek at redhat.com >>>>>> >>>>>> # ipa-getcert list -i test-san-1 >>>>>> Number of certificates and requests being tracked: 8. >>>>>> Request ID 'test-san-1': >>>>>> status: CA_UNREACHABLE >>>>>> ca-error: Server failed request, will retry: -504 (HTTP response >>>>>> code is >>>>>> 500, >>>>>> not 200). >>>>>> stuck: yes >>>>>> >>>>>> >>>>>> HTTPD traceback >>>>>> [Mon Jun 16 13:06:14.528642 2014] [:error] [pid 12941] [remote >> ... >>>>>> PyAsn1Error: TagSet(Tag(tagClass=128, tagFormat=0, tagId=2)) not in >>>>>> asn1Spec: >>>>>> _GeneralName() >>>>> >>>>> What version of certmonger are you using? >>>> >>>> Latest Fedora 20, i.e. should be certmonger-0.71.2-1.fc20 (do not have access >>>> to my VM atm). Is this a bug in certmonger? >>> >>> No, it's bug in my code. Fixed. >> >> Works. >> >>> Also added patch 301 which fixes a bug in ldap2.get_effective_rights I was >>> hitting with patch 234. >>> >>> Updated patches attached. >>> >> >> Thanks. Functionally, the patch looks ok to me, we are close to final ack. Just >> couple more minor changes need to happen: >> >> 1) We decided to drop ipaVirtualOperation concept in the end and allow people >> reading this list. This implies following changes: >> >> 234 - drop ipaVirtualOperation from cn=request certificate with >> subjectaltname,cn=virtual operations,cn=etc,$SUFFIX >> 300 - drop the entire patch (sorry) > > OK. > >> >> 2) I would like to have more confidence that no unauthorized SAN extension gets >> in. I know we have the >> >> + for name_type, name in subjectaltname: >> + if name_type not in (pkcs10.SAN_DNSNAME, >> >> loop, but I would also like to add "else" path to the SAN type validation loop, >> in case somebody just expands the part above, but forgot to also add >> validation. I want us to be explicit in this case: >> >> + for name_type, name in subjectaltname: >> + if name_type == pkcs10.SAN_DNSNAME: >> ... >> + elif name_type in (pkcs10.SAN_OTHERNAME_KRB5PRINCIPALNAME, >> + pkcs10.SAN_OTHERNAME_UPN): >> ... >>> else: >>> raise errors.ACIError(info=_( >>> "Unauthorized subject alt name '%s'.") % name) >> > > Fixed. > >> >> When this is fixed, we should be done. >> >> Thanks, >> Martin >> > > Updated and rebased patches attached. > This looks good. We can finally push this beast. Note that we should also add proper tests in future exercising the new functionality. ACK. Pushed to master: 8b8774d138348ab4b938f98dc106ea983e261262 Martin From pviktori at redhat.com Tue Jun 24 10:27:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Jun 2014 12:27:25 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A84CF4.8090501@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> <53A824CD.2040400@redhat.com> <53A84CF4.8090501@redhat.com> Message-ID: <53A9528D.6090109@redhat.com> On 06/23/2014 05:51 PM, Martin Kosek wrote: > On 06/23/2014 02:59 PM, Petr Viktorin wrote: >> On 06/23/2014 10:07 AM, Martin Kosek wrote: >>> On 06/20/2014 11:17 PM, Martin Kosek wrote: >>>> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>>>> All these should be independent, except for conflicts in ACI.txt that are >>>>> easily solved by running makeaci. >>>> >>>> Umh, now the fun begins as I see :) There will probably need to be some rebase, >>>> it clashed with some other ACI patches in my tree (namely Hosts which I acked). >> >> Rebased on top of my patch 0607, please apply that first. >> >> Added a new patch, 0608, which adds missing write permissions. >> >> >>>> 594: we miss permissions for Automount Locations. Permissions for keys&maps >>>> look ok. >> >> Added in 0608. >> >>>> >>>> 595: "System: Modify Group Membership" is probably waiting for the group >>>> objectclass fix - the filter is different. Otherwise it looks ok. >> >> Right; rebased. >> >>>> 596-598: HBAC is ok >>>> >>>> 599: hostgroup is OK >>>> >>>> 600: there must have been some DS problem on my side as my regular user could >>>> not see any netgroup >> >> The problem is a bit closer to home this time. >> Fixed in patch 0607. >> >>>> 601: privileges - we miss CRUD ACIs >> >> Added in 0608. >> >> We also miss CRUD permissions on permissions, but since currently these need >> pretty much unlimited access to ACIs, it's better to keep them admin-only. >> >>>> 602: roles were ok >>>> >>>> 603: ok >>>> >>>> I got this far today, the rest will need to wait for the next week. >>> >>> 604: ok, I was able to create a service, get a keytab >>> >>> 605: Should we case the permissions as "Sudo Command instead of "Sudo command"? >> >> Yes, fixed >> >>> 606: we also miss Modify Sudo Command permission so that people can modify >>> description. Otherwise ok. >> >> Added in 0608. >> >> > > 1) # ipa-server-install: > ... > Applying LDAP updates > ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing > required attribute "objectclass" > ... > > There is a problem in this pending update: > > dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX > add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' > > You apparently also need to make this permission also a member of "Modify Group > membership" privilege. Fixed, thank you. > 2) We may not need "System: Modify Automount Locations" as there is just the CN > and we do not support renames in automountlocation API. I am not insisting. Removed. > When these 2 issues are resolved, we can push. I've also added a patch that fixes a permission-find test which assumed there are many old permissions. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0594.3-Convert-Automount-default-permissions-to-managed.patch Type: text/x-patch Size: 16366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0595.3-Convert-Group-default-permissions-to-managed.patch Type: text/x-patch Size: 12821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0596.3-Convert-HBAC-Rule-default-permissions-to-managed.patch Type: text/x-patch Size: 9552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0597.3-Convert-HBAC-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 6264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0598.3-Convert-HBAC-Service-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0599.3-Convert-Hostgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 8847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0600.3-Convert-Netgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 9239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0601.3-Convert-the-Modify-privilege-membership-permission-t.patch Type: text/x-patch Size: 4658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0602.3-Convert-Role-default-permissions-to-managed.patch Type: text/x-patch Size: 8689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0603.3-Convert-SELinux-User-Map-default-permissions-to-mana.patch Type: text/x-patch Size: 7888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0604.3-Convert-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 8890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0605.3-Convert-Sudo-Command-default-permissions-to-managed.patch Type: text/x-patch Size: 8615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0606.3-Convert-Sudo-Command-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0608.3-Add-several-CRUD-default-permissions.patch Type: text/x-patch Size: 9937 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0609.3-test_permission_plugin-Fix-permission_find-test-for-.patch Type: text/x-patch Size: 1227 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 24 10:35:36 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 12:35:36 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A9528D.6090109@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> <53A824CD.2040400@redhat.com> <53A84CF4.8090501@redhat.com> <53A9528D.6090109@redhat.com> Message-ID: <53A95478.3010200@redhat.com> On 06/24/2014 12:27 PM, Petr Viktorin wrote: > On 06/23/2014 05:51 PM, Martin Kosek wrote: >> On 06/23/2014 02:59 PM, Petr Viktorin wrote: >>> On 06/23/2014 10:07 AM, Martin Kosek wrote: >>>> On 06/20/2014 11:17 PM, Martin Kosek wrote: >>>>> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>>>>> All these should be independent, except for conflicts in ACI.txt that are >>>>>> easily solved by running makeaci. >>>>> >>>>> Umh, now the fun begins as I see :) There will probably need to be some >>>>> rebase, >>>>> it clashed with some other ACI patches in my tree (namely Hosts which I >>>>> acked). >>> >>> Rebased on top of my patch 0607, please apply that first. >>> >>> Added a new patch, 0608, which adds missing write permissions. >>> >>> >>>>> 594: we miss permissions for Automount Locations. Permissions for keys&maps >>>>> look ok. >>> >>> Added in 0608. >>> >>>>> >>>>> 595: "System: Modify Group Membership" is probably waiting for the group >>>>> objectclass fix - the filter is different. Otherwise it looks ok. >>> >>> Right; rebased. >>> >>>>> 596-598: HBAC is ok >>>>> >>>>> 599: hostgroup is OK >>>>> >>>>> 600: there must have been some DS problem on my side as my regular user could >>>>> not see any netgroup >>> >>> The problem is a bit closer to home this time. >>> Fixed in patch 0607. >>> >>>>> 601: privileges - we miss CRUD ACIs >>> >>> Added in 0608. >>> >>> We also miss CRUD permissions on permissions, but since currently these need >>> pretty much unlimited access to ACIs, it's better to keep them admin-only. >>> >>>>> 602: roles were ok >>>>> >>>>> 603: ok >>>>> >>>>> I got this far today, the rest will need to wait for the next week. >>>> >>>> 604: ok, I was able to create a service, get a keytab >>>> >>>> 605: Should we case the permissions as "Sudo Command instead of "Sudo >>>> command"? >>> >>> Yes, fixed >>> >>>> 606: we also miss Modify Sudo Command permission so that people can modify >>>> description. Otherwise ok. >>> >>> Added in 0608. >>> >>> >> >> 1) # ipa-server-install: >> ... >> Applying LDAP updates >> ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing >> required attribute "objectclass" >> ... >> >> There is a problem in this pending update: >> >> dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX >> add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' >> >> You apparently also need to make this permission also a member of "Modify Group >> membership" privilege. > > Fixed, thank you. > >> 2) We may not need "System: Modify Automount Locations" as there is just the CN >> and we do not support renames in automountlocation API. I am not insisting. > > Removed. > >> When these 2 issues are resolved, we can push. > > I've also added a patch that fixes a permission-find test which assumed there > are many old permissions. Are you sure you tested the patches? 1) This change in 595 looks suspicious: dn: $SUFFIX -# Don't allow the default 'manage group membership' to be able to manage the -# admins group -replace:aci:'(targetattr = "member")(target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX";)::(targetfilter = "(!(cn=admins))")(targetattr = "member")(target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX";)' It lefts the update file with dn: $SUFFIX dn: cn=ipa,cn=etc,$SUFFIX add:aci:'(target = "ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "Add CA Certific ... 2) About patch 609.3 - this test still looks very fragile. It would break just with adding one more permission to SUFFIX. Martin From pvoborni at redhat.com Tue Jun 24 11:02:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 13:02:40 +0200 Subject: [Freeipa-devel] [PATCH] 670-675 webui: dns forward zones Message-ID: <53A95AD0.5060905@redhat.com> ticket: https://fedorahosted.org/freeipa/ticket/4357 - patch 673 is compressed - CI patches functionally depends on #667, #668 == PATCH] 670 webui: add confirmation for dns zone permission actions == All header actions should require confirmation. == [PATCH] 671 webui: dns forward zones == Add DNS Forward Zones Web UI. - pages under: Identity/DNS/DNS Forward Zones == [PATCH] 672 webui-ci: dns forward zone tests == Selenium CI sanity tests for DNS Forward Zones == [PATCH] 673 webui-test: static metadata update == Regular update of static metadata for testing and presentation purposes. It should also contain new DNS Forward Zones metadata. == [PATCH] 674 webui-test: dns forward zone json data == Fake API results for testing and presentation purposes of DNS Forward Zones. == [PATCH] 675 webui: fix detection of RPC command == old detection did not work with the static version used for test and demonstration purposes. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0675-webui-fix-detection-of-RPC-command.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0674-webui-test-dns-forward-zone-json-data.patch Type: text/x-patch Size: 7177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0672-webui-ci-dns-forward-zone-tests.patch Type: text/x-patch Size: 3213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0671-webui-dns-forward-zones.patch Type: text/x-patch Size: 7989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0670-webui-add-confirmation-for-dns-zone-permission-actio.patch Type: text/x-patch Size: 4729 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0673-webui-test-static-metadata-update.patch.tar.gz Type: application/gzip Size: 52846 bytes Desc: not available URL: From pviktori at redhat.com Tue Jun 24 11:26:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Jun 2014 13:26:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A95478.3010200@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> <53A824CD.2040400@redhat.com> <53A84CF4.8090501@redhat.com> <53A9528D.6090109@redhat.com> <53A95478.3010200@redhat.com> Message-ID: <53A96060.1040400@redhat.com> On 06/24/2014 12:35 PM, Martin Kosek wrote: > On 06/24/2014 12:27 PM, Petr Viktorin wrote: >> On 06/23/2014 05:51 PM, Martin Kosek wrote: >>> On 06/23/2014 02:59 PM, Petr Viktorin wrote: >>>> On 06/23/2014 10:07 AM, Martin Kosek wrote: >>>>> On 06/20/2014 11:17 PM, Martin Kosek wrote: >>>>>> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>>>>>> All these should be independent, except for conflicts in ACI.txt that are >>>>>>> easily solved by running makeaci. >>>>>> >>>>>> Umh, now the fun begins as I see :) There will probably need to be some >>>>>> rebase, >>>>>> it clashed with some other ACI patches in my tree (namely Hosts which I >>>>>> acked). >>>> >>>> Rebased on top of my patch 0607, please apply that first. >>>> >>>> Added a new patch, 0608, which adds missing write permissions. >>>> >>>> >>>>>> 594: we miss permissions for Automount Locations. Permissions for keys&maps >>>>>> look ok. >>>> >>>> Added in 0608. >>>> >>>>>> >>>>>> 595: "System: Modify Group Membership" is probably waiting for the group >>>>>> objectclass fix - the filter is different. Otherwise it looks ok. >>>> >>>> Right; rebased. >>>> >>>>>> 596-598: HBAC is ok >>>>>> >>>>>> 599: hostgroup is OK >>>>>> >>>>>> 600: there must have been some DS problem on my side as my regular user could >>>>>> not see any netgroup >>>> >>>> The problem is a bit closer to home this time. >>>> Fixed in patch 0607. >>>> >>>>>> 601: privileges - we miss CRUD ACIs >>>> >>>> Added in 0608. >>>> >>>> We also miss CRUD permissions on permissions, but since currently these need >>>> pretty much unlimited access to ACIs, it's better to keep them admin-only. >>>> >>>>>> 602: roles were ok >>>>>> >>>>>> 603: ok >>>>>> >>>>>> I got this far today, the rest will need to wait for the next week. >>>>> >>>>> 604: ok, I was able to create a service, get a keytab >>>>> >>>>> 605: Should we case the permissions as "Sudo Command instead of "Sudo >>>>> command"? >>>> >>>> Yes, fixed >>>> >>>>> 606: we also miss Modify Sudo Command permission so that people can modify >>>>> description. Otherwise ok. >>>> >>>> Added in 0608. >>>> >>>> >>> >>> 1) # ipa-server-install: >>> ... >>> Applying LDAP updates >>> ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing >>> required attribute "objectclass" >>> ... >>> >>> There is a problem in this pending update: >>> >>> dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX >>> add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' >>> >>> You apparently also need to make this permission also a member of "Modify Group >>> membership" privilege. >> >> Fixed, thank you. >> >>> 2) We may not need "System: Modify Automount Locations" as there is just the CN >>> and we do not support renames in automountlocation API. I am not insisting. >> >> Removed. >> >>> When these 2 issues are resolved, we can push. >> >> I've also added a patch that fixes a permission-find test which assumed there >> are many old permissions. > > Are you sure you tested the patches? Yes. Not enough, I'm sure, but I did test them... > 1) This change in 595 looks suspicious: > > dn: $SUFFIX > -# Don't allow the default 'manage group membership' to be able to manage the > -# admins group > -replace:aci:'(targetattr = "member")(target = > "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify > Group membership,cn=permissions,cn=pbac,$SUFFIX";)::(targetfilter = > "(!(cn=admins))")(targetattr = "member")(target = > "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify > Group membership,cn=permissions,cn=pbac,$SUFFIX";)' > > It lefts the update file with > dn: $SUFFIX > dn: cn=ipa,cn=etc,$SUFFIX > add:aci:'(target = "ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX")(version > 3.0; acl "Add CA Certific > ... Right. (It's removed in one of the later patches, so I didn't catch it.) > 2) About patch 609.3 - this test still looks very fragile. It would break just > with adding one more permission to SUFFIX. It follows the general style of declarative tests, which depend on a freshly installed system. I think it's a good test to have around, at least until there's a better suite for permission-find on legacy permissions. > > Martin > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0594.4-Convert-Automount-default-permissions-to-managed.patch Type: text/x-patch Size: 16366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0595.4-Convert-Group-default-permissions-to-managed.patch Type: text/x-patch Size: 12834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0596.4-Convert-HBAC-Rule-default-permissions-to-managed.patch Type: text/x-patch Size: 9552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0597.4-Convert-HBAC-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 6264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0598.4-Convert-HBAC-Service-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0599.4-Convert-Hostgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 8847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0600.4-Convert-Netgroup-default-permissions-to-managed.patch Type: text/x-patch Size: 9239 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0601.4-Convert-the-Modify-privilege-membership-permission-t.patch Type: text/x-patch Size: 4658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0602.4-Convert-Role-default-permissions-to-managed.patch Type: text/x-patch Size: 8689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0603.4-Convert-SELinux-User-Map-default-permissions-to-mana.patch Type: text/x-patch Size: 8114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0604.4-Convert-Service-default-permissions-to-managed.patch Type: text/x-patch Size: 8890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0605.4-Convert-Sudo-Command-default-permissions-to-managed.patch Type: text/x-patch Size: 8615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0606.4-Convert-Sudo-Command-Group-default-permissions-to-ma.patch Type: text/x-patch Size: 6719 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0607.4-Add-several-CRUD-default-permissions.patch Type: text/x-patch Size: 9937 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0608.4-test_permission_plugin-Fix-permission_find-test-for-.patch Type: text/x-patch Size: 1227 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jun 24 11:49:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 13:49:56 +0200 Subject: [Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible In-Reply-To: <53A85763.4050802@redhat.com> References: <538473E0.6070702@redhat.com> <5399C659.30109@redhat.com> <53A173CB.3060203@redhat.com> <53A45EF1.6080209@redhat.com> <53A82882.8070302@redhat.com> <53A85763.4050802@redhat.com> Message-ID: <53A965E4.4050509@redhat.com> On 23.6.2014 18:35, Endi Sukma Dewata wrote: > On 6/23/2014 8:15 AM, Petr Vobornik wrote: >>> 1. I'm not sure if we really need a HashCreator. Ideally the router >>> should map a hash to a page. Links to another page can be hardcoded too >>> (and substitute the parameters). >> >> The main purpose of a hash creator is to update hash when a facet state >> changes. This change can be initiated from the facet itself, e.g. when >> searching in a search facet. Removing the hash creator would make facets >> dependent on navigation specifics. > > I was thinking if the facet itself is changing the state, it will only > change the query part of the URL. The base facet URL itself is assigned > by the router. I think we used to put all UI states in the URL so that's > why we needed a hash creator. My thinking was that the facet shouldn't be even aware of the hash or routing. > >> I would agree if it was related only to links. But even then it would be >> better to have a method which would create the hash (for the one which >> shares the same pattern) to reduce code reuse. In any case, it's >> possible to hardcode hash parts in links if one needs to. > > It's more about removing dependencies between pages. For example, to > link from one page to another we use something like this: > > navigation.show_entity(entity.name, facetname, [pkey]); > > This means we're explicitly handling the link. And this also puts > additional restrictions such as the target page must be an entity page > which has one level sub page called 'facetname' that takes one primary > key. If the target page is not an entity page we'd have to use a > different method. > > I think it would be cleaner if the link can be defined in a (future) > template like this: > > > How is this different? You still have to pass the entity, facet name and pkey. You just moved the logic form hash creator to the template. And I can bet that doing something more difficult there will be a pain. Also it doesn't work for redirection initiated by other means then a link, e.g., when something gets deleted. If one wants to create a link in a template he could use some link helper which would internally call the hash creator. > Note that the template is used to generate the links only. When the user > clicks the link we rely on the browser, or other routing libraries, to > handle it so less code to maintain and it puts the UI workflow in the > hands of UI designers. Keeping facet and widget internals out of direct hash modification allows to embed the whole app or just some parts of it into other app. Or we can have two different or same facets displayed next to each other. Atm this is not an argument since we do not make it with this use case in mind. The same applies for code modifications by designers. > >>> 2. Ideally there should be no entity-specific navigation code. All >>> routing should be handled in a generic way. This probably depends on the >>> entity-facet separation that we discussed previously. So routes like >>> this: >>> >>> /e/:entity/:facet/:pkeys/*args >>> >>> should be replaced by individual routes for each entity: >>> >>> /user/:facet/:pkeys/*args >>> /group/:facet/:pkeys/*args >> >> Yes, but IMHO the hash prefix is a detail. It would be more important if >> it would be a REST API where it's a core aspect. > > Right, a REST URL probably would look like: > > /ipa/ui/users/{facet}/{pkey}?{query} > > And ideally if you open a REST URL in a browser you should get a UI. So > anything that brings the UI closer to this would be great. > >>> 4. The args/query in the navigation paths should be separated by a more >>> standard delimiter "?" instead of "//". For example: >>> >>> /ipa/ui/#/e/user/search//filter=test >>> >>> should be replaced with: >>> >>> /ipa/ui/#/e/user/search?filter=test >> >> note that // is a result of /:pkeys/, where :pkeys is '' Therefore a >> simple replacement would lead to >> /ipa/ui/#/e/user/search/?filter=test >> >> Please file a ticket, if you think it's important. > > I was originally thinking this to be a way to mimic the REST URL, but > now I'm not sure if it would interfere with URL parsing because in this > case the ? will be part of the URL hash, not URL query, so maybe we > should just leave it for now. > >> Lets say that we would implement #2 and #4. Would we also want to keep >> the old routes for backwards compatibility? (main purpose of hashes is >> to make the page bookmarkable). IMHO people don't care about #2 and #4 >> much, but they care about broken bookmarks. > > The hashes are probably more useful to make the browser's Back button > functional. Bookmarking is probably a secondary benefit, but are there > pages in the UI that people would likely to bookmark? An admin probably > would just bookmark the main URL, not a particular page in the UI. > Backward compatibility of routing is nice, but I don't think it's a hard > requirement. > -- Petr Vobornik From pviktori at redhat.com Tue Jun 24 12:03:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Jun 2014 14:03:32 +0200 Subject: [Freeipa-devel] [PATCH] [WIP] ipatest/util: Use YAML-diff for reporting differences in assert_deepequal Message-ID: <53A96914.8060708@redhat.com> Hello, With this patch applied and python-PyYAML installed, failed declarative tests will output a diff between the full expected/got structures, so you can see all the context and all the differences at once. (I use YAML because it diffs very nicely, at least with the options used here.) It's a hack/proof of concept, but I tried extra hard ensure it passes/fails in the same cases as the original assert_deepequal. If you don't have python-PyYAML installed, the original assert_deepequal is used. Feel free to use it if it helps. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0608-WIP-ipatest-util-Use-YAML-diff-for-reporting-differe.patch Type: text/x-patch Size: 10084 bytes Desc: not available URL: From mkosek at redhat.com Tue Jun 24 12:04:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 14:04:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0594-0606 Convert default permissions to managed In-Reply-To: <53A96060.1040400@redhat.com> References: <53A44E09.8010300@redhat.com> <53A4A4E9.9070304@redhat.com> <53A7E03C.7020101@redhat.com> <53A824CD.2040400@redhat.com> <53A84CF4.8090501@redhat.com> <53A9528D.6090109@redhat.com> <53A95478.3010200@redhat.com> <53A96060.1040400@redhat.com> Message-ID: <53A9693F.80600@redhat.com> On 06/24/2014 01:26 PM, Petr Viktorin wrote: > On 06/24/2014 12:35 PM, Martin Kosek wrote: >> On 06/24/2014 12:27 PM, Petr Viktorin wrote: >>> On 06/23/2014 05:51 PM, Martin Kosek wrote: >>>> On 06/23/2014 02:59 PM, Petr Viktorin wrote: >>>>> On 06/23/2014 10:07 AM, Martin Kosek wrote: >>>>>> On 06/20/2014 11:17 PM, Martin Kosek wrote: >>>>>>> On 06/20/2014 05:06 PM, Petr Viktorin wrote: >>>>>>>> All these should be independent, except for conflicts in ACI.txt that are >>>>>>>> easily solved by running makeaci. >>>>>>> >>>>>>> Umh, now the fun begins as I see :) There will probably need to be some >>>>>>> rebase, >>>>>>> it clashed with some other ACI patches in my tree (namely Hosts which I >>>>>>> acked). >>>>> >>>>> Rebased on top of my patch 0607, please apply that first. >>>>> >>>>> Added a new patch, 0608, which adds missing write permissions. >>>>> >>>>> >>>>>>> 594: we miss permissions for Automount Locations. Permissions for keys&maps >>>>>>> look ok. >>>>> >>>>> Added in 0608. >>>>> >>>>>>> >>>>>>> 595: "System: Modify Group Membership" is probably waiting for the group >>>>>>> objectclass fix - the filter is different. Otherwise it looks ok. >>>>> >>>>> Right; rebased. >>>>> >>>>>>> 596-598: HBAC is ok >>>>>>> >>>>>>> 599: hostgroup is OK >>>>>>> >>>>>>> 600: there must have been some DS problem on my side as my regular user >>>>>>> could >>>>>>> not see any netgroup >>>>> >>>>> The problem is a bit closer to home this time. >>>>> Fixed in patch 0607. >>>>> >>>>>>> 601: privileges - we miss CRUD ACIs >>>>> >>>>> Added in 0608. >>>>> >>>>> We also miss CRUD permissions on permissions, but since currently these need >>>>> pretty much unlimited access to ACIs, it's better to keep them admin-only. >>>>> >>>>>>> 602: roles were ok >>>>>>> >>>>>>> 603: ok >>>>>>> >>>>>>> I got this far today, the rest will need to wait for the next week. >>>>>> >>>>>> 604: ok, I was able to create a service, get a keytab >>>>>> >>>>>> 605: Should we case the permissions as "Sudo Command instead of "Sudo >>>>>> command"? >>>>> >>>>> Yes, fixed >>>>> >>>>>> 606: we also miss Modify Sudo Command permission so that people can modify >>>>>> description. Otherwise ok. >>>>> >>>>> Added in 0608. >>>>> >>>>> >>>> >>>> 1) # ipa-server-install: >>>> ... >>>> Applying LDAP updates >>>> ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure missing >>>> required attribute "objectclass" >>>> ... >>>> >>>> There is a problem in this pending update: >>>> >>>> dn: cn=Modify Group membership,cn=permissions,cn=pbac,$SUFFIX >>>> add:member: 'cn=Modify Group membership,cn=privileges,cn=pbac,$SUFFIX' >>>> >>>> You apparently also need to make this permission also a member of "Modify >>>> Group >>>> membership" privilege. >>> >>> Fixed, thank you. >>> >>>> 2) We may not need "System: Modify Automount Locations" as there is just >>>> the CN >>>> and we do not support renames in automountlocation API. I am not insisting. >>> >>> Removed. >>> >>>> When these 2 issues are resolved, we can push. >>> >>> I've also added a patch that fixes a permission-find test which assumed there >>> are many old permissions. >> >> Are you sure you tested the patches? > > Yes. > Not enough, I'm sure, but I did test them... > >> 1) This change in 595 looks suspicious: >> >> dn: $SUFFIX >> -# Don't allow the default 'manage group membership' to be able to manage the >> -# admins group >> -replace:aci:'(targetattr = "member")(target = >> "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl >> "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify >> Group membership,cn=permissions,cn=pbac,$SUFFIX";)::(targetfilter = >> "(!(cn=admins))")(targetattr = "member")(target = >> "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl >> "permission:Modify Group membership";allow (write) groupdn = "ldap:///cn=Modify >> Group membership,cn=permissions,cn=pbac,$SUFFIX";)' >> >> It lefts the update file with >> dn: $SUFFIX >> dn: cn=ipa,cn=etc,$SUFFIX >> add:aci:'(target = "ldap:///cn=*,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX")(version >> 3.0; acl "Add CA Certific >> ... > > Right. (It's removed in one of the later patches, so I didn't catch it.) > >> 2) About patch 609.3 - this test still looks very fragile. It would break just >> with adding one more permission to SUFFIX. > > It follows the general style of declarative tests, which depend on a freshly > installed system. > I think it's a good test to have around, at least until there's a better suite > for permission-find on legacy permissions. Ok, as you wish. The patch set now looks good to me, tests are also good. ACK to all, I pushed them all to master. This pretty much concludes the ground work on permission/aci refactoring - good job Petr! :-) Martin From abokovoy at redhat.com Tue Jun 24 12:39:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Jun 2014 15:39:53 +0300 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1401801502.4161.7.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> Message-ID: <20140624123953.GX7233@redhat.com> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >> On 3.6.2014 05:08, Nathaniel McCallum wrote: >> > This command calls the token sync HTTP POST call in the server providing >> > the CLI interface to synchronization. >> > >> > https://fedorahosted.org/freeipa/ticket/4260 >> > >> > This patch depends on my patch #0055. >> > >> >> Build fails on validation. You forgot to update API.txt and also the >> command misses __doc__. >> >> (not a proper review) Failed for me: [root at ipa-01 rpms]# ipa otptoken-show test.token Unique ID: test.token Description: test token Owner: abbra Vendor: FreeIPA Model: hotp [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token Password: First Code: Second Code: ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', ) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, in execute result = self.Command[_name](*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", line 427, in forward rsp = urllib.urlopen(sync_uri, query) File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen return opener.open(url, data) File "/usr/lib64/python2.7/urllib.py", line 210, in open return getattr(self, name)(url, data) File "/usr/lib64/python2.7/urllib.py", line 454, in open_https data) File "/usr/lib64/python2.7/urllib.py", line 374, in http_error result = method(url, fp, errcode, errmsg, headers, data) File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 errcode, errmsg, headers) File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default raise IOError, ('http error', errcode, errmsg, headers) IOError: ('http error', 401, 'Unauthorized', ) ipa: ERROR: an internal error has occurred Note that I can successfully use the token. It looks like authentication with urllib.urlopen(sync_uri, query) fails. -- / Alexander Bokovoy From tbabej at redhat.com Tue Jun 24 12:50:32 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Jun 2014 14:50:32 +0200 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes Message-ID: <53A97418.7080302@redhat.com> Hi, this is a follow up patch for 232. Read access to additional attributes is required for the trust objects. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0233-trusts-Add-more-read-attributes.patch Type: text/x-patch Size: 2689 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jun 24 14:02:04 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 16:02:04 +0200 Subject: [Freeipa-devel] [PATCH] 676 rpcserver: fix local vs utc time comparison Message-ID: <53A984DC.3040609@redhat.com> login_password did not work properly in timezones other than +0h because local time was compared with utc time. Bug introduced in: https://fedorahosted.org/freeipa/ticket/4339 We should review other code for invalid usage of datetime.now() -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0676-rpcserver-fix-local-vs-utc-time-comparison.patch Type: text/x-patch Size: 1177 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jun 24 14:03:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 16:03:40 +0200 Subject: [Freeipa-devel] [PATCH] 632 webui: simplify self-service menu In-Reply-To: <5399A2AF.2090903@redhat.com> References: <5374C821.60004@redhat.com> <5397745F.3060100@redhat.com> <53983820.2040606@redhat.com> <5398730A.1010907@redhat.com> <5399A2AF.2090903@redhat.com> Message-ID: <53A9853C.6020700@redhat.com> On 12.6.2014 14:53, Endi Sukma Dewata wrote: > On 6/11/2014 10:17 AM, Endi Sukma Dewata wrote: >> On 6/11/2014 6:06 AM, Petr Vobornik wrote: >>>> 1. If I recall correctly, a new user is required to change the password >>>> upon the initial login. This can be done with kinit, but can this be >>>> done via UI too? Right now a new user will get a login error without >>>> any >>>> message or link to reset the password. >>> >>> It works for me. There was a ticket >>> https://fedorahosted.org/freeipa/ticket/4339 which corresponds to the >>> description. >>> >>> Or it could be related to: >>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=c41b782bc59cd0cb70cbd62d543f9c538109d410 >>> >>> >>> (if you use an IPA version before the revert) >> >> I just built the master yesterday. Let me see if I can reproduce it with >> a newer build. > > I'm still seeing the problem in the new build. Here are the steps to > reproduce: > 1. Login as admin. > 2. Add a new user with a password. > 3. Logout. > 4. Login as the new user. > > It will say "The password or username you entered is incorrect." There's > no message about expiration or link to change the password. So far the > only way to change the password is via kinit. > Found the culprit. It was caused by utc vs local time comparison. Patch #676 should fix it. -- Petr Vobornik From simo at redhat.com Tue Jun 24 14:14:10 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jun 2014 10:14:10 -0400 (EDT) Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <1403617556.20513.36.camel@vespa.frost.loc> References: <53A82440.30000@redhat.com> <1403617556.20513.36.camel@vespa.frost.loc> Message-ID: <941407471.29569527.1403619250063.JavaMail.zimbra@redhat.com> Tomas Mraz: > On, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: > > We need to wrap > > =============== > > - asymmetric key (zone key) with symmetric key (master key) > > - symmetric key (master key) with asymmetric key (replica key) > > Can you please provide more info what purpose these keys have? I > understand that the zone key is the DNSSEC asymmetric key for the zone. > But what about the master key and replica key? Why the master key is > symmetric and the replica asymmetric? What we want is the ability to store keys in LDAP so that multiple servers can generate DNSSEC keys. This allows no single points of failure, and also allows local servers to generate signatures for DNS names that may differ from replica to replica in the future (think things like views). In order to do that each DNS server need access to the Zone keys, but we do not want to distribute the unencrypted in LDAP. We also do not want to have to invent a parallel distribution method to send these keys to all the replicas that need them. We do have a private/public key pair on each replica though so we can use this fact to wrap a symmetric master key with all the public keys of the replicas that need access to the zone keys, and encrypt the zone keys with this master key. The reason to use a symmetric in the middle is that is allows for a few things: 1. it is easy to re-encrypt it t replica creation time by one of the other servers as soon as the replica is built and publishes its on key. This solves the distribution problem to new replicas. This same mechanism also allows to redistribute a new key if you need/want to rotate it for whatever reason. It also avoids the need to encrypt every zone private key multiple times with each replica public key, which would cause a lot of churn. HTH, Simo. From simo at redhat.com Tue Jun 24 14:30:54 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jun 2014 10:30:54 -0400 (EDT) Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <53A82440.30000@redhat.com> References: <53A82440.30000@redhat.com> Message-ID: <1447352013.29581232.1403620254135.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hello list, > > I'm working on key wrapping mechanism described in thread "LDAP schema for > DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would > really appreciate any suggestions or comments on this. > > - I have difficulties to pick and use proper wrapping mechanisms and their > configuration/usage patterns. > > - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose > of PKCS#11 by exporting raw keys from HSM. I can see his point and we should > be able to do all crypto operations inside SoftHSM. > > I have asked him to describe his doubts on freeipa-devel list - stay tuned. > > > We need to wrap > =============== > - asymmetric key (zone key) with symmetric key (master key) > - symmetric key (master key) with asymmetric key (replica key) > > LDAP schema prescribes some storage formats but my question is about crypto > algorithms (and padding!) used for key wrapping. It is important to get these details right indeed, we must be able to change crypto algorithms if needed in the future, so algorithm agility must be part of the story. > Asymmetric keys > =============== > According to schema [1] wrapped asymmetric (i.e. private) key must be stored > in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure > according to RFC 5958 [2]. > > It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part > of EncryptedPrivateKeyInfo structure so we only have to add algorithm > identifier, DER-encode the whole thing, and we could be done. Right. > I'm not sure where should I stick IV or what happens if default (fixed) IV > value is left in place...? We cannot use a fixed IV unless the wrapping algorithm uses an obfuscator within the data, otherwise you open yourself up for attacks. I expect the IV (if needed) to be provided by the SoftHSM itself ? If not something sounds broken. If the IV is fixed for some reason we culd provide the data with a secret confounder in the first block, but then we would not respect the standard in the first place. I will try to take a look at RFC 5958 once I am back at home tomorrow. > Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with > AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > > RFC 3394 works only on blocks of 64 bits, which is not our case because > EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > proper padding etc. We could also define how we generate padding ourselves if RFC 3394 is easier, although of course using RFC 5649 wuld be preferable rather than massaging the data ourselves. > And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but > OpenSSL doesn't support RFC 5649! The patch with this functionality was > submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state > "new" and there was no reply to the e-mail in the original thread [4]. > > What do we do? > - Convince OpenSSL to review and accept the patch? If we are using a standard this is not as important, we can make our own implementation and then work with the OpenSSL community to get a proper implementation in. Does NSS implements it btw ? > - Hack it around #0: Use something else as key wrapping method? Other > wrapping > methods would require SoftHSM modification because SoftHSM supports only AES > mechanisms now. > - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a > downstream > patch in SoftHSM? Do we have enough expertise to implement it correctly? > - Hack it around #2: Implement raw key extraction from SoftHSM and do key > wrapping somehow somewhere? (Please nooooooo.) No, let's use standards where they exist, it is ok to make our own implementation until upstream libraries finally get a good one, but let's avoid completely custom stuff. > Symmetric keys > ============== > should be stored in 'ipaSecretKey' attribute but detailed storage format > definition is missing from schema [1] right now. > > Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with > asymmetric key as *wrapping* key so we need to add this functionality. > > The first question is: > What algorithm and padding scheme should we use? We need algorithm agility here too, so I would use some generic envelope mechanism defined for encrypting data with asymetric keys and use it. If it is a good mechanism it will allow to use multiple algorithms and key sizes etc.. > Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively > easy to implement to SoftHSM because it is already there, just not handled in > C_WrapKey (so we need to add appropriate 'glue' there). I would not use something that ties us to RSA keys, it is probably highly desirable to use EC keys too as an alternative. > Another question is storage format of the wrapped key. > PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: > "For wrapping, the ?input? to the encryption operation is the value of the > CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The > mechanism does not wrap the key type or any other information about the key, > except the key length; the application must convey these separately." > > AFAIK it means that it wraps raw secret key and nothing else. If I'm not > wrong > we should be able to take resulting blob and stick it into OneSymmetricKey > structure from RFC 6031 [5]. Honza, is it correct assumption/idea? As long as we have a place to stick in what standard as used so we can change it if needs be then I do not have a strong preference. > I would really appreciate any suggestions or comments on this. > > Thank you for your time. > > [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html > [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 > [2] http://tools.ietf.org/html/rfc5958#section-3 > [3] http://rt.openssl.org/Ticket/Display.html?id=2204 > [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 > [5] https://tools.ietf.org/html/rfc6031#section-2 > [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html > [7] > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 From tmraz at redhat.com Tue Jun 24 13:45:56 2014 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 24 Jun 2014 15:45:56 +0200 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <53A82440.30000@redhat.com> References: <53A82440.30000@redhat.com> Message-ID: <1403617556.20513.36.camel@vespa.frost.loc> On Po, 2014-06-23 at 14:57 +0200, Petr Spacek wrote: > Hello list, > > I'm working on key wrapping mechanism described in thread "LDAP schema for > DNSSEC keys" [0] and I'm really puzzled from the maze of crypto here. I would > really appreciate any suggestions or comments on this. I am not sure I am able to respond to all of your questions and problems you're trying to solve but let's try at least some. > - I have difficulties to pick and use proper wrapping mechanisms and their > configuration/usage patterns. > > - Rick van Rein from OpenDNSSEC-user list noted that we are defeating purpose > of PKCS#11 by exporting raw keys from HSM. I can see his point and we should > be able to do all crypto operations inside SoftHSM. > > I have asked him to describe his doubts on freeipa-devel list - stay tuned. It is really questionable what are you trying to achieve here. I would definitely stay away from trying to replicate any back-up mechanisms that eventual HSM (software or hardware one) should have. This is all fairly non-trivial functionality and if any HSM implementation is serious enough it should have backup facility of its own (which should also allow duplicating such HSM if needed). Note that simply allowing to export wrapped key with a key you provide to HSM during a normal operation (not as a special privileged operation) is defeating the purpose of HSM anyway as you can unwrap the protected key as you wish. So the only wrapping key that can be used in normal operation should be a key that is preset or pre-generated in the HSM by the HSM admin. > > We need to wrap > =============== > - asymmetric key (zone key) with symmetric key (master key) > - symmetric key (master key) with asymmetric key (replica key) Can you please provide more info what purpose these keys have? I understand that the zone key is the DNSSEC asymmetric key for the zone. But what about the master key and replica key? Why the master key is symmetric and the replica asymmetric? > LDAP schema prescribes some storage formats but my question is about crypto > algorithms (and padding!) used for key wrapping. > > > Asymmetric keys > =============== > According to schema [1] wrapped asymmetric (i.e. private) key must be stored > in 'ipaPrivateKey' attribute as DER-encoded EncryptedPrivateKeyInfo structure > according to RFC 5958 [2]. > > It seem that SoftHSM's C_WrapKey PKCS#11 call will give us encryptedData part > of EncryptedPrivateKeyInfo structure so we only have to add algorithm > identifier, DER-encode the whole thing, and we could be done. > > I'm not sure where should I stick IV or what happens if default (fixed) IV > value is left in place...? In general using fixed IV when encrypting multiple data (keys) with the same key breaks the security of the wrapped data. So no, fixed IV must not be used. > > Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with > AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > > RFC 3394 works only on blocks of 64 bits, which is not our case because > EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > proper padding etc. > > And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but > OpenSSL doesn't support RFC 5649! The patch with this functionality was > submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state > "new" and there was no reply to the e-mail in the original thread [4]. I am sorry, but this does not make much sense to me. Iff the SoftHSM's C_WrapKey is really safe wrapping method for backing up and/or replicating HSM's it must provide wrapped key in such format that the IV is pregenerated as part of the Wrap operation and stored in the final blob of wrapped key. Unfortunately I do not know much of SoftHSM. > What do we do? > - Convince OpenSSL to review and accept the patch? I would say the patch is not too useful as is - there are multiple problems with it such as it is not using proper high level interfaces for the AES encryption, etc. > - Hack it around #0: Use something else as key wrapping method? Other wrapping > methods would require SoftHSM modification because SoftHSM supports only AES > mechanisms now. > - Hack it around #1: Implement the RFC 5649 wrapping algorithm in a downstream > patch in SoftHSM? Do we have enough expertise to implement it correctly? > - Hack it around #2: Implement raw key extraction from SoftHSM and do key > wrapping somehow somewhere? (Please nooooooo.) > > > Symmetric keys > ============== > should be stored in 'ipaSecretKey' attribute but detailed storage format > definition is missing from schema [1] right now. > > Unfortunately, SoftHSM doesn't support C_WrapKey PKCS#11 function with > asymmetric key as *wrapping* key so we need to add this functionality. > > The first question is: > What algorithm and padding scheme should we use? > > Something like OpenSSL's RSA_PKCS1_OAEP_PADDING [6]? That would be relatively > easy to implement to SoftHSM because it is already there, just not handled in > C_WrapKey (so we need to add appropriate 'glue' there). > > Another question is storage format of the wrapped key. > PKCS#11 2.40d2 [7] contains this comment about "PKCS #1 RSA OAEP" algorithm: > "For wrapping, the ?input? to the encryption operation is the value of the > CKA_VALUE attribute of the key that is wrapped; similarly for unwrapping. The > mechanism does not wrap the key type or any other information about the key, > except the key length; the application must convey these separately." > > AFAIK it means that it wraps raw secret key and nothing else. If I'm not wrong > we should be able to take resulting blob and stick it into OneSymmetricKey > structure from RFC 6031 [5]. Honza, is it correct assumption/idea? > > > I would really appreciate any suggestions or comments on this. > > Thank you for your time. > > [0] https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html > [1] http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data_2 > [2] http://tools.ietf.org/html/rfc5958#section-3 > [3] http://rt.openssl.org/Ticket/Display.html?id=2204 > [4] http://marc.info/?l=openssl-dev&m=126953517430167&w=2 > [5] https://tools.ietf.org/html/rfc6031#section-2 > [6] https://www.openssl.org/docs/crypto/RSA_public_encrypt.html > [7] > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd02/pkcs11-curr-v2.40-csprd02.html#_Toc387327841 > -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From mkosek at redhat.com Tue Jun 24 14:36:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 16:36:56 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53A98D08.1090005@redhat.com> On 06/18/2014 01:46 PM, Martin Basti wrote: > On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: >> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: >>> Patches attached, require patches mbasti 0052-0055. >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Rebased patches attached. >> PEP8 fixes. >> > Sorry, patches are here 66.2: 1) Is it OK to just change constants in the update plugins? -PRE_UPDATE = 1 -POST_UPDATE = 2 +PRE_SCHEMA_UPDATE = 1 +PRE_UPDATE = 2 +POST_UPDATE = 3 When people refer to the types via names, it should be OK. It just seemed unnecessary to me. 67.2: 1) update_check_forwardzones: I think we should set update_to_forward_zones to False when the objectclass is there and add a check at the beginning of the execute to simply bail out, if update_to_forward_zones is present in the sysupgrade file. This will prevent the objectclass check (which takes some time) to run again and again. 2) I would use different backup name: + backup_filename = u'master-zones-transform-backup.ldif' Probably something based on time so that different installations' backup do not step on each other. You can inspire yourself in other backup files we create: # ll /var/lib/ipa/backup/ total 16 drwx------. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13 drwx------. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09 drwx------. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21 -rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif 3) This exception does not provide much information, we should at least log the error message itself: + except Exception: + self.log.error('Unable to create backup file') + return (False, False, []) 4) The actual upgrade failed in my case, when I had set forward policy: # ipa-ldap-upgrade --upgrade ... Updating managed permissions for user Updating non-object managed permissions Zones with specified forwarders with policy different than none will be transformed to forward zones. Original zones will be saved in LDIF format in /var/lib/ipa/backup/master-zones-transform-backup.ldif file No changes to ACI Zone forward1.test. was sucessfully transformed to forward zone Transform to forwardzone terminated: creating forwardzone forward2.test. failed Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", line 265, in execute api.Command['dnsforwardzone_add'](zone['idnsname'][0], **kw) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 433, in __call__ params = self.convert(**params) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 631, in convert (k, self.params[k].convert(v)) for (k, v) in kw.iteritems() File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 631, in (k, self.params[k].convert(v)) for (k, v) in kw.iteritems() File "/usr/lib/python2.7/site-packages/ipalib/parameters.py", line 797, in convert return self._convert_scalar(value) File "/usr/lib/python2.7/site-packages/ipalib/parameters.py", line 806, in _convert_scalar error=ugettext(self.type_error), ConversionError: invalid 'idnsforwardpolicy': Gettext('incorrect type', domain='ipa', localedir=None) ... Attaching my DNS zone setting. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: master-zones-transform-backup.ldif Type: text/x-ldif Size: 3441 bytes Desc: not available URL: From pvoborni at redhat.com Tue Jun 24 14:39:43 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 16:39:43 +0200 Subject: [Freeipa-devel] [PATCH] 670-675 webui: dns forward zones In-Reply-To: <53A95AD0.5060905@redhat.com> References: <53A95AD0.5060905@redhat.com> Message-ID: <53A98DAF.9000306@redhat.com> On 24.6.2014 13:02, Petr Vobornik wrote: > ticket: https://fedorahosted.org/freeipa/ticket/4357 > > - patch 673 is compressed > - CI patches functionally depends on #667, #668 > > == PATCH] 670 webui: add confirmation for dns zone permission actions == > All header actions should require confirmation. > > == [PATCH] 671 webui: dns forward zones == > Add DNS Forward Zones Web UI. > > - pages under: Identity/DNS/DNS Forward Zones > > == [PATCH] 672 webui-ci: dns forward zone tests == > Selenium CI sanity tests for DNS Forward Zones > > == [PATCH] 673 webui-test: static metadata update == > Regular update of static metadata for testing and presentation purposes. > It should also contain new DNS Forward Zones metadata. > > == [PATCH] 674 webui-test: dns forward zone json data == > Fake API results for testing and presentation purposes of DNS Forward > Zones. > > == [PATCH] 675 webui: fix detection of RPC command == > old detection did not work with the static version used for test and > demonstration purposes. > Attaching an updated version of #675 with a fix for unit tests. Btw I'm not very satisfied with patch #675's approach. I'm open to suggestions for better approaches. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0675-1-webui-fix-detection-of-RPC-command.patch Type: text/x-patch Size: 2219 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 24 14:46:14 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 16:46:14 +0200 Subject: [Freeipa-devel] [PATCH 0269] Silence GCC warning about uninitialized ldap_writeback Message-ID: <53A98F36.3010600@redhat.com> Hello, Silence GCC warning about uninitialized ldap_writeback. It seems like false positive, I can't imagine how ldap_writeback could be used without prior initialization. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0269-Silence-GCC-warning-about-uninitialized-ldap_writeba.patch Type: text/x-patch Size: 945 bytes Desc: not available URL: From mbasti at redhat.com Tue Jun 24 14:52:12 2014 From: mbasti at redhat.com (Martin Basti) Date: Tue, 24 Jun 2014 16:52:12 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <53A98D08.1090005@redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> <53A98D08.1090005@redhat.com> Message-ID: <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> On Tue, 2014-06-24 at 16:36 +0200, Martin Kosek wrote: > On 06/18/2014 01:46 PM, Martin Basti wrote: > > On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: > >> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: > >>> Patches attached, require patches mbasti 0052-0055. > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> Rebased patches attached. > >> PEP8 fixes. > >> > > Sorry, patches are here > > 66.2: > > 1) Is it OK to just change constants in the update plugins? > > -PRE_UPDATE = 1 > -POST_UPDATE = 2 > +PRE_SCHEMA_UPDATE = 1 > +PRE_UPDATE = 2 > +POST_UPDATE = 3 > > When people refer to the types via names, it should be OK. It just seemed > unnecessary to me. > I checked where the constants are used, and it shouldn't broke anything. It looks weird to me to have something which happens first with last number. Should I set PRE_SCHEMA_UPDATE = 3 and leave other unchanged then? > 67.2: > > 1) update_check_forwardzones: > > I think we should set update_to_forward_zones to False when the objectclass is > there and add a check at the beginning of the execute to simply bail out, if > update_to_forward_zones is present in the sysupgrade file. > > This will prevent the objectclass check (which takes some time) to run again > and again. Good point thanks. > 2) I would use different backup name: > > + backup_filename = u'master-zones-transform-backup.ldif' > > Probably something based on time so that different installations' backup do not > step on each other. You can inspire yourself in other backup files we create: > > # ll /var/lib/ipa/backup/ > total 16 > drwx------. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13 > drwx------. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09 > drwx------. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21 > -rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif Is this better: forward-zones-transform-%datetime%.ldif ? > > 3) This exception does not provide much information, we should at least log the > error message itself: > > + except Exception: > + self.log.error('Unable to create backup file') > + return (False, False, []) Sorry my bad, I missed that > > 4) The actual upgrade failed in my case, when I had set forward policy: > > # ipa-ldap-upgrade --upgrade > ... > Updating managed permissions for user > Updating non-object managed permissions > Zones with specified forwarders with policy different than none will be > transformed to forward zones. > Original zones will be saved in LDIF format in > /var/lib/ipa/backup/master-zones-transform-backup.ldif file > No changes to ACI > Zone forward1.test. was sucessfully transformed to forward zone > Transform to forwardzone terminated: creating forwardzone forward2.test. failed > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py", > line 265, in execute > api.Command['dnsforwardzone_add'](zone['idnsname'][0], **kw) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 433, in __call__ > params = self.convert(**params) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 631, in convert > (k, self.params[k].convert(v)) for (k, v) in kw.iteritems() > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 631, in > > (k, self.params[k].convert(v)) for (k, v) in kw.iteritems() > File "/usr/lib/python2.7/site-packages/ipalib/parameters.py", line 797, in > convert > return self._convert_scalar(value) > File "/usr/lib/python2.7/site-packages/ipalib/parameters.py", line 806, in > _convert_scalar > error=ugettext(self.type_error), > ConversionError: invalid 'idnsforwardpolicy': Gettext('incorrect type', > domain='ipa', localedir=None) > ... > > Attaching my DNS zone setting. I will inspect it. > > Martin Thank you for review -- Martin^2 Basti From pspacek at redhat.com Tue Jun 24 15:04:21 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 17:04:21 +0200 Subject: [Freeipa-devel] [PATCH 0270-0271] Add TLSA and DLV RR types to LDAP schema Message-ID: <53A99375.7030602@redhat.com> Hello, Add TLSA and DLV RR types to LDAP schema. Those RR types will be handy for DNSSEC users. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0270-Add-DLV-RR-type-to-LDAP-schema.patch Type: text/x-patch Size: 1352 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0271-Add-TLSA-RR-type-to-LDAP-schema.patch Type: text/x-patch Size: 1078 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 24 15:06:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 17:06:55 +0200 Subject: [Freeipa-devel] [PATCH 0273-0274] Bump NVR to 5.0Update README and NEWS: DNSSEC and changes in forwarding semantics Message-ID: <53A9940F.2000005@redhat.com> Hello, it's release time! Bump NVR to 5.0 and update README and NEWS to describe DNSSEC support and changes in forwarding semantics. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0272-Update-README-and-NEWS-DNSSEC-and-changes-in-forward.patch Type: text/x-patch Size: 8144 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0273-Bump-NVR-to-5.0.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 24 15:37:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 17:37:32 +0200 Subject: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release In-Reply-To: <53A843F8.7000405@redhat.com> References: <53A843F8.7000405@redhat.com> Message-ID: <53A99B3C.30106@redhat.com> On 23.6.2014 17:12, Petr Spacek wrote: > Hello, > > Bump NVR to 4.4. > > Update NEWS for upcoming 4.4 release. Pushed to master: 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 3a705963ed575f01b792a7e89d825cf56ce99734 At this point v4 branches from master. -- Petr^2 Spacek From pvoborni at redhat.com Tue Jun 24 15:44:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Jun 2014 17:44:09 +0200 Subject: [Freeipa-devel] [PATCH] 677 webui: support unlock user command Message-ID: <53A99CC9.1070905@redhat.com> Call user-unlock command from Web UI. It will unlock displayed user on current master. related to: https://fedorahosted.org/freeipa/ticket/2792 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0677-webui-support-unlock-user-command.patch Type: text/x-patch Size: 3915 bytes Desc: not available URL: From lslebodn at redhat.com Tue Jun 24 15:53:44 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 24 Jun 2014 17:53:44 +0200 Subject: [Freeipa-devel] [PATCH 0269] Silence GCC warning about uninitialized ldap_writeback In-Reply-To: <53A98F36.3010600@redhat.com> References: <53A98F36.3010600@redhat.com> Message-ID: <20140624155344.GB14562@mail.corp.redhat.com> On (24/06/14 16:46), Petr Spacek wrote: >Hello, > >Silence GCC warning about uninitialized ldap_writeback. > >It seems like false positive, I can't imagine how ldap_writeback could be >used without prior initialization. > >-- >Petr^2 Spacek >From eb253b58d6214b3f94d22c3ec2dcf62d0103ad46 Mon Sep 17 00:00:00 2001 >From: Petr Spacek >Date: Mon, 23 Jun 2014 17:02:08 +0200 >Subject: [PATCH] Silence GCC warning about uninitialized ldap_writeback. > >Signed-off-by: Petr Spacek >--- > src/ldap_helper.c | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >index 43bacf779f44a709b0cefd638826633b9d2d8891..a7a782fdfc5ae4d28b50155c9614d66a427dc3e0 100644 >--- a/src/ldap_helper.c >+++ b/src/ldap_helper.c >@@ -2130,7 +2130,11 @@ zone_sync_apex(const ldap_instance_t * const inst, > isc_boolean_t soa_tuple_alloc = ISC_FALSE; > isc_uint32_t curr_serial; > >+ REQUIRE(ldap_writeback != NULL); >+ > INIT_LIST(rdatalist); >+ *ldap_writeback = ISC_FALSE; /* GCC */ >+ > CHECK(setting_get_str("fake_mname", inst->local_settings, > &fake_mname)); > CHECK(ldap_parse_rrentry(inst->mctx, entry, &name, fake_mname, >-- >1.9.3 > ACK LS From npmccallum at redhat.com Tue Jun 24 16:26:19 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 12:26:19 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140624123953.GX7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> Message-ID: <1403627179.32227.2.camel@ipa.example.com> On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: > On Tue, 03 Jun 2014, Nathaniel McCallum wrote: > >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > >> On 3.6.2014 05:08, Nathaniel McCallum wrote: > >> > This command calls the token sync HTTP POST call in the server providing > >> > the CLI interface to synchronization. > >> > > >> > https://fedorahosted.org/freeipa/ticket/4260 > >> > > >> > This patch depends on my patch #0055. > >> > > >> > >> Build fails on validation. You forgot to update API.txt and also the > >> command misses __doc__. > >> > >> (not a proper review) > Failed for me: > > [root at ipa-01 rpms]# ipa otptoken-show test.token > Unique ID: test.token > Description: test token > Owner: abbra > Vendor: FreeIPA > Model: hotp > [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token > Password: > First Code: > Second Code: > ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', > ) > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, > in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", > line 427, in forward > rsp = urllib.urlopen(sync_uri, query) > File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen > return opener.open(url, data) > File "/usr/lib64/python2.7/urllib.py", line 210, in open > return getattr(self, name)(url, data) > File "/usr/lib64/python2.7/urllib.py", line 454, in open_https > data) > File "/usr/lib64/python2.7/urllib.py", line 374, in http_error > result = method(url, fp, errcode, errmsg, headers, data) > File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 > errcode, errmsg, headers) > File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default > raise IOError, ('http error', errcode, errmsg, headers) > IOError: ('http error', 401, 'Unauthorized', ) > ipa: ERROR: an internal error has occurred > > Note that I can successfully use the token. It looks like authentication > with urllib.urlopen(sync_uri, query) fails. Works for me (just tested). I suspect you have not updated the ipa httpd config. Did you apply patches 0054, 0055 and 0056? Nathaniel From tbordaz at redhat.com Tue Jun 24 16:31:11 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 24 Jun 2014 18:31:11 +0200 Subject: [Freeipa-devel] User Life Cycle: scoping of referential integrity, memberof, IPA UUID plugins Message-ID: <53A9A7CF.3040505@redhat.com> Hello, User life cycle "assigns" a status to user entries depending where they are in the DIT. 'Active' user will be under 'cn=accounts,SUFFIX' while 'Stage' and 'Delete' users are somewhere under 'cn=provisioning,SUFFIX'. Only 'Active' users have valid membership attributes: A Stage/Delete user does not belong to any 'Active' group. membership is managed by DS plugins, and particularly RI and memberof. To automatically update membership attributes RI and memberof implement a scoping, that update/add/remove membership attributes if the group/user are Active. The scoping is a single valued attribute. It create failures in IPA tests if I restrict RI/memberof to 'cn=accounts,SUFFIX'. For example adding a host (under 'cn=accounts,SUFFIX) adds it to a network group that is under 'cn=alt,SUFFIX'. A solution would be that the attribute that scopes the plugin is multivalued. But then it would require a long list of values: cn=pbac,SUFFIX cn=hbac,SUFFX cn=alt,SUFFIX cn=accounts, SUFFIX ... An other solution would be to exclude some parts of the DIT, here limited to 'cn=provisionning,SUFFIX'. (prefered solution). This is a similar issue with IPA UUID plugin that generates ipaUniqueID for entries under 'cn=accounts' but also 'cn=alt' or 'cn=hbac'. regards thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Jun 24 16:34:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Jun 2014 19:34:06 +0300 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1403627179.32227.2.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> <1403627179.32227.2.camel@ipa.example.com> Message-ID: <20140624163406.GZ7233@redhat.com> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: >> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: >> >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >> >> On 3.6.2014 05:08, Nathaniel McCallum wrote: >> >> > This command calls the token sync HTTP POST call in the server providing >> >> > the CLI interface to synchronization. >> >> > >> >> > https://fedorahosted.org/freeipa/ticket/4260 >> >> > >> >> > This patch depends on my patch #0055. >> >> > >> >> >> >> Build fails on validation. You forgot to update API.txt and also the >> >> command misses __doc__. >> >> >> >> (not a proper review) >> Failed for me: >> >> [root at ipa-01 rpms]# ipa otptoken-show test.token >> Unique ID: test.token >> Description: test token >> Owner: abbra >> Vendor: FreeIPA >> Model: hotp >> [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token >> Password: >> First Code: >> Second Code: >> ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', >> ) >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, >> in execute >> result = self.Command[_name](*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, >> in __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, >> in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", >> line 427, in forward >> rsp = urllib.urlopen(sync_uri, query) >> File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen >> return opener.open(url, data) >> File "/usr/lib64/python2.7/urllib.py", line 210, in open >> return getattr(self, name)(url, data) >> File "/usr/lib64/python2.7/urllib.py", line 454, in open_https >> data) >> File "/usr/lib64/python2.7/urllib.py", line 374, in http_error >> result = method(url, fp, errcode, errmsg, headers, data) >> File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 >> errcode, errmsg, headers) >> File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default >> raise IOError, ('http error', errcode, errmsg, headers) >> IOError: ('http error', 401, 'Unauthorized', ) >> ipa: ERROR: an internal error has occurred >> >> Note that I can successfully use the token. It looks like authentication >> with urllib.urlopen(sync_uri, query) fails. > >Works for me (just tested). I suspect you have not updated the ipa httpd >config. Did you apply patches 0054, 0055 and 0056? Yes, I did apply those patches and I installed packages as an upgrade. How I supposed to update httpd config? I think we need to solve this without re-install and it should be done automatically. -- / Alexander Bokovoy From npmccallum at redhat.com Tue Jun 24 16:35:15 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 12:35:15 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140624163406.GZ7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> <1403627179.32227.2.camel@ipa.example.com> <20140624163406.GZ7233@redhat.com> Message-ID: <1403627715.32227.3.camel@ipa.example.com> On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote: > On Tue, 24 Jun 2014, Nathaniel McCallum wrote: > >On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: > >> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: > >> >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > >> >> On 3.6.2014 05:08, Nathaniel McCallum wrote: > >> >> > This command calls the token sync HTTP POST call in the server providing > >> >> > the CLI interface to synchronization. > >> >> > > >> >> > https://fedorahosted.org/freeipa/ticket/4260 > >> >> > > >> >> > This patch depends on my patch #0055. > >> >> > > >> >> > >> >> Build fails on validation. You forgot to update API.txt and also the > >> >> command misses __doc__. > >> >> > >> >> (not a proper review) > >> Failed for me: > >> > >> [root at ipa-01 rpms]# ipa otptoken-show test.token > >> Unique ID: test.token > >> Description: test token > >> Owner: abbra > >> Vendor: FreeIPA > >> Model: hotp > >> [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token > >> Password: > >> First Code: > >> Second Code: > >> ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', > >> ) > >> Traceback (most recent call last): > >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, > >> in execute > >> result = self.Command[_name](*args, **options) > >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > >> in __call__ > >> ret = self.run(*args, **options) > >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, > >> in run > >> return self.forward(*args, **options) > >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", > >> line 427, in forward > >> rsp = urllib.urlopen(sync_uri, query) > >> File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen > >> return opener.open(url, data) > >> File "/usr/lib64/python2.7/urllib.py", line 210, in open > >> return getattr(self, name)(url, data) > >> File "/usr/lib64/python2.7/urllib.py", line 454, in open_https > >> data) > >> File "/usr/lib64/python2.7/urllib.py", line 374, in http_error > >> result = method(url, fp, errcode, errmsg, headers, data) > >> File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 > >> errcode, errmsg, headers) > >> File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default > >> raise IOError, ('http error', errcode, errmsg, headers) > >> IOError: ('http error', 401, 'Unauthorized', ) > >> ipa: ERROR: an internal error has occurred > >> > >> Note that I can successfully use the token. It looks like authentication > >> with urllib.urlopen(sync_uri, query) fails. > > > >Works for me (just tested). I suspect you have not updated the ipa httpd > >config. Did you apply patches 0054, 0055 and 0056? > Yes, I did apply those patches and I installed packages as an upgrade. > How I supposed to update httpd config? I think we need to solve this > without re-install and it should be done automatically. Oh. I thought it *was* done automatically... From abokovoy at redhat.com Tue Jun 24 16:44:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Jun 2014 19:44:40 +0300 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1403627715.32227.3.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> <1403627179.32227.2.camel@ipa.example.com> <20140624163406.GZ7233@redhat.com> <1403627715.32227.3.camel@ipa.example.com> Message-ID: <20140624164440.GA7233@redhat.com> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote: >> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >> >On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: >> >> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: >> >> >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >> >> >> On 3.6.2014 05:08, Nathaniel McCallum wrote: >> >> >> > This command calls the token sync HTTP POST call in the server providing >> >> >> > the CLI interface to synchronization. >> >> >> > >> >> >> > https://fedorahosted.org/freeipa/ticket/4260 >> >> >> > >> >> >> > This patch depends on my patch #0055. >> >> >> > >> >> >> >> >> >> Build fails on validation. You forgot to update API.txt and also the >> >> >> command misses __doc__. >> >> >> >> >> >> (not a proper review) >> >> Failed for me: >> >> >> >> [root at ipa-01 rpms]# ipa otptoken-show test.token >> >> Unique ID: test.token >> >> Description: test token >> >> Owner: abbra >> >> Vendor: FreeIPA >> >> Model: hotp >> >> [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token >> >> Password: >> >> First Code: >> >> Second Code: >> >> ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', >> >> ) >> >> Traceback (most recent call last): >> >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, >> >> in execute >> >> result = self.Command[_name](*args, **options) >> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, >> >> in __call__ >> >> ret = self.run(*args, **options) >> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, >> >> in run >> >> return self.forward(*args, **options) >> >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", >> >> line 427, in forward >> >> rsp = urllib.urlopen(sync_uri, query) >> >> File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen >> >> return opener.open(url, data) >> >> File "/usr/lib64/python2.7/urllib.py", line 210, in open >> >> return getattr(self, name)(url, data) >> >> File "/usr/lib64/python2.7/urllib.py", line 454, in open_https >> >> data) >> >> File "/usr/lib64/python2.7/urllib.py", line 374, in http_error >> >> result = method(url, fp, errcode, errmsg, headers, data) >> >> File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 >> >> errcode, errmsg, headers) >> >> File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default >> >> raise IOError, ('http error', errcode, errmsg, headers) >> >> IOError: ('http error', 401, 'Unauthorized', ) >> >> ipa: ERROR: an internal error has occurred >> >> >> >> Note that I can successfully use the token. It looks like authentication >> >> with urllib.urlopen(sync_uri, query) fails. >> > >> >Works for me (just tested). I suspect you have not updated the ipa httpd >> >config. Did you apply patches 0054, 0055 and 0056? >> Yes, I did apply those patches and I installed packages as an upgrade. >> How I supposed to update httpd config? I think we need to solve this >> without re-install and it should be done automatically. > >Oh. I thought it *was* done automatically... No. You only modified the template which is used for an install from scratch. -- / Alexander Bokovoy From simo at redhat.com Tue Jun 24 17:19:43 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jun 2014 13:19:43 -0400 (EDT) Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403297459.4808.15.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403287538.4808.5.camel@ipa.example.com> <1403287842.12884.157.camel@willson.usersys.redhat.com> <1403289046.4808.7.camel@ipa.example.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> Message-ID: <1756330129.29675529.1403630383606.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote: > > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote: > > > This change would have very small impact on your patch set, but would > > > be > > > much clearer for the future consumers of this protocol. Code can be > > > changed; protocols can't. > > > > Ok this new patchset implements the requested change. > > Initial testing seem to indicate it all works as expected. > > 0001: Line 555 has very wrong indentation. Attached a new patch 0001 hat fixes this. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 36287 bytes Desc: not available URL: From tbabej at redhat.com Tue Jun 24 18:15:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Jun 2014 20:15:39 +0200 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes In-Reply-To: <53A97418.7080302@redhat.com> References: <53A97418.7080302@redhat.com> Message-ID: <53A9C04B.7050102@redhat.com> Attaching patch 234, which resolves another ACI issue related to trusts. On 06/24/2014 02:50 PM, Tomas Babej wrote: > Hi, > > this is a follow up patch for 232. Read access to additional attributes > is required for the trust objects. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0234-trusts-Allow-reading-system-trust-accounts-by-adtrus.patch Type: text/x-patch Size: 3780 bytes Desc: not available URL: From pspacek at redhat.com Tue Jun 24 18:30:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Jun 2014 20:30:12 +0200 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <1403617556.20513.36.camel@vespa.frost.loc> References: <53A82440.30000@redhat.com> <1403617556.20513.36.camel@vespa.frost.loc> Message-ID: <53A9C3B4.3080004@redhat.com> On 24.6.2014 15:45, Tomas Mraz wrote: >> >Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with >> >AES according to RFC 3394 (no padding) or RFC 5649 (with padding). >> > >> >RFC 3394 works only on blocks of 64 bits, which is not our case because >> >EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get >> >proper padding etc. >> > >> >And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but >> >OpenSSL doesn't support RFC 5649! The patch with this functionality was >> >submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state >> >"new" and there was no reply to the e-mail in the original thread [4]. > I am sorry, but this does not make much sense to me. Iff the SoftHSM's > C_WrapKey is really safe wrapping method for backing up and/or > replicating HSM's it must provide wrapped key in such format that the IV > is pregenerated as part of the Wrap operation and stored in the final > blob of wrapped key. Unfortunately I do not know much of SoftHSM. SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do something against PKCS#11 standard. In this case the standard says that user has to provide IV explicitly and the C_WrapKey should fall-back to standardized default if IV was not given by user. See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki ? Draft 7" on ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > >> >What do we do? >> >- Convince OpenSSL to review and accept the patch? > I would say the patch is not too useful as is - there are multiple > problems with it such as it is not using proper high level interfaces > for the AES encryption, etc. Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from the 2010-version. I didn't notice it. Would you review the patch if we re-write it against current OpenSSL git head? -- Petr^2 Spacek From simo at redhat.com Tue Jun 24 19:33:56 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jun 2014 15:33:56 -0400 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <53A9C3B4.3080004@redhat.com> References: <53A82440.30000@redhat.com> <1403617556.20513.36.camel@vespa.frost.loc> <53A9C3B4.3080004@redhat.com> Message-ID: <1403638436.19579.26.camel@willson.usersys.redhat.com> On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: > On 24.6.2014 15:45, Tomas Mraz wrote: > >> >Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with > >> >AES according to RFC 3394 (no padding) or RFC 5649 (with padding). > >> > > >> >RFC 3394 works only on blocks of 64 bits, which is not our case because > >> >EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get > >> >proper padding etc. > >> > > >> >And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but > >> >OpenSSL doesn't support RFC 5649! The patch with this functionality was > >> >submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state > >> >"new" and there was no reply to the e-mail in the original thread [4]. > > I am sorry, but this does not make much sense to me. Iff the SoftHSM's > > C_WrapKey is really safe wrapping method for backing up and/or > > replicating HSM's it must provide wrapped key in such format that the IV > > is pregenerated as part of the Wrap operation and stored in the final > > blob of wrapped key. Unfortunately I do not know much of SoftHSM. > SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do > something against PKCS#11 standard. > > In this case the standard says that user has to provide IV explicitly and the > C_WrapKey should fall-back to standardized default if IV was not given by user. Sounds completely bogus, but in this case we'll have to either provide a random IV ourselves (and then store it alongside or provide data with a confounder at the start implementing padding on our own. > See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki ? > Draft 7" on > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > > > > >> >What do we do? > >> >- Convince OpenSSL to review and accept the patch? > > I would say the patch is not too useful as is - there are multiple > > problems with it such as it is not using proper high level interfaces > > for the AES encryption, etc. > Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from > the 2010-version. I didn't notice it. > > Would you review the patch if we re-write it against current OpenSSL git head? > -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Jun 24 19:34:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 21:34:35 +0200 Subject: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release In-Reply-To: <53A99B3C.30106@redhat.com> References: <53A843F8.7000405@redhat.com> <53A99B3C.30106@redhat.com> Message-ID: <53A9D2CB.4050101@redhat.com> On 06/24/2014 05:37 PM, Petr Spacek wrote: > On 23.6.2014 17:12, Petr Spacek wrote: >> Hello, >> >> Bump NVR to 4.4. >> >> Update NEWS for upcoming 4.4 release. > > Pushed to master: > 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 > 3a705963ed575f01b792a7e89d825cf56ce99734 > > At this point v4 branches from master. > Just for my education - what is the branching model in bind-dyndb-ldap? In FreeIPA, we branch when we release FreeIPA x.y so that bugfixing releases FreeIPA x.y.z can be done. When you now branched at 4.4, do you plan to release bugfixes 4.4.x or rather 4.5, 4.6...? Thanks, Martin From simo at redhat.com Tue Jun 24 19:37:33 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 24 Jun 2014 15:37:33 -0400 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <1403638436.19579.26.camel@willson.usersys.redhat.com> References: <53A82440.30000@redhat.com> <1403617556.20513.36.camel@vespa.frost.loc> <53A9C3B4.3080004@redhat.com> <1403638436.19579.26.camel@willson.usersys.redhat.com> Message-ID: <1403638653.19579.28.camel@willson.usersys.redhat.com> On Tue, 2014-06-24 at 15:33 -0400, Simo Sorce wrote: > On Tue, 2014-06-24 at 20:30 +0200, Petr Spacek wrote: > > In this case the standard says that user has to provide IV explicitly and the > > C_WrapKey should fall-back to standardized default if IV was not given by user. > > Sounds completely bogus, but in this case we'll have to either provide a > random IV ourselves (and then store it alongside or provide data with a Add "the key data)" here-------------------------^ Simo. > confounder at the start implementing padding on our own. > > > See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki ? > > Draft 7" on > > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > > > > > > > >> >What do we do? > > >> >- Convince OpenSSL to review and accept the patch? > > > I would say the patch is not too useful as is - there are multiple > > > problems with it such as it is not using proper high level interfaces > > > for the AES encryption, etc. > > Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from > > the 2010-version. I didn't notice it. > > > > Would you review the patch if we re-write it against current OpenSSL git head? > > > > -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Jun 24 19:40:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Jun 2014 21:40:33 +0200 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140624164440.GA7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> <1403627179.32227.2.camel@ipa.example.com> <20140624163406.GZ7233@redhat.com> <1403627715.32227.3.camel@ipa.example.com> <20140624164440.GA7233@redhat.com> Message-ID: <53A9D431.3090000@redhat.com> On 06/24/2014 06:44 PM, Alexander Bokovoy wrote: > On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >> On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote: >>> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >>> >On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: >>> >> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: >>> >> >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >>> >> >> On 3.6.2014 05:08, Nathaniel McCallum wrote: >>> >> >> > This command calls the token sync HTTP POST call in the server >>> providing >>> >> >> > the CLI interface to synchronization. >>> >> >> > >>> >> >> > https://fedorahosted.org/freeipa/ticket/4260 >>> >> >> > >>> >> >> > This patch depends on my patch #0055. >>> >> >> > >>> >> >> >>> >> >> Build fails on validation. You forgot to update API.txt and also the >>> >> >> command misses __doc__. >>> >> >> >>> >> >> (not a proper review) >>> >> Failed for me: >>> >> >>> >> [root at ipa-01 rpms]# ipa otptoken-show test.token >>> >> Unique ID: test.token >>> >> Description: test token >>> >> Owner: abbra >>> >> Vendor: FreeIPA >>> >> Model: hotp >>> >> [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token >>> >> Password: >>> >> First Code: >>> >> Second Code: >>> >> ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', >>> >> ) >>> >> Traceback (most recent call last): >>> >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, >>> >> in execute >>> >> result = self.Command[_name](*args, **options) >>> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, >>> >> in __call__ >>> >> ret = self.run(*args, **options) >>> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, >>> >> in run >>> >> return self.forward(*args, **options) >>> >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", >>> >> line 427, in forward >>> >> rsp = urllib.urlopen(sync_uri, query) >>> >> File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen >>> >> return opener.open(url, data) >>> >> File "/usr/lib64/python2.7/urllib.py", line 210, in open >>> >> return getattr(self, name)(url, data) >>> >> File "/usr/lib64/python2.7/urllib.py", line 454, in open_https >>> >> data) >>> >> File "/usr/lib64/python2.7/urllib.py", line 374, in http_error >>> >> result = method(url, fp, errcode, errmsg, headers, data) >>> >> File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 >>> >> errcode, errmsg, headers) >>> >> File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default >>> >> raise IOError, ('http error', errcode, errmsg, headers) >>> >> IOError: ('http error', 401, 'Unauthorized', >> instance at 0x2cdde60>) >>> >> ipa: ERROR: an internal error has occurred >>> >> >>> >> Note that I can successfully use the token. It looks like authentication >>> >> with urllib.urlopen(sync_uri, query) fails. >>> > >>> >Works for me (just tested). I suspect you have not updated the ipa httpd >>> >config. Did you apply patches 0054, 0055 and 0056? >>> Yes, I did apply those patches and I installed packages as an upgrade. >>> How I supposed to update httpd config? I think we need to solve this >>> without re-install and it should be done automatically. >> >> Oh. I thought it *was* done automatically... > No. You only modified the template which is used for an install from > scratch. It *will* get updated automatically if you bump the "VERSION" on the first line of install/conf/ipa.conf. Martin From npmccallum at redhat.com Tue Jun 24 19:42:14 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 15:42:14 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <53A9D431.3090000@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> <1403627179.32227.2.camel@ipa.example.com> <20140624163406.GZ7233@redhat.com> <1403627715.32227.3.camel@ipa.example.com> <20140624164440.GA7233@redhat.com> <53A9D431.3090000@redhat.com> Message-ID: <1403638934.3523.0.camel@ipa.example.com> On Tue, 2014-06-24 at 21:40 +0200, Martin Kosek wrote: > On 06/24/2014 06:44 PM, Alexander Bokovoy wrote: > > On Tue, 24 Jun 2014, Nathaniel McCallum wrote: > >> On Tue, 2014-06-24 at 19:34 +0300, Alexander Bokovoy wrote: > >>> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: > >>> >On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: > >>> >> On Tue, 03 Jun 2014, Nathaniel McCallum wrote: > >>> >> >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > >>> >> >> On 3.6.2014 05:08, Nathaniel McCallum wrote: > >>> >> >> > This command calls the token sync HTTP POST call in the server > >>> providing > >>> >> >> > the CLI interface to synchronization. > >>> >> >> > > >>> >> >> > https://fedorahosted.org/freeipa/ticket/4260 > >>> >> >> > > >>> >> >> > This patch depends on my patch #0055. > >>> >> >> > > >>> >> >> > >>> >> >> Build fails on validation. You forgot to update API.txt and also the > >>> >> >> command misses __doc__. > >>> >> >> > >>> >> >> (not a proper review) > >>> >> Failed for me: > >>> >> > >>> >> [root at ipa-01 rpms]# ipa otptoken-show test.token > >>> >> Unique ID: test.token > >>> >> Description: test token > >>> >> Owner: abbra > >>> >> Vendor: FreeIPA > >>> >> Model: hotp > >>> >> [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token > >>> >> Password: > >>> >> First Code: > >>> >> Second Code: > >>> >> ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', > >>> >> ) > >>> >> Traceback (most recent call last): > >>> >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, > >>> >> in execute > >>> >> result = self.Command[_name](*args, **options) > >>> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > >>> >> in __call__ > >>> >> ret = self.run(*args, **options) > >>> >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, > >>> >> in run > >>> >> return self.forward(*args, **options) > >>> >> File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", > >>> >> line 427, in forward > >>> >> rsp = urllib.urlopen(sync_uri, query) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen > >>> >> return opener.open(url, data) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 210, in open > >>> >> return getattr(self, name)(url, data) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 454, in open_https > >>> >> data) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 374, in http_error > >>> >> result = method(url, fp, errcode, errmsg, headers, data) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 > >>> >> errcode, errmsg, headers) > >>> >> File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default > >>> >> raise IOError, ('http error', errcode, errmsg, headers) > >>> >> IOError: ('http error', 401, 'Unauthorized', >>> instance at 0x2cdde60>) > >>> >> ipa: ERROR: an internal error has occurred > >>> >> > >>> >> Note that I can successfully use the token. It looks like authentication > >>> >> with urllib.urlopen(sync_uri, query) fails. > >>> > > >>> >Works for me (just tested). I suspect you have not updated the ipa httpd > >>> >config. Did you apply patches 0054, 0055 and 0056? > >>> Yes, I did apply those patches and I installed packages as an upgrade. > >>> How I supposed to update httpd config? I think we need to solve this > >>> without re-install and it should be done automatically. > >> > >> Oh. I thought it *was* done automatically... > > No. You only modified the template which is used for an install from > > scratch. > > It *will* get updated automatically if you bump the "VERSION" on the first line > of install/conf/ipa.conf. Yup, I figured that out about 15 minutes ago by looking at your past commits. :) Nathaniel From npmccallum at redhat.com Tue Jun 24 20:32:01 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 16:32:01 -0400 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support In-Reply-To: <1401764823.4161.4.camel@ipa.example.com> References: <1401764823.4161.4.camel@ipa.example.com> Message-ID: <1403641921.3523.2.camel@ipa.example.com> On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: > This HTTP call takes the following parameters: > * user > * password > * first_code > * second_code > * token (optional) > > Using this information, the server will perform token synchronization. > If the token is not specified, all tokens will be searched for > synchronization. > Otherwise, only the token specified will be searched. > > This patch depends on my patch #0054. Attached is a new revision. This version should force an update to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0055.1-Add-session-token_sync-POST-support.patch Type: text/x-patch Size: 9998 bytes Desc: not available URL: From npmccallum at redhat.com Tue Jun 24 20:32:45 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 16:32:45 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140624123953.GX7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <20140624123953.GX7233@redhat.com> Message-ID: <1403641965.3523.3.camel@ipa.example.com> On Tue, 2014-06-24 at 15:39 +0300, Alexander Bokovoy wrote: > On Tue, 03 Jun 2014, Nathaniel McCallum wrote: > >On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > >> On 3.6.2014 05:08, Nathaniel McCallum wrote: > >> > This command calls the token sync HTTP POST call in the server providing > >> > the CLI interface to synchronization. > >> > > >> > https://fedorahosted.org/freeipa/ticket/4260 > >> > > >> > This patch depends on my patch #0055. > >> > > >> > >> Build fails on validation. You forgot to update API.txt and also the > >> command misses __doc__. > >> > >> (not a proper review) > Failed for me: > > [root at ipa-01 rpms]# ipa otptoken-show test.token > Unique ID: test.token > Description: test token > Owner: abbra > Vendor: FreeIPA > Model: hotp > [root at ipa-01 rpms]# ipa otptoken-sync abbra --token=test.token > Password: > First Code: > Second Code: > ipa: ERROR: non-public: IOError: ('http error', 401, 'Unauthorized', > ) > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 129, > in execute > result = self.Command[_name](*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, > in __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1118, > in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py", > line 427, in forward > rsp = urllib.urlopen(sync_uri, query) > File "/usr/lib64/python2.7/urllib.py", line 89, in urlopen > return opener.open(url, data) > File "/usr/lib64/python2.7/urllib.py", line 210, in open > return getattr(self, name)(url, data) > File "/usr/lib64/python2.7/urllib.py", line 454, in open_https > data) > File "/usr/lib64/python2.7/urllib.py", line 374, in http_error > result = method(url, fp, errcode, errmsg, headers, data) > File "/usr/lib64/python2.7/urllib.py", line 689, in http_error_401 > errcode, errmsg, headers) > File "/usr/lib64/python2.7/urllib.py", line 381, in http_error_default > raise IOError, ('http error', errcode, errmsg, headers) > IOError: ('http error', 401, 'Unauthorized', ) > ipa: ERROR: an internal error has occurred > > Note that I can successfully use the token. It looks like authentication > with urllib.urlopen(sync_uri, query) fails. This should be fixed in 0055.1. Nathaniel From lslebodn at redhat.com Tue Jun 24 20:46:19 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 24 Jun 2014 22:46:19 +0200 Subject: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release In-Reply-To: <53A9D2CB.4050101@redhat.com> References: <53A843F8.7000405@redhat.com> <53A99B3C.30106@redhat.com> <53A9D2CB.4050101@redhat.com> Message-ID: <20140624204618.GA24460@mail.corp.redhat.com> On (24/06/14 21:34), Martin Kosek wrote: >On 06/24/2014 05:37 PM, Petr Spacek wrote: >>On 23.6.2014 17:12, Petr Spacek wrote: >>>Hello, >>> >>>Bump NVR to 4.4. >>> >>>Update NEWS for upcoming 4.4 release. >> >>Pushed to master: >>2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 >>3a705963ed575f01b792a7e89d825cf56ce99734 >> >>At this point v4 branches from master. >> > >Just for my education - what is the branching model in bind-dyndb-ldap? In >FreeIPA, we branch when we release FreeIPA x.y so that bugfixing releases >FreeIPA x.y.z can be done. > >When you now branched at 4.4, do you plan to release bugfixes 4.4.x or rather >4.5, 4.6...? Numbers are cheap. bind-dyndb-ldap is small project. It will be simpler to use only two numbers for version. LS From npmccallum at redhat.com Tue Jun 24 20:57:40 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 24 Jun 2014 16:57:40 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1401801502.4161.7.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> Message-ID: <1403643460.3523.5.camel@ipa.example.com> On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote: > On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > > On 3.6.2014 05:08, Nathaniel McCallum wrote: > > > This command calls the token sync HTTP POST call in the server providing > > > the CLI interface to synchronization. > > > > > > https://fedorahosted.org/freeipa/ticket/4260 > > > > > > This patch depends on my patch #0055. > > > > > > > Build fails on validation. You forgot to update API.txt and also the > > command misses __doc__. > > > > (not a proper review) > > Thanks, fixed. Attached is a new revision which is rebased on master. In addition it: 1. Moves user to a parameter and moves token to an argument. Doing it this way both mirrors the existing otptoken APIs and sets us up for future Kerberos based syncing where the username/password will be optional. 2. Converts the token ID to a DN. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0056.2-Add-otptoken-sync-command.patch Type: text/x-patch Size: 4384 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 25 07:16:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jun 2014 09:16:44 +0200 Subject: [Freeipa-devel] [PATCH 0068] Fix ipa.service restart In-Reply-To: <1403014977.5043.1.camel@unused-4-145.brq.redhat.com> References: <1403014977.5043.1.camel@unused-4-145.brq.redhat.com> Message-ID: <53AA775C.2090304@redhat.com> On 06/17/2014 04:22 PM, Martin Basti wrote: > Patch attached. > Ticket: https://fedorahosted.org/freeipa/ticket/4243 Works fine. ACK, pushed to master, ipa-3-3. Martin From pspacek at redhat.com Wed Jun 25 07:53:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Jun 2014 09:53:34 +0200 Subject: [Freeipa-devel] [PATCH 0267-0268] Preparation for 4.4 release In-Reply-To: <20140624204618.GA24460@mail.corp.redhat.com> References: <53A843F8.7000405@redhat.com> <53A99B3C.30106@redhat.com> <53A9D2CB.4050101@redhat.com> <20140624204618.GA24460@mail.corp.redhat.com> Message-ID: <53AA7FFE.1060301@redhat.com> On 24.6.2014 22:46, Lukas Slebodnik wrote: > On (24/06/14 21:34), Martin Kosek wrote: >> On 06/24/2014 05:37 PM, Petr Spacek wrote: >>> On 23.6.2014 17:12, Petr Spacek wrote: >>>> Bump NVR to 4.4. >>>> >>>> Update NEWS for upcoming 4.4 release. >>> >>> Pushed to master: >>> 2cd574e90a9fdebdbeaab45ef335e7d63e85dfd7 >>> 3a705963ed575f01b792a7e89d825cf56ce99734 >>> >>> At this point v4 branches from master. >>> >> >> Just for my education - what is the branching model in bind-dyndb-ldap? In >> FreeIPA, we branch when we release FreeIPA x.y so that bugfixing releases >> FreeIPA x.y.z can be done. >> >> When you now branched at 4.4, do you plan to release bugfixes 4.4.x or rather >> 4.5, 4.6...? > Numbers are cheap. > bind-dyndb-ldap is small project. It will be simpler to use only two > numbers for version. To sum it up: https://fedorahosted.org/bind-dyndb-ldap/wiki/Versions -- Petr^2 Spacek From pviktori at redhat.com Wed Jun 25 08:48:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 10:48:13 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53A2EB24.8030404@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> Message-ID: <53AA8CCD.6000604@redhat.com> On 06/19/2014 03:52 PM, Tomas Babej wrote: > > On 06/19/2014 12:52 PM, Tomas Babej wrote: >> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>> Attached is a new version of patch 226, and a new patch 228, which moves >>>> the paths from installers to the paths module. >>> In patch 226, there's another "certificated" typo in >>> remove_ca_cert_from_systemwide_ca_store >>> >>>> I greped the repository, and I do not see many paths lurking around any >>>> more, there are only some in the error messages (as these can't be >>>> reliably replaced automatically, and will need some manual love). >>>> >>>> If you see any forgotten paths, which should be added to the module, let >>>> me know. Well, since you asked... install/tools/ipa-upgradeconfig:236: ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", ipaserver/install/dsinstance.py:209:InstallLdifFile= /var/lib/dirsrv/boot.ldif ipaserver/install/dsinstance.py:210:inst_dir= /var/lib/dirsrv/scripts-$SERVERID ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', ipatests/test_integration/tasks.py:451: host.run_command("find /var/lib/sss/db -name '*.ldb' | " install/tools/ipa-replica-conncheck:403: "/usr/sbin/ipa-replica-conncheck " + install/tools/ipa-replica-conncheck:414: print_info("/usr/sbin/ipa-replica-conncheck " + " ".join(remote_check_opts)) ipapython/ipautil.py:296: env["PATH"] = "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" ipaserver/install/cainstance.py:88:ConfigFile = /usr/share/pki/ca/conf/database.ldif ipaserver/install/bindinstance.py:829: ipautil.run(['/usr/libexec/generate-rndc-key.sh']) I guess it'll be a while before we catch them all, but now it's at least clear where these paths should be, so anyone porting to another distro can send patches (or tickets) upstream. >>> I see another duplicate: >>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>> "/var/lib/sss/pubconf/krb5.include.d/" Could you just pick one instead? Would ipa_backup.py break if it had a trailing slash here? In ipa-client-install, if you set: NSSWITCH_CONF = paths.NSSWITCH_CONF then you should only use one of those later. (Preferably paths.*, to get rid of the redundant constants.) Perhaps this is for another patch that would clean up all the cases where these trivial module variables are used. >> Fixed all mentioned issues. I also attached a patch 230, which removes >> the base Authconfig class. > Attaching one additional patch, which removes unnecessary build warnings. > 226, 230, 231 look good -- Petr? From mkosek at redhat.com Wed Jun 25 08:52:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jun 2014 10:52:26 +0200 Subject: [Freeipa-devel] User Life Cycle: scoping of referential integrity, memberof, IPA UUID plugins In-Reply-To: <53A9A7CF.3040505@redhat.com> References: <53A9A7CF.3040505@redhat.com> Message-ID: <53AA8DCA.4050009@redhat.com> On 06/24/2014 06:31 PM, thierry bordaz wrote: > Hello, > > User life cycle "assigns" a status to user entries depending where > they are in the DIT. > 'Active' user will be under 'cn=accounts,SUFFIX' while 'Stage' and > 'Delete' users are somewhere under 'cn=provisioning,SUFFIX'. > > Only 'Active' users have valid membership attributes: A Stage/Delete > user does not belong to any 'Active' group. > membership is managed by DS plugins, and particularly RI and memberof. > To automatically update membership attributes RI and memberof > implement a scoping, that update/add/remove membership attributes if > the group/user are Active. > > The scoping is a single valued attribute. > > It create failures in IPA tests if I restrict RI/memberof to > 'cn=accounts,SUFFIX'. For example adding a host (under > 'cn=accounts,SUFFIX) adds it to a network group that is under > 'cn=alt,SUFFIX'. > A solution would be that the attribute that scopes the plugin is > multivalued. But then it would require a long list of values: > > cn=pbac,SUFFIX > cn=hbac,SUFFX > cn=alt,SUFFIX > cn=accounts, SUFFIX > ... > > > An other solution would be to exclude some parts of the DIT, here > limited to 'cn=provisionning,SUFFIX'. (prefered solution). > > > This is a similar issue with IPA UUID plugin that generates > ipaUniqueID for entries under 'cn=accounts' but also 'cn=alt' or > 'cn=hbac'. > > regards > thierry Right. As discussed yesterday, I think the best approach would be to specify a SUFFIX + excluded tree. Specifying all containers where there may be an entry with member or RI'ed attribute would be very long and possibly error prone when we add a new one (all active IPA server plugin configuration would need to be updated?). Martin From tbordaz at redhat.com Wed Jun 25 09:37:13 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Wed, 25 Jun 2014 11:37:13 +0200 Subject: [Freeipa-devel] User Life Cycle: scoping of referential integrity, memberof, IPA UUID plugins In-Reply-To: <53AA8DCA.4050009@redhat.com> References: <53A9A7CF.3040505@redhat.com> <53AA8DCA.4050009@redhat.com> Message-ID: <53AA9849.1000500@redhat.com> On 06/25/2014 10:52 AM, Martin Kosek wrote: > On 06/24/2014 06:31 PM, thierry bordaz wrote: >> Hello, >> >> User life cycle "assigns" a status to user entries depending where >> they are in the DIT. >> 'Active' user will be under 'cn=accounts,SUFFIX' while 'Stage' and >> 'Delete' users are somewhere under 'cn=provisioning,SUFFIX'. >> >> Only 'Active' users have valid membership attributes: A Stage/Delete >> user does not belong to any 'Active' group. >> membership is managed by DS plugins, and particularly RI and memberof. >> To automatically update membership attributes RI and memberof >> implement a scoping, that update/add/remove membership attributes if >> the group/user are Active. >> >> The scoping is a single valued attribute. >> >> It create failures in IPA tests if I restrict RI/memberof to >> 'cn=accounts,SUFFIX'. For example adding a host (under >> 'cn=accounts,SUFFIX) adds it to a network group that is under >> 'cn=alt,SUFFIX'. >> A solution would be that the attribute that scopes the plugin is >> multivalued. But then it would require a long list of values: >> >> cn=pbac,SUFFIX >> cn=hbac,SUFFX >> cn=alt,SUFFIX >> cn=accounts, SUFFIX >> ... >> >> >> An other solution would be to exclude some parts of the DIT, here >> limited to 'cn=provisionning,SUFFIX'. (prefered solution). >> >> >> This is a similar issue with IPA UUID plugin that generates >> ipaUniqueID for entries under 'cn=accounts' but also 'cn=alt' or >> 'cn=hbac'. >> >> regards >> thierry > Right. As discussed yesterday, I think the best approach would be to specify a > SUFFIX + excluded tree. > > Specifying all containers where there may be an entry with member or RI'ed > attribute would be very long and possibly error prone when we add a new one > (all active IPA server plugin configuration would need to be updated?). > > Martin Thanks. I opened https://fedorahosted.org/389/ticket/47828 (DNA) and https://fedorahosted.org/389/ticket/47829 (memberof). For RI https://fedorahosted.org/389/ticket/47621 already implements it. For IPA Unique IDs I may use https://fedorahosted.org/freeipa/ticket/3813 or open a separated ticket. thierry From pviktori at redhat.com Wed Jun 25 09:45:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 11:45:09 +0200 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes In-Reply-To: <53A9C04B.7050102@redhat.com> References: <53A97418.7080302@redhat.com> <53A9C04B.7050102@redhat.com> Message-ID: <53AA9A25.3070506@redhat.com> On 06/24/2014 08:15 PM, Tomas Babej wrote: > Attaching patch 234, which resolves another ACI issue related to trusts. > > On 06/24/2014 02:50 PM, Tomas Babej wrote: >> Hi, >> >> this is a follow up patch for 232. Read access to additional attributes >> is required for the trust objects. >> First patch looks fine. For the second: should the trust ACIs apply to other objects than (objectclas=ipanttrusteddomain)? If not, we can enable "--type=trust" permissions and use it to specify location & filter, see attached patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: trusts-Allow-reading-system-trust-accounts-by-adtrus.patch Type: text/x-patch Size: 5079 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 25 10:13:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 12:13:27 +0200 Subject: [Freeipa-devel] [PATCH 0077] Add dnssecinlinesigning attribute to ACI In-Reply-To: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> References: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> Message-ID: <53AAA0C7.80501@redhat.com> On 06/20/2014 03:32 PM, Martin Basti wrote: > Required patches: mbasti-0060, mbasti-0073 > > Patch attached. > Hi, For the raw ACI in dns.ldif, there are some more hoops to jump through. Remove the ACI from /install/share/dns.ldif entirely (except for schema, we're slowly replacing the .ldif content by .update files). In install/updates/40-dns.update, you'll notice the "Update DNS entries in a zone" ACI is already being added. You'll need to replace it, using a line like: replace:aci:'::' This will remove the old value that IPA 3.x users still have. I see you already changed the ACI in 7cdc417, in dns.ldif only. Be sureto use the original value for . -- Petr? From abokovoy at redhat.com Wed Jun 25 10:18:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 13:18:37 +0300 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1403643460.3523.5.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <1403643460.3523.5.camel@ipa.example.com> Message-ID: <20140625101837.GD7233@redhat.com> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote: >> On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >> > On 3.6.2014 05:08, Nathaniel McCallum wrote: >> > > This command calls the token sync HTTP POST call in the server providing >> > > the CLI interface to synchronization. >> > > >> > > https://fedorahosted.org/freeipa/ticket/4260 >> > > >> > > This patch depends on my patch #0055. >> > > >> > >> > Build fails on validation. You forgot to update API.txt and also the >> > command misses __doc__. >> > >> > (not a proper review) >> >> Thanks, fixed. > >Attached is a new revision which is rebased on master. > >In addition it: > >1. Moves user to a parameter and moves token to an argument. Doing it >this way both mirrors the existing otptoken APIs and sets us up for >future Kerberos based syncing where the username/password will be >optional. > >2. Converts the token ID to a DN. ACK. Please do not commit this patch yet, we are not done with its dependencies. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Jun 25 10:21:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 13:21:39 +0300 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support In-Reply-To: <1403641921.3523.2.camel@ipa.example.com> References: <1401764823.4161.4.camel@ipa.example.com> <1403641921.3523.2.camel@ipa.example.com> Message-ID: <20140625102139.GE7233@redhat.com> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: >> This HTTP call takes the following parameters: >> * user >> * password >> * first_code >> * second_code >> * token (optional) >> >> Using this information, the server will perform token synchronization. >> If the token is not specified, all tokens will be searched for >> synchronization. >> Otherwise, only the token specified will be searched. >> >> This patch depends on my patch #0054. > >Attached is a new revision. This version should force an update >to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. ACK with condition that you apply attached fixups. Since token that is passed by 'ipa otptoken-sync' command is not a full DN, we need to support both cases, when DN and just a name is passed. Attached patch fixes this. -- / Alexander Bokovoy -------------- next part -------------- >From ac31c6c6ce0b7bc163696968e07e8dd3c75accef Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 25 Jun 2014 13:17:08 +0300 Subject: [PATCH 9/9] fixup! Add /session/token_sync POST support --- ipaserver/rpcserver.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py index 39134af..33d03e2 100644 --- a/ipaserver/rpcserver.py +++ b/ipaserver/rpcserver.py @@ -1165,8 +1165,12 @@ class sync_token(Backend, HTTP_Status): sr.setComponentByName('firstCode', data['first_code']) sr.setComponentByName('secondCode', data['second_code']) if 'token' in data: - token_dn = DN((self.api.Object.otptoken.primary_key.name, data['token']), - self.api.env.container_otp, self.api.env.basedn) + try: + token_dn = DN(data['token']) + except ValueError: + token_dn = DN((self.api.Object.otptoken.primary_key.name, data['token']), + self.api.env.container_otp, self.api.env.basedn) + sr.setComponentByName('tokenDN', str(token_dn)) rc = ldap.controls.RequestControl(sr.OID, True, encoder.encode(sr)) -- 1.9.3 From abokovoy at redhat.com Wed Jun 25 10:35:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 13:35:11 +0300 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403557986.3263.7.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <1403557986.3263.7.camel@ipa.example.com> Message-ID: <20140625103511.GF7233@redhat.com> On Mon, 23 Jun 2014, Nathaniel McCallum wrote: >On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: >> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >> >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: >> >> This command behaves almost exactly like otptoken-add except: >> >> 1. The new token data is written directly to a YubiKey >> >> 2. The vendor/model/serial fields are populated from the YubiKey >> >> >> >> === NOTE === >> >> 1. This patch depends on the new Fedora package: python-yubico. If you >> >> would like to help with the package review, please assign yourself here: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 >> > >> >New version of the patch. This one works (yay!). >> > >> >1. Because of the dependency on python-yubico, is this feature something >> >we want in core FreeIPA? As a subpackage? Separate project altogether? >> >The only dependency for python-yubico is pyusb. >> I'd prefer to have it integrated but have a separate dummy subpackage >> that pulls in all required dependencies, like, freeipa-tools-yubico. Instead >> of failing when 'ipa otptoken-add-yubikey' is called, please wrap the >> python-yubico import into a code that allows reporting a message back to >> the user advising to install the package. >> >> Who is a supposed user for this command? IPA command line interface isn't >> usually available on enrolled machines even though underlying Python >> modules are all there. Are we talking about admins or just users? > >As discussed on IRC, we are currently hard-coding lots of optional >dependencies. And breaking this apart into subpackages can be solved at >a later point. YubiKey is also a unique case: we don't expect to be >adding many more plugins like this. > >For these reasons, I have kept this as a hard dependency. To ease this >transition, I have added python-yubico to F20 and EL6. You can help with >the update review here: >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 > >> >3. This code currently emits a warning from the call to otptoken-add: >> >WARNING: API Version number was not sent, forward compatibility not >> >guaranteed. Assuming server's API version, 2.89 >> > >> >How do I fix this? >> Do not filter 'version' field in options in execute(). > >I opted to not filter out version rather than hard-code it (pviktori's >suggestion). This is based on the fact that otptoken-add-yubikey is >tightly integrated with otptoken-add (even using some of the class >attributes from otptoken). > >> >4. I am not sure why I have to delete the summary and value keys from >> >the return dictionary. It would be nice to display this summary message >> >just like otptoken-add. > >I still need help on this. > >> >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These >> >aren't user settable, but we need to pass them from the yubikey >> >(client-side) to the server. > >This is no longer needed since I am doing everything in forward(). >However, listing these three as output params causes them to appear >before the token's ID. I don't think this is the right way to output >these. But this seems to me a framework issue. > >> >6. I'm not sure my use of assert or ValueError are correct. What should >> >I do here? > >Still need help here. Fixed this part. > >> >7. Considering that this is just a specialized invocation of >> >otptoken-add, can't we do this all on the client-side? This is why I had >> >originally used frontend.Local rather than frontend.Command. >> You don't need to implement execute then, only forward, where you'll >> forward your call to the server under otptoken_add name. >> >> Typically in #forward we call super's forward but that is because we >> in Command.forward() we simply forward the command to the remote backend, >> using the self.name. In your case we shouldn't really have a separate >> command on the server under the same name, so you'll need to avoid >> calling >> >> So, it should look like this: >> >> def forward(self, *args, **kw): >> perform yubikey initialization >> filter out kw and args, if needed >> return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) >> >> See service_show implementation for an example. > >Fixed. I'm attaching few fixups to the patch that make it proper reporting for non-Yubikey case and also properly update VERSION. Provisional ACK. -- / Alexander Bokovoy -------------- next part -------------- >From 1c83f1943a635a4b2541addd9fc21b6155fb12d6 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 25 Jun 2014 13:32:16 +0300 Subject: [PATCH 10/10] fixup! Add the otptoken-add-yubikey command --- ipalib/plugins/otptoken_yubikey.py | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/ipalib/plugins/otptoken_yubikey.py b/ipalib/plugins/otptoken_yubikey.py index 30a81e5..b4f2188 100644 --- a/ipalib/plugins/otptoken_yubikey.py +++ b/ipalib/plugins/otptoken_yubikey.py @@ -18,6 +18,7 @@ # along with this program. If not, see . from ipalib import _, Str, IntEnum +from ipalib.errors import NotFound from ipalib.plugable import Registry from ipalib.frontend import Command from ipalib.plugins.otptoken import otptoken @@ -78,7 +79,11 @@ class otptoken_add_yubikey(Command): def forward(self, *args, **kwargs): # Open the YubiKey - yk = yubico.find_yubikey() + try: + yk = yubico.find_yubikey() + except yubico.yubikey.YubiKeyError, e: + raise NotFound(reason=_('No YubiKey found')) + assert yk.version_num() >= (2, 1) # If no slot is specified, find the first free slot. @@ -87,7 +92,7 @@ class otptoken_add_yubikey(Command): used = yk.status().valid_configs() kwargs['slot'] = sorted({1, 2}.difference(used))[0] except IndexError: - raise ValueError('No free YubiKey slot!') + raise NotFound(reason=_('No free YubiKey slot!')) # Create the key (NOTE: the length is fixed). key = os.urandom(20) -- 1.9.3 -------------- next part -------------- >From 3f8d3d009cc45fb28a937770bb370646a4261c39 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 25 Jun 2014 09:37:18 +0300 Subject: [PATCH 07/10] fixup! Add the otptoken-add-yubikey command --- VERSION | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/VERSION b/VERSION index 65e5273..f0c2db5 100644 --- a/VERSION +++ b/VERSION @@ -89,5 +89,5 @@ IPA_DATA_VERSION=20100614120000 # # ######################################################## IPA_API_VERSION_MAJOR=2 -IPA_API_VERSION_MINOR=93 -# Last change: mbasti - New record type added: DLV +IPA_API_VERSION_MINOR=94 +# Last change: npmaccallum - otptoken-add-yubikey -- 1.9.3 From abokovoy at redhat.com Wed Jun 25 10:40:01 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 13:40:01 +0300 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <1403128499.6477.18.camel@ipa.example.com> References: <1399999125.2512.9.camel@ipa.example.com> <1403127281.6477.16.camel@ipa.example.com> <1403128109.12884.76.camel@willson.usersys.redhat.com> <1403128499.6477.18.camel@ipa.example.com> Message-ID: <20140625104001.GG7233@redhat.com> On Wed, 18 Jun 2014, Nathaniel McCallum wrote: >On Wed, 2014-06-18 at 17:48 -0400, Simo Sorce wrote: >> On Wed, 2014-06-18 at 17:34 -0400, Nathaniel McCallum wrote: >> > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: >> > > This patch adds support for importing tokens using RFC 6030 key >> > > container files. This includes decryption support. For sysadmin sanity, >> > > any tokens which fail to add will be written to the output file for >> > > examination. The main use case here is where a small subset of a large >> > > set of tokens fails to validate or add. Using the output file, the >> > > sysadmin can attempt to recover these specific tokens. >> > > >> > > This code is implemented as a server-side script. However, it doesn't >> > > actually need to run on the server. This was done because importing is >> > > an odd fit for the IPA command framework: >> > > 1. We need to write an output file. >> > > 2. The operation may be long-running (thousands of tokens). >> > > 3. Only admins need to perform this task and it only happens >> > > infrequently. >> > >> > Attached is revision 4. I believe this addresses all the points given >> > over the last few days in all emails. The ipa_otptoken_import.py has >> > been significantly reworked to make it simpler and easy to test, but >> > none of the logic has changed. >> > >> > I have removed most of the inheritance and sorted out most of the style >> > issues (like map() vs comprehension). I did not change the XML parsing >> > because it appears that network access is disabled by default. >> > >> > I have also included a test suite which should have 100% code coverage. >> > It even tests for features we don't support yet (like X.509). All tests >> > pass for me. >> > >> > Nathaniel >> >> +++ b/install/tools/man/ipa-otptoken-import.1 >> @@ -0,0 +1,36 @@ >> +.\" A man page for ipa-compat-manage >> >> Bad Copy&paste here ^^^ > >Thanks! Fixed. There is whitespace warning in the man page, needs to be fixed. Also, spec file changes are incomplete, man page is not there. The patch itself works fine for me with the test suite. Attached is the specfile fix, with that one and whitespace removal -- ACK. Attached also is a small fix for ipaplatform changes as specfile now has wrong scoping for the platform files. -- / Alexander Bokovoy -------------- next part -------------- >From c4c303fc471e8ad2561bd8e3180985485981472d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 25 Jun 2014 09:46:39 +0300 Subject: [PATCH 08/10] fixup! Implement OTP token importing --- freeipa.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 63f7477..2ba9786 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -775,6 +775,7 @@ fi %{_mandir}/man1/ipa-backup.1.gz %{_mandir}/man1/ipa-restore.1.gz %{_mandir}/man1/ipa-advise.1.gz +%{_mandir}/man1/ipa-otptoken-import.1.gz %files server-trust-ad %{_sbindir}/ipa-adtrust-install -- 1.9.3 -------------- next part -------------- >From 6e5aabecc290e170882f53de52987d675a9b78b6 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 24 Jun 2014 15:51:45 +0300 Subject: [PATCH 06/10] Fix packaging issue with doubly specified directories --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index ed125e5..63f7477 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -837,7 +837,7 @@ fi %dir %{python_sitelib}/ipaplatform %dir %{python_sitelib}/ipaplatform/base %dir %{python_sitelib}/ipaplatform/fedora -%{python_sitelib}/ipaplatform/* +%{python_sitelib}/ipaplatform/*.py* %{python_sitelib}/ipaplatform/base/*.py* %{python_sitelib}/ipaplatform/fedora/*.py* %attr(0644,root,root) %{python_sitearch}/default_encoding_utf8.so -- 1.9.3 From mkosek at redhat.com Wed Jun 25 11:03:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jun 2014 13:03:02 +0200 Subject: [Freeipa-devel] [PATCH 0053] Implement OTP token importing In-Reply-To: <20140625104001.GG7233@redhat.com> References: <1399999125.2512.9.camel@ipa.example.com> <1403127281.6477.16.camel@ipa.example.com> <1403128109.12884.76.camel@willson.usersys.redhat.com> <1403128499.6477.18.camel@ipa.example.com> <20140625104001.GG7233@redhat.com> Message-ID: <53AAAC66.3040409@redhat.com> On 06/25/2014 12:40 PM, Alexander Bokovoy wrote: > On Wed, 18 Jun 2014, Nathaniel McCallum wrote: >> On Wed, 2014-06-18 at 17:48 -0400, Simo Sorce wrote: >>> On Wed, 2014-06-18 at 17:34 -0400, Nathaniel McCallum wrote: >>> > On Tue, 2014-05-13 at 12:38 -0400, Nathaniel McCallum wrote: >>> > > This patch adds support for importing tokens using RFC 6030 key >>> > > container files. This includes decryption support. For sysadmin sanity, >>> > > any tokens which fail to add will be written to the output file for >>> > > examination. The main use case here is where a small subset of a large >>> > > set of tokens fails to validate or add. Using the output file, the >>> > > sysadmin can attempt to recover these specific tokens. >>> > > >>> > > This code is implemented as a server-side script. However, it doesn't >>> > > actually need to run on the server. This was done because importing is >>> > > an odd fit for the IPA command framework: >>> > > 1. We need to write an output file. >>> > > 2. The operation may be long-running (thousands of tokens). >>> > > 3. Only admins need to perform this task and it only happens >>> > > infrequently. >>> > >>> > Attached is revision 4. I believe this addresses all the points given >>> > over the last few days in all emails. The ipa_otptoken_import.py has >>> > been significantly reworked to make it simpler and easy to test, but >>> > none of the logic has changed. >>> > >>> > I have removed most of the inheritance and sorted out most of the style >>> > issues (like map() vs comprehension). I did not change the XML parsing >>> > because it appears that network access is disabled by default. >>> > >>> > I have also included a test suite which should have 100% code coverage. >>> > It even tests for features we don't support yet (like X.509). All tests >>> > pass for me. >>> > >>> > Nathaniel >>> >>> +++ b/install/tools/man/ipa-otptoken-import.1 >>> @@ -0,0 +1,36 @@ >>> +.\" A man page for ipa-compat-manage >>> >>> Bad Copy&paste here ^^^ >> >> Thanks! Fixed. > There is whitespace warning in the man page, needs to be fixed. > Also, spec file changes are incomplete, man page is not there. > > The patch itself works fine for me with the test suite. > > Attached is the specfile fix, with that one and whitespace removal -- > ACK. > > Attached also is a small fix for ipaplatform changes as specfile now has > wrong scoping for the platform files. I pushed all 3 patches to master. (I did not realize you want to just fixup your patch 0008 before I pushed the first, so I chosen a better name for it.) Martin From abokovoy at redhat.com Wed Jun 25 11:09:56 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 14:09:56 +0300 Subject: [Freeipa-devel] [PATCH 0054] Change OTPSyncRequest structure to use OctetString In-Reply-To: <1401217192.29756.6.camel@ipa.example.com> References: <1401217192.29756.6.camel@ipa.example.com> Message-ID: <20140625110956.GH7233@redhat.com> On Tue, 27 May 2014, Nathaniel McCallum wrote: >This change has two motivations: > 1. Clients don't have to parse the string. > 2. Future token types may have new formats. ACK, works for me. -- / Alexander Bokovoy From jcholast at redhat.com Wed Jun 25 11:13:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Jun 2014 13:13:27 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <539F5552.9070005@redhat.com> References: <5399E749.6070806@redhat.com> <539F0593.9060007@redhat.com> <539F5552.9070005@redhat.com> Message-ID: <53AAAED7.7070705@redhat.com> On 16.6.2014 22:36, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches implement >>> and >>> . >>> >>> This work depends on my patches 241-253 and 262-266 >>> (). >>> >>> Note that automatic distribution of CA certificates to IPA systems is >>> not implemented yet (it's planned for IPA 4.2, see >>> ), so /etc/ipa/ca.crt, >>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are updated >>> *only* during client/server install. >> >> 267 >> >> What is the purpose of this change? Won't this cause no certificates to >> be exported in the default case? >> >> diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py >> index 61a954f..3cd7a53 100644 >> --- a/ipaserver/install/certs.py >> +++ b/ipaserver/install/certs.py >> @@ -463,7 +463,7 @@ class CertDB(object): >> do that step.""" >> # export the CA cert for use with other apps >> ipautil.backup_file(self.cacert_fname) >> - root_nicknames = self.find_root_cert(nickname) >> + root_nicknames = self.find_root_cert(nickname)[:-1] >> fd = open(self.cacert_fname, "w") >> for root in root_nicknames: >> (cert, stderr, returncode) = self.run_certutil(["-L", "-n", >> root, "-a"]) >> >> Or are you separating out issuing CA from the rest of the chain? find_root_cert() returns the certificate chain *including* the end-entity certificate. We want only CA certificates here. This is an error introduced in the CA-less rewrite. >> >> 268 ACK >> >> 269 ACK >> >> 270 >> >> If a user has their own CA installed, such as the case where they used >> ipa-server-certinstall, this will break it. You can't install own CA with ipa-server-certinstall. I did not see anything break. >> >> What can be in the other set? Docs are needed. The "trusted" set is for trusted CA certs and the "other" set is for other CA certs. I will add a comment... >> >> You potentially add a bunch of certs with no trust, what is the purpose? "No trust" in this context means "trust only for issuing CA certificates". The certs are there for the sole purpose of forming the CA chain, so they don't need to be trusted for anything else. >> >> 271 >> >> ipaSecretKey isn't mentioned on >> http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and >> does it need to be added now? This is the schema from . It is shared with DNSSEC. I will add a comment. >> >> 272 ACK >> >> 273 ACK >> >> 274 ACK >> >> 275 ACK >> >> 276 >> >> There isn't any error handling around the ASN.1 decoder. Is that wise? Probably not, but it's consistent with the rest of the x509 module - none of its functions do error handling, it is up to the caller. BTW I have started refactoring x509 code, but didn't have time to finish. The new code will include error handling. >> >> There should be unit tests Yes. >> >> 277 >> >> There should be unit tests Yes. >> >> 278 >> >> When the certificate must be passed in as DER can you use dercert as the >> argument name so it's clear what is needed? OK. >> >> In update_ca_cert() and get_ca_certs() should the values for trust be >> case insensitive? It already is in update_ca_cert(), but get_ca_certs() does indeed need to be fixed. >> >> This breaks the convention where attribute names are always lower-case. I wasn't aware there is such a convention, especially so after seeing loads of mixed case attribute names all over IPA code. Anyway, I don't think it matters anymore, the new LDAP code has case-insensitive attribute names. >> >> I can't really grok add_ca_cert(). You are adding certs but removing >> values? Is this un-setting the list of trusted CA's maybe? It is unsetting ipaConfigString values from entries that should no longer have them. I will add a comment. >> >> There isn't a single comment in this file beyond the header. Sorry, will fix. >> >> 279 >> >> Looks ok >> >> 280 >> >> Why add the chain with no trust? See my comment for patch 270. >> >> 281 / 282 >> >> What is the difference between add_cert and import_cert other than >> passing in trust and not having the db password? Do we even need >> add_single_pem_cert anymore? add_cert adds certificate by value, import_cert loads it from a file. We don't need add_single_pem_cert anymore. >> >> 283 / 284 >> >> In __import_ca_certs() I assume the pass is there for NotFound for the >> case of creating a replica with an older master that doesn't have these? >> How is SSL trust setup then? It is for the case where there is no cn=certificates nor cn=CAcert. The trust is setup as usual, failed import does not affect it. >> >> This code looks awfully similar. Will fix. >> >> 285 >> >> ACK >> >> 286 >> >> It looks ok, just one wild thought. If writing the certificate fails and >> you go to clean up by removing ca_file, what if that removal fails, for >> the same reason the write failed, SELinux for example? Good point, will fix. >> >> 287 >> >> If this weren't addressed in a later patch I've have dinged you on the: >> >> + return [cert] >> >> There are some places where you pluralize the variables (certs) and >> others where you do not (ca_cert, existing_ca_cert). Right, will fix. >> >> 288 >> >> Is a rawcert a dercert? I'd use that name instead for consistency. It can be both DER or PEM, I used it for consistency with write_certificate(). >> >> normalize_certificate() can raise exceptions. Those should be handled in >> write_certificate_list() Actually they should be handled by the caller, the same way as with write_certificate(). (See my comment for patch 276.) >> >> 289 >> >> ACK >> >> 290 >> >> This can be dangerous because if another database is opened in the >> process things may fail. Additional warnings and red flags should be >> provided, or the context should be compared to known places this will >> blow up (e.g server). This is used only in ipa-client-install (in patch 291) and it does not blow up. >> >> 291 >> >> You use a temporary database to make cleanup easier I suppose? Did you >> test this in enforcing? Yes, it works fine. >> >> 292 >> >> Need unit tests OK. >> >> 293 >> >> Why the fixme for the x509 import? Because it's import from ipalib to ipapython. >> >> Isn't this changing already published API for >> [insert|remove]_ca_cert_into_systemwide_ca_store? Yes. I don't think this is a public API and it is changed in Tom??'s platform code refactoring anyway. >> >> 294 >> >> Can you change the old occurances of >> >> cafile = config.dir + "/ca.crt" >> >> to use CACERT instead? No, config.dir is the directory where the replica info is unpacked, not "/etc/ipa". >> >> Bad case in exception, "Ca cert file is not available". Is there any >> additional information we can provide, like what to do about it and >> where we looked? Maybe. This code is cut-and-pasted from install_ca_cert(), I did not touch it otherwise. >> >> You actually remove one occurrence of CACERT and replace it with a >> hardcoded path, is that on purpose? Yes. Currently, the CA certificate from the replica info is copied directly to /etc/ipa/ca.crt, but I want to use it only for connecting to LDAP and use whatever is in there to create /etc/ipa/ca.crt. >> >> --- >> >> I still need to do functional testing and will probably take another >> pass the changes through but this patchset generally looks ok. > > Several issues found during testing: > > 1. Enrollment from RHEL-5 fails because the entire cert chain is not > retrieved, only the issuing CA cert. > > Joining realm failed: libcurl failed to execute the HTTP POST > transaction. SSL certificate problem, verify that the CA cert is OK. > Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify failed > Installation failed. Rolling back changes. I couldn't reproduce this, I have the full certificate chain in http:///ipa/config/ca.crt. > > 2. Not quite sure the cause, but this is on a replica: > > # ldapsearch -x -Z > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > ldap_start_tls: Operations error (1) > additional info: SSL connection already established. > # extended LDIF > # > # LDAPv3 > # base (default) with scope subtree > # filter: (objectclass=*) > > Same command on initial master doesn't spit out the p11-kit errors. > > Get similar errors out of certutil: > > # certutil -L -d /etc/httpd/alias > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > p11-kit: invalid basic constraints certificate extension > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > GREYOAK.COM IPA CA CT,C,C > Server-Cert u,u,u > CN=External Authority ,, > ipaCert u,u,u > > Same version of p11-kit on both machines. > > p11-kit-trust-0.20.2-1.fc20.x86_64 > p11-kit-0.20.2-1.fc20.x86_64 This does not happen for me. I don't touch basic constraints anywhere in the code. Can I see the "CN=External Authority" certificate? > > 3. On uninstall the CA's are not removed from /etc/pki/nssdb and > /etc/httpd/alias in one of my tests (the first one, so I no longer have > the logs). Will fix. > > 4. This one isn't your issue AFAICT, not sure if you've seen this one: > > # ipa-ca-install ... > > [snip] > > 2014-06-16T18:07:44Z DEBUG stdout=Loading deployment configuration from > /tmp/tmprI2isq. > > 2014-06-16T18:07:44Z DEBUG stderr=Traceback (most recent call last): > File "/usr/sbin/pkispawn", line 530, in > main(sys.argv) > File "/usr/sbin/pkispawn", line 439, in main > info = parser.sd_get_info() > File > "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", > line 442, in sd_get_info > info = sd.getSecurityDomainInfo() > File "/usr/lib/python2.7/site-packages/pki/system.py", line 40, in > getSecurityDomainInfo > info.name = j['DomainInfo']['@id'] > KeyError: 'DomainInfo' > > 2014-06-16T18:07:44Z CRITICAL failed to configure ca instance Command > ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmprI2isq'' returned non-zero > exit status 1 > 2014-06-16T18:07:44Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 639, in run_script > return_value = main_function() I haven't seen this one. Can it be reproduced? > > 5. This one may be for Tomas, but: > > 2014-06-16T19:01:28Z INFO Deleting schedule 2358-2359 0 from agreement > cn=meTogrindle.greyoak.com,cn=replica,cn=dc\=greyoak\,dc\=com,cn=mapping > tree,cn=config > 2014-06-16T19:01:29Z ERROR unable to convert the attribute > u'nsds5replicalastupdateend' value '0' to type > 2014-06-16T19:01:29Z INFO Replication Update in progress: TRUE: status: > 0 Replica acquired successfully: Incremental update started: start: 0: > end: 0 > 2014-06-16T19:01:30Z ERROR unable to convert the attribute > u'nsds5replicalastupdateend' value '0' to type > 2014-06-16T19:01:30Z INFO Replication Update in progress: TRUE: status: > 0 Replica acquired successfully: Incremental update started: start: 0: > end: 0 > 2014-06-16T19:01:31Z ERROR unable to convert the attribute > u'nsds5replicalastupdateend' value '0' to type > 2014-06-16T19:01:31Z INFO Replication Update in progress: TRUE: status: > 0 Replica acquired successfully: Incremental update started: start: 0: > end: 0 > 2014-06-16T19:01:32Z ERROR unable to convert the attribute > u'nsds5replicalastupdateend' value '0' to type > 2014-06-16T19:01:32Z INFO Replication Update in progress: TRUE: status: > 0 Replica acquired successfully: Incremental update started: start: 0: > end: 0 I believe this is . > > 6. With an external CA install of F-20 vanilla, upgraded to this patch, > the external CA is not added to /etc/pki/nssdb. On a pure install of > this patch, it is added. Not sure if we care since the cert is in the > global cert store. Yes, that's one of the effects of "automatic distribution to clients is not implemented yet". > > 7. Something for the future, but I wonder if test test_0002_find_CA in > ipatests/test_xmlrpc/test_cert_plugin.py should be able to handle > external CAs. > > rob > -- Jan Cholasta From tbabej at redhat.com Wed Jun 25 11:47:28 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 13:47:28 +0200 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes In-Reply-To: <53AA9A25.3070506@redhat.com> References: <53A97418.7080302@redhat.com> <53A9C04B.7050102@redhat.com> <53AA9A25.3070506@redhat.com> Message-ID: <53AAB6D0.5070801@redhat.com> On 06/25/2014 11:45 AM, Petr Viktorin wrote: > On 06/24/2014 08:15 PM, Tomas Babej wrote: >> Attaching patch 234, which resolves another ACI issue related to trusts. >> >> On 06/24/2014 02:50 PM, Tomas Babej wrote: >>> Hi, >>> >>> this is a follow up patch for 232. Read access to additional attributes >>> is required for the trust objects. >>> > > First patch looks fine. > > For the second: should the trust ACIs apply to other objects than > (objectclas=ipanttrusteddomain)? > If not, we can enable "--type=trust" permissions and use it to specify > location & filter, see attached patch. > > Turns out there are also kerberos principals stored under cn=trust tree and this filter would block the access to them. Attached is a new version of 234, which allows reading krbPrincipalName as well. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0234-2-trusts-Allow-reading-system-trust-accounts-by-adtrus.patch Type: text/x-patch Size: 3820 bytes Desc: not available URL: From abokovoy at redhat.com Wed Jun 25 11:54:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Jun 2014 14:54:39 +0300 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes In-Reply-To: <53AAB6D0.5070801@redhat.com> References: <53A97418.7080302@redhat.com> <53A9C04B.7050102@redhat.com> <53AA9A25.3070506@redhat.com> <53AAB6D0.5070801@redhat.com> Message-ID: <20140625115439.GI7233@redhat.com> On Wed, 25 Jun 2014, Tomas Babej wrote: > >On 06/25/2014 11:45 AM, Petr Viktorin wrote: >> On 06/24/2014 08:15 PM, Tomas Babej wrote: >>> Attaching patch 234, which resolves another ACI issue related to trusts. >>> >>> On 06/24/2014 02:50 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> this is a follow up patch for 232. Read access to additional attributes >>>> is required for the trust objects. >>>> >> >> First patch looks fine. >> >> For the second: should the trust ACIs apply to other objects than >> (objectclas=ipanttrusteddomain)? >> If not, we can enable "--type=trust" permissions and use it to specify >> location & filter, see attached patch. >> >> >Turns out there are also kerberos principals stored under cn=trust tree >and this filter would block the access to them. > >Attached is a new version of 234, which allows reading krbPrincipalName >as well. ACK. -- / Alexander Bokovoy From mkosek at redhat.com Wed Jun 25 12:22:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jun 2014 14:22:42 +0200 Subject: [Freeipa-devel] [PATCH 0054] Change OTPSyncRequest structure to use OctetString In-Reply-To: <20140625110956.GH7233@redhat.com> References: <1401217192.29756.6.camel@ipa.example.com> <20140625110956.GH7233@redhat.com> Message-ID: <53AABF12.4050609@redhat.com> On 06/25/2014 01:09 PM, Alexander Bokovoy wrote: > On Tue, 27 May 2014, Nathaniel McCallum wrote: >> This change has two motivations: >> 1. Clients don't have to parse the string. >> 2. Future token types may have new formats. > ACK, works for me. > Pushed to master: 7b15fcd57b06482be36e95e50cbec596777955b4 Martin From mbasti at redhat.com Wed Jun 25 12:29:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 14:29:01 +0200 Subject: [Freeipa-devel] [PATCH 0270-0271] Add TLSA and DLV RR types to LDAP schema In-Reply-To: <53A99375.7030602@redhat.com> References: <53A99375.7030602@redhat.com> Message-ID: <1403699341.2323.2.camel@unused-4-145.brq.redhat.com> On Tue, 2014-06-24 at 17:04 +0200, Petr Spacek wrote: > Hello, > > Add TLSA and DLV RR types to LDAP schema. > > Those RR types will be handy for DNSSEC users. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patch 270 LGTM Patch 271 NACK: You have to add the 'TLSARecord' attribute to idnsRecord objectclass -- Martin^2 Basti From mbasti at redhat.com Wed Jun 25 12:31:22 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 14:31:22 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSEC: Add TLSA record Message-ID: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 Patches attached. Note: ACI will be updated in another patch which fix ACIs in DNS plugin -- Martin^2 Basti From mbasti at redhat.com Wed Jun 25 12:35:57 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 14:35:57 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSEC: Add TLSA record In-Reply-To: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> Message-ID: <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: > Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 > Patches attached. > > Note: ACI will be updated in another patch which fix ACIs in DNS plugin Patches are here -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0078-DNSSEC-add-TLSA-record-type.patch Type: text/x-patch Size: 22893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0079-DNSSEC-WebUI-add-TLSA-record.patch Type: text/x-patch Size: 1816 bytes Desc: not available URL: From mkosek at redhat.com Wed Jun 25 12:36:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Jun 2014 14:36:14 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> <53A98D08.1090005@redhat.com> <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53AAC23E.2050406@redhat.com> On 06/24/2014 04:52 PM, Martin Basti wrote: > On Tue, 2014-06-24 at 16:36 +0200, Martin Kosek wrote: >> On 06/18/2014 01:46 PM, Martin Basti wrote: >>> On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: >>>> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: >>>>> Patches attached, require patches mbasti 0052-0055. >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Rebased patches attached. >>>> PEP8 fixes. >>>> >>> Sorry, patches are here >> >> 66.2: >> >> 1) Is it OK to just change constants in the update plugins? >> >> -PRE_UPDATE = 1 >> -POST_UPDATE = 2 >> +PRE_SCHEMA_UPDATE = 1 >> +PRE_UPDATE = 2 >> +POST_UPDATE = 3 >> >> When people refer to the types via names, it should be OK. It just seemed >> unnecessary to me. >> > I checked where the constants are used, and it shouldn't broke anything. > It looks weird to me to have something which happens first with last > number. > Should I set PRE_SCHEMA_UPDATE = 3 and leave other unchanged then? Ok, either update it or set it to 0. Up to you. > >> 67.2: >> >> 1) update_check_forwardzones: >> >> I think we should set update_to_forward_zones to False when the objectclass is >> there and add a check at the beginning of the execute to simply bail out, if >> update_to_forward_zones is present in the sysupgrade file. >> >> This will prevent the objectclass check (which takes some time) to run again >> and again. > Good point thanks. > >> 2) I would use different backup name: >> >> + backup_filename = u'master-zones-transform-backup.ldif' >> >> Probably something based on time so that different installations' backup do not >> step on each other. You can inspire yourself in other backup files we create: >> >> # ll /var/lib/ipa/backup/ >> total 16 >> drwx------. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13 >> drwx------. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09 >> drwx------. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21 >> -rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif > Is this better: forward-zones-transform-%datetime%.ldif ? It is. I would do something like "dns-forward-zones-backup-YYYY-MM-DD.ldif to match existing files. Martin From pviktori at redhat.com Wed Jun 25 13:02:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 15:02:12 +0200 Subject: [Freeipa-devel] [PATCH 0233] trusts: Add more read attributes In-Reply-To: <20140625115439.GI7233@redhat.com> References: <53A97418.7080302@redhat.com> <53A9C04B.7050102@redhat.com> <53AA9A25.3070506@redhat.com> <53AAB6D0.5070801@redhat.com> <20140625115439.GI7233@redhat.com> Message-ID: <53AAC854.2050403@redhat.com> On 06/25/2014 01:54 PM, Alexander Bokovoy wrote: > On Wed, 25 Jun 2014, Tomas Babej wrote: >> >> On 06/25/2014 11:45 AM, Petr Viktorin wrote: >>> On 06/24/2014 08:15 PM, Tomas Babej wrote: >>>> Attaching patch 234, which resolves another ACI issue related to >>>> trusts. >>>> >>>> On 06/24/2014 02:50 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> this is a follow up patch for 232. Read access to additional >>>>> attributes >>>>> is required for the trust objects. >>>>> >>> >>> First patch looks fine. >>> >>> For the second: should the trust ACIs apply to other objects than >>> (objectclas=ipanttrusteddomain)? >>> If not, we can enable "--type=trust" permissions and use it to specify >>> location & filter, see attached patch. >>> >>> >> Turns out there are also kerberos principals stored under cn=trust tree >> and this filter would block the access to them. >> >> Attached is a new version of 234, which allows reading krbPrincipalName >> as well. > > ACK. > Pushed to master: c2e6b74029e08a4eadb7a14a4c711febfc83b5be -- Petr? From edewata at redhat.com Wed Jun 25 13:30:49 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Jun 2014 08:30:49 -0500 Subject: [Freeipa-devel] [PATCH] 667 webui-ci: adjust tests to dns changes In-Reply-To: <53A1765D.90009@redhat.com> References: <53A1765D.90009@redhat.com> Message-ID: <53AACF09.1090208@redhat.com> On 6/18/2014 6:22 AM, Petr Vobornik wrote: > All DNS Zone names must be fully qualified. Assuming test works, ACK. -- Endi S. Dewata From edewata at redhat.com Wed Jun 25 13:30:55 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Jun 2014 08:30:55 -0500 Subject: [Freeipa-devel] [PATCH] 668 webui: fix field's default value In-Reply-To: <53A17662.107@redhat.com> References: <53A17662.107@redhat.com> Message-ID: <53AACF0F.5040200@redhat.com> On 6/18/2014 6:22 AM, Petr Vobornik wrote: > Fields with default value, such as DNS Zone's idnsforwardpolicy, were > marked as dirty when no value was loaded and when default value of > input control was other than empty. > > Fixes regression in DNS Zone details facet - facet is always dirty. ACK. -- Endi S. Dewata From edewata at redhat.com Wed Jun 25 13:31:02 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Jun 2014 08:31:02 -0500 Subject: [Freeipa-devel] [PATCH] 669 webui: don't limit permission search in privileges In-Reply-To: <53A8513A.7040502@redhat.com> References: <53A8513A.7040502@redhat.com> Message-ID: <53AACF16.60507@redhat.com> On 6/23/2014 11:09 AM, Petr Vobornik wrote: > Search for privileges was limited to bindruletype==permission. There > was no reason to do that. > > This patch removes the restriction. > > Related to: > https://fedorahosted.org/freeipa/ticket/4079 ACK. -- Endi S. Dewata From pvoborni at redhat.com Wed Jun 25 13:51:50 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Jun 2014 15:51:50 +0200 Subject: [Freeipa-devel] [PATCH] 678-679 webui: send API version in RPC requests and adapt to new response format Message-ID: <53AAD3F6.3070101@redhat.com> ticket: https://fedorahosted.org/freeipa/ticket/4394 == [PATCH] 678 webui: send API version in RPC requests == Currently there is an incorrect behavior that server doesn't send datetime and dnsname data in new format. This patch adds the version to each RPC request making the UI look as the latest client. Server then sends data in correct format. It also removes the "unknown version" warning from each RPC response. == [PATCH] 679 webui: extract rpc value from object envelope == adapt Web UI to a newer style of encapsulation object data -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0679-webui-extract-rpc-value-from-object-envelope.patch Type: text/x-patch Size: 7774 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0678-webui-send-API-version-in-RPC-requests.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 25 13:53:12 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Jun 2014 09:53:12 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <20140625103511.GF7233@redhat.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <1403557986.3263.7.camel@ipa.example.com> <20140625103511.GF7233@redhat.com> Message-ID: <1403704392.3523.13.camel@ipa.example.com> On Wed, 2014-06-25 at 13:35 +0300, Alexander Bokovoy wrote: > On Mon, 23 Jun 2014, Nathaniel McCallum wrote: > >On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: > >> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: > >> >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: > >> >> This command behaves almost exactly like otptoken-add except: > >> >> 1. The new token data is written directly to a YubiKey > >> >> 2. The vendor/model/serial fields are populated from the YubiKey > >> >> > >> >> === NOTE === > >> >> 1. This patch depends on the new Fedora package: python-yubico. If you > >> >> would like to help with the package review, please assign yourself here: > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > >> > > >> >New version of the patch. This one works (yay!). > >> > > >> >1. Because of the dependency on python-yubico, is this feature something > >> >we want in core FreeIPA? As a subpackage? Separate project altogether? > >> >The only dependency for python-yubico is pyusb. > >> I'd prefer to have it integrated but have a separate dummy subpackage > >> that pulls in all required dependencies, like, freeipa-tools-yubico. Instead > >> of failing when 'ipa otptoken-add-yubikey' is called, please wrap the > >> python-yubico import into a code that allows reporting a message back to > >> the user advising to install the package. > >> > >> Who is a supposed user for this command? IPA command line interface isn't > >> usually available on enrolled machines even though underlying Python > >> modules are all there. Are we talking about admins or just users? > > > >As discussed on IRC, we are currently hard-coding lots of optional > >dependencies. And breaking this apart into subpackages can be solved at > >a later point. YubiKey is also a unique case: we don't expect to be > >adding many more plugins like this. > > > >For these reasons, I have kept this as a hard dependency. To ease this > >transition, I have added python-yubico to F20 and EL6. You can help with > >the update review here: > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 > > > >> >3. This code currently emits a warning from the call to otptoken-add: > >> >WARNING: API Version number was not sent, forward compatibility not > >> >guaranteed. Assuming server's API version, 2.89 > >> > > >> >How do I fix this? > >> Do not filter 'version' field in options in execute(). > > > >I opted to not filter out version rather than hard-code it (pviktori's > >suggestion). This is based on the fact that otptoken-add-yubikey is > >tightly integrated with otptoken-add (even using some of the class > >attributes from otptoken). > > > >> >4. I am not sure why I have to delete the summary and value keys from > >> >the return dictionary. It would be nice to display this summary message > >> >just like otptoken-add. > > > >I still need help on this. > > > >> >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These > >> >aren't user settable, but we need to pass them from the yubikey > >> >(client-side) to the server. > > > >This is no longer needed since I am doing everything in forward(). > >However, listing these three as output params causes them to appear > >before the token's ID. I don't think this is the right way to output > >these. But this seems to me a framework issue. > > > >> >6. I'm not sure my use of assert or ValueError are correct. What should > >> >I do here? > > > >Still need help here. > Fixed this part. > > > > >> >7. Considering that this is just a specialized invocation of > >> >otptoken-add, can't we do this all on the client-side? This is why I had > >> >originally used frontend.Local rather than frontend.Command. > >> You don't need to implement execute then, only forward, where you'll > >> forward your call to the server under otptoken_add name. > >> > >> Typically in #forward we call super's forward but that is because we > >> in Command.forward() we simply forward the command to the remote backend, > >> using the self.name. In your case we shouldn't really have a separate > >> command on the server under the same name, so you'll need to avoid > >> calling > >> > >> So, it should look like this: > >> > >> def forward(self, *args, **kw): > >> perform yubikey initialization > >> filter out kw and args, if needed > >> return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) > >> > >> See service_show implementation for an example. > > > >Fixed. > I'm attaching few fixups to the patch that make it proper reporting for > non-Yubikey case and also properly update VERSION. > > Provisional ACK. Merged. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058.3-Add-the-otptoken-add-yubikey-command.patch Type: text/x-patch Size: 7176 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 25 13:54:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 15:54:10 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix incompatible DNS permission In-Reply-To: <1403270888.2336.19.camel@unused-4-145.brq.redhat.com> References: <1403270888.2336.19.camel@unused-4-145.brq.redhat.com> Message-ID: <53AAD482.4060502@redhat.com> On 06/20/2014 03:28 PM, Martin Basti wrote: > Patch attached. > > Ticket:https://fedorahosted.org/freeipa/ticket/4383 This works, just two comments: To check if an entry exists, instead of calling api.Command['permission_show'](permission_name_rel) you should call the more light-weight api.Object[permission].get_dn_if_exists(permission_name_rel) And for translated messages, use: _('message about %(topic)s") % {...} rather than: _('message about %(topic)s" % {...}) In other words, _() must be called on a literal string. Otherwise it couldn't be looked up in the translation database (or even picked up by gettext). -- Petr? From tbabej at redhat.com Wed Jun 25 14:01:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 16:01:41 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AA8CCD.6000604@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> Message-ID: <53AAD645.3080102@redhat.com> On 06/25/2014 10:48 AM, Petr Viktorin wrote: > On 06/19/2014 03:52 PM, Tomas Babej wrote: >> >> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>> Attached is a new version of patch 226, and a new patch 228, which >>>>> moves >>>>> the paths from installers to the paths module. >>>> In patch 226, there's another "certificated" typo in >>>> remove_ca_cert_from_systemwide_ca_store >>>> >>>>> I greped the repository, and I do not see many paths lurking >>>>> around any >>>>> more, there are only some in the error messages (as these can't be >>>>> reliably replaced automatically, and will need some manual love). >>>>> >>>>> If you see any forgotten paths, which should be added to the >>>>> module, let >>>>> me know. > > Well, since you asked... > > install/tools/ipa-upgradeconfig:236: > ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' > ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", > > ipaserver/install/dsinstance.py:209:InstallLdifFile= > /var/lib/dirsrv/boot.ldif > ipaserver/install/dsinstance.py:210:inst_dir= > /var/lib/dirsrv/scripts-$SERVERID > > ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', > > ipatests/test_integration/tasks.py:451: host.run_command("find > /var/lib/sss/db -name '*.ldb' | " > > install/tools/ipa-replica-conncheck:403: > "/usr/sbin/ipa-replica-conncheck " + > install/tools/ipa-replica-conncheck:414: > print_info("/usr/sbin/ipa-replica-conncheck " + " > ".join(remote_check_opts)) > > ipapython/ipautil.py:296: env["PATH"] = > "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" > > ipaserver/install/cainstance.py:88:ConfigFile = > /usr/share/pki/ca/conf/database.ldif > > ipaserver/install/bindinstance.py:829: > ipautil.run(['/usr/libexec/generate-rndc-key.sh']) > /me will think twice about teasing nex time. This are paths requiring manual changes in one way or the other and as such cannot be handled by my tool. Let's not stall the patcheset on this. We can fix these (and surely there are other) as we go along. > > I guess it'll be a while before we catch them all, but now it's at > least clear where these paths should be, so anyone porting to another > distro can send patches (or tickets) upstream. > >>>> I see another duplicate: >>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>> "/var/lib/sss/pubconf/krb5.include.d/" > > Could you just pick one instead? Would ipa_backup.py break if it had a > trailing slash here? > Yes. I verified it produces the same result with or without trailing slash, fixed. > In ipa-client-install, if you set: > NSSWITCH_CONF = paths.NSSWITCH_CONF > then you should only use one of those later. (Preferably paths.*, to > get rid of the redundant constants.) > Perhaps this is for another patch that would clean up all the cases > where these trivial module variables are used. > I agree. Fixed this occurence. >>> Fixed all mentioned issues. I also attached a patch 230, which removes >>> the base Authconfig class. > > >> Attaching one additional patch, which removes unnecessary build >> warnings. >> > > 226, 230, 231 look good > Attaching whole updated patchset. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0231-2-ipaplatform-Fix-build-warnings.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0230-2-ipaplatform-Drop-the-base-authconfig-class.patch Type: text/x-patch Size: 6053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-4-ipaplatform-Move-paths-from-installers-to-paths-modu.patch Type: text/x-patch Size: 62529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-4-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4755 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 25 14:13:46 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 16:13:46 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AAD645.3080102@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> Message-ID: <53AAD91A.2000603@redhat.com> On 06/25/2014 04:01 PM, Tomas Babej wrote: > > On 06/25/2014 10:48 AM, Petr Viktorin wrote: >> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>> >>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>> which moves >>>>>> the paths from installers to the paths module. >>>>> In patch 226, there's another "certificated" typo in >>>>> remove_ca_cert_from_systemwide_ca_store >>>>> >>>>>> I greped the repository, and I do not see many paths lurking >>>>>> around any >>>>>> more, there are only some in the error messages (as these can't be >>>>>> reliably replaced automatically, and will need some manual love). >>>>>> >>>>>> If you see any forgotten paths, which should be added to the >>>>>> module, let >>>>>> me know. >> >> Well, since you asked... >> >> install/tools/ipa-upgradeconfig:236: >> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >> >> ipaserver/install/dsinstance.py:209:InstallLdifFile= >> /var/lib/dirsrv/boot.ldif >> ipaserver/install/dsinstance.py:210:inst_dir= >> /var/lib/dirsrv/scripts-$SERVERID >> >> ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', >> >> ipatests/test_integration/tasks.py:451: host.run_command("find >> /var/lib/sss/db -name '*.ldb' | " >> >> install/tools/ipa-replica-conncheck:403: >> "/usr/sbin/ipa-replica-conncheck " + >> install/tools/ipa-replica-conncheck:414: >> print_info("/usr/sbin/ipa-replica-conncheck " + " >> ".join(remote_check_opts)) >> >> ipapython/ipautil.py:296: env["PATH"] = >> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >> >> ipaserver/install/cainstance.py:88:ConfigFile = >> /usr/share/pki/ca/conf/database.ldif >> >> ipaserver/install/bindinstance.py:829: >> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >> > > /me will think twice about teasing nex time. > > This are paths requiring manual changes in one way or the other and as > such cannot be handled by my tool. Let's not stall the patcheset on > this. We can fix these (and surely there are other) as we go along. > >> >> I guess it'll be a while before we catch them all, but now it's at >> least clear where these paths should be, so anyone porting to another >> distro can send patches (or tickets) upstream. >> >>>>> I see another duplicate: >>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>> "/var/lib/sss/pubconf/krb5.include.d/" >> >> Could you just pick one instead? Would ipa_backup.py break if it had >> a trailing slash here? >> > > Yes. I verified it produces the same result with or without trailing > slash, fixed. > > >> In ipa-client-install, if you set: >> NSSWITCH_CONF = paths.NSSWITCH_CONF >> then you should only use one of those later. (Preferably paths.*, to >> get rid of the redundant constants.) >> Perhaps this is for another patch that would clean up all the cases >> where these trivial module variables are used. >> > > I agree. Fixed this occurence. > >>>> Fixed all mentioned issues. I also attached a patch 230, which removes >>>> the base Authconfig class. >> >> >>> Attaching one additional patch, which removes unnecessary build >>> warnings. >>> >> >> 226, 230, 231 look good >> > > Attaching whole updated patchset. Attaching one more patch which should fix broken CI tests. > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0235-ipaplatform-Fix-misspelled-path-constant.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 25 14:28:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 16:28:01 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <53A145CD.7000500@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> <53A017A8.8080105@redhat.com> <53A145CD.7000500@redhat.com> Message-ID: <53AADC71.8090509@redhat.com> On 06/18/2014 09:54 AM, Petr Viktorin wrote: > On 06/17/2014 12:25 PM, Tomas Babej wrote: >> >> On 05/26/2014 06:20 PM, Petr Viktorin wrote: >>> On 05/20/2014 06:15 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> the following set of patches fixes: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4274 >>>> https://fedorahosted.org/freeipa/ticket/4263 >>>> https://fedorahosted.org/freeipa/ticket/4324 >>>> https://fedorahosted.org/freeipa/ticket/4340 >>>> https://fedorahosted.org/freeipa/ticket/4341 >>>> >>>> and additional minor issues. >>>> >>>> The improvemed CI test coverage for the sudorule plugin is added as a >>>> bonus. > > You've dropped most of the long commit messages and ticket URLs. Why? Sorry about that.. fixed! > > >>> 0187: OK > >>> (Speaking of PEP8, if you could remove the baseldap star import from >>> sudorule.py, it would be great...) >>> >>> >> This one did hurt, but the star disappeared. > > Thank you, much appreciated. > (Especially the fact that Int is no longer imported from baseldap) > >>> General thoughts: >>> >>> Would it be possible to merge schema_compat.uldif and >>> install/updates/10-schema_compat.update into one file? Is the uldif >>> special somehow? I guess this is a question for Rob. >>> It would be nice to add a link to some schema-compat-entry-attribute >>> documentation to these files. >>> >> I added Rob to cc. Rob, can you elaborate on this? > > >>> 0188 - sudorule: Allow using hostmasks for setting allowed hosts > > If I run sudorule-add-host / sudorule-remove-host with a hostmask, but > not host/hostgroup, I get prompted for host and hostgroup. I don't > think that's the intended behavior. This problem is beyond this patchset. Observe that same thing happens with ipa group-add-member --external. I'm not sure if there's a ticket for this though. > > 0189: OK > 0190: OK > 0191: OK > 0192: OK > >>> 0193 sudorule: Make sure all the relevant attributes are checked when >>> setting category to ALL > >>> You're missing the `_` for the hostcategory error message. >>> Did you think about using something like _("%s cannot be set to 'all' >>> while there are %s")? >>> >> Fixed. Initially, I changed the message as you suggested, but then I >> realized, that this might pose a problem for translations that do not >> follow the word order in the sentence as it is defined in English >> language. > > Right, sorry for the incorrect example. You can use named > substitutions for that: > _("can't %(action)s while %(state)s") % {'action': 'move', > 'state': 'asleep'} > > One more thing - the function is only called once, could you move it > to the for loop? > Fixed! > 0194: OK > 0195: OK > 0196-0198: OK > 0199-0201: OK > > 0225: > Looks good. Could you also document the arguments & return value in > *_external_post_callback docstrings? > > I did. The updated patchset attached. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0225-2-sudorule-Refactor-add-and-remove-external_post_callb.patch Type: text/x-patch Size: 22803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0187-4-sudorule-PEP8-fixes-in-sudorule.py.patch Type: text/x-patch Size: 18390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0188-4-sudorule-Allow-using-hostmasks-for-setting-allowed-h.patch Type: text/x-patch Size: 11271 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0189-4-sudorule-Allow-using-external-groups-as-groups-of-ru.patch Type: text/x-patch Size: 14011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0190-4-sudorule-Make-sure-sudoRunAsGroup-is-dereferencing-t.patch Type: text/x-patch Size: 2864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0191-4-sudorule-Include-externalhost-and-ipasudorunasextgro.patch Type: text/x-patch Size: 1215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0192-4-sudorule-Allow-adding-deny-commands-when-command-cat.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0193-4-sudorule-Make-sure-all-the-relevant-attributes-are-c.patch Type: text/x-patch Size: 4301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0194-4-sudorule-Fix-the-order-of-the-parameters-to-have-les.patch Type: text/x-patch Size: 2984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0195-4-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch Type: text/x-patch Size: 4943 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0196-4-ipatests-test_sudo-Add-tests-for-allowing-hosts-via-.patch Type: text/x-patch Size: 2625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0197-4-ipatests-test_sudo-Add-coverage-for-external-entries.patch Type: text/x-patch Size: 6890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0201-4-ipatests-test_sudo-Expect-root-listed-out-if-no-RunA.patch Type: text/x-patch Size: 1544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0198-4-ipatests-test_sudo-Add-coverage-for-category-ALL-val.patch Type: text/x-patch Size: 15765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0199-4-ipatests-test_sudo-Fix-assertions-not-assuming-runas.patch Type: text/x-patch Size: 4708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0200-4-ipatests-test_sudo-Do-not-expect-enumeration-of-runa.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: From pvoborni at redhat.com Wed Jun 25 14:38:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Jun 2014 16:38:02 +0200 Subject: [Freeipa-devel] [PATCH] 667 webui-ci: adjust tests to dns changes In-Reply-To: <53AACF09.1090208@redhat.com> References: <53A1765D.90009@redhat.com> <53AACF09.1090208@redhat.com> Message-ID: <53AADECA.8070509@redhat.com> On 25.6.2014 15:30, Endi Sukma Dewata wrote: > On 6/18/2014 6:22 AM, Petr Vobornik wrote: >> All DNS Zone names must be fully qualified. > > Assuming test works, ACK. > pushed to master: 15374cf58fe26396be7bc70d7133b501b11dad6d webui-ci: adjust tests to dns changes -- Petr Vobornik From pvoborni at redhat.com Wed Jun 25 14:38:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Jun 2014 16:38:29 +0200 Subject: [Freeipa-devel] [PATCH] 668 webui: fix field's default value In-Reply-To: <53AACF0F.5040200@redhat.com> References: <53A17662.107@redhat.com> <53AACF0F.5040200@redhat.com> Message-ID: <53AADEE5.8020602@redhat.com> On 25.6.2014 15:30, Endi Sukma Dewata wrote: > On 6/18/2014 6:22 AM, Petr Vobornik wrote: >> Fields with default value, such as DNS Zone's idnsforwardpolicy, were >> marked as dirty when no value was loaded and when default value of >> input control was other than empty. >> >> Fixes regression in DNS Zone details facet - facet is always dirty. > > ACK. > pushed to master: bfdf9039ce6396e343f85d475f589efd57d13304 webui: fix field's default value -- Petr Vobornik From pvoborni at redhat.com Wed Jun 25 14:41:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Jun 2014 16:41:17 +0200 Subject: [Freeipa-devel] [PATCH] 669 webui: don't limit permission search in privileges In-Reply-To: <53AACF16.60507@redhat.com> References: <53A8513A.7040502@redhat.com> <53AACF16.60507@redhat.com> Message-ID: <53AADF8D.9070307@redhat.com> On 25.6.2014 15:31, Endi Sukma Dewata wrote: > On 6/23/2014 11:09 AM, Petr Vobornik wrote: >> Search for privileges was limited to bindruletype==permission. There >> was no reason to do that. >> >> This patch removes the restriction. >> >> Related to: >> https://fedorahosted.org/freeipa/ticket/4079 > > ACK. > pushed to master: 6dab9123be1d4c2db8a194d00f05884738fb692a webui: don't limit permission search in privileges -- Petr Vobornik From tbabej at redhat.com Wed Jun 25 14:59:59 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 16:59:59 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AAD91A.2000603@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> <53AAD91A.2000603@redhat.com> Message-ID: <53AAE3EF.5000005@redhat.com> On 06/25/2014 04:13 PM, Tomas Babej wrote: > > On 06/25/2014 04:01 PM, Tomas Babej wrote: >> >> On 06/25/2014 10:48 AM, Petr Viktorin wrote: >>> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>>> >>>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>>> which moves >>>>>>> the paths from installers to the paths module. >>>>>> In patch 226, there's another "certificated" typo in >>>>>> remove_ca_cert_from_systemwide_ca_store >>>>>> >>>>>>> I greped the repository, and I do not see many paths lurking >>>>>>> around any >>>>>>> more, there are only some in the error messages (as these can't be >>>>>>> reliably replaced automatically, and will need some manual love). >>>>>>> >>>>>>> If you see any forgotten paths, which should be added to the >>>>>>> module, let >>>>>>> me know. >>> >>> Well, since you asked... >>> >>> install/tools/ipa-upgradeconfig:236: >>> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >>> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >>> >>> ipaserver/install/dsinstance.py:209:InstallLdifFile= >>> /var/lib/dirsrv/boot.ldif >>> ipaserver/install/dsinstance.py:210:inst_dir= >>> /var/lib/dirsrv/scripts-$SERVERID >>> >>> ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', >>> >>> ipatests/test_integration/tasks.py:451: host.run_command("find >>> /var/lib/sss/db -name '*.ldb' | " >>> >>> install/tools/ipa-replica-conncheck:403: >>> "/usr/sbin/ipa-replica-conncheck " + >>> install/tools/ipa-replica-conncheck:414: >>> print_info("/usr/sbin/ipa-replica-conncheck " + " >>> ".join(remote_check_opts)) >>> >>> ipapython/ipautil.py:296: env["PATH"] = >>> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >>> >>> ipaserver/install/cainstance.py:88:ConfigFile = >>> /usr/share/pki/ca/conf/database.ldif >>> >>> ipaserver/install/bindinstance.py:829: >>> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >>> >> >> /me will think twice about teasing nex time. >> >> This are paths requiring manual changes in one way or the other and >> as such cannot be handled by my tool. Let's not stall the patcheset >> on this. We can fix these (and surely there are other) as we go along. >> >>> >>> I guess it'll be a while before we catch them all, but now it's at >>> least clear where these paths should be, so anyone porting to >>> another distro can send patches (or tickets) upstream. >>> >>>>>> I see another duplicate: >>>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>>> "/var/lib/sss/pubconf/krb5.include.d/" >>> >>> Could you just pick one instead? Would ipa_backup.py break if it had >>> a trailing slash here? >>> >> >> Yes. I verified it produces the same result with or without trailing >> slash, fixed. >> >> >>> In ipa-client-install, if you set: >>> NSSWITCH_CONF = paths.NSSWITCH_CONF >>> then you should only use one of those later. (Preferably paths.*, to >>> get rid of the redundant constants.) >>> Perhaps this is for another patch that would clean up all the cases >>> where these trivial module variables are used. >>> >> >> I agree. Fixed this occurence. >> >>>>> Fixed all mentioned issues. I also attached a patch 230, which >>>>> removes >>>>> the base Authconfig class. >>> >>> >>>> Attaching one additional patch, which removes unnecessary build >>>> warnings. >>>> >>> >>> 226, 230, 231 look good >>> >> >> Attaching whole updated patchset. > > Attaching one more patch which should fix broken CI tests. > >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Self-NACK - It seems I omitted one occurence of NSSWITCH_CONF in ipa-client-install, fixed now. Attaching the whole patchset for your convenience. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-5-ipaplatform-Fix-misspelled-path-constant.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0235-ipaplatform-Fix-misspelled-path-constant.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0231-2-ipaplatform-Fix-build-warnings.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0230-2-ipaplatform-Drop-the-base-authconfig-class.patch Type: text/x-patch Size: 6053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-4-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4755 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 25 15:03:49 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 17:03:49 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix incompatible DNS permission In-Reply-To: <53AAD482.4060502@redhat.com> References: <1403270888.2336.19.camel@unused-4-145.brq.redhat.com> <53AAD482.4060502@redhat.com> Message-ID: <1403708629.2323.7.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-25 at 15:54 +0200, Petr Viktorin wrote: > On 06/20/2014 03:28 PM, Martin Basti wrote: > > Patch attached. > > > > Ticket:https://fedorahosted.org/freeipa/ticket/4383 > > This works, just two comments: > > To check if an entry exists, instead of calling > api.Command['permission_show'](permission_name_rel) > you should call the more light-weight > api.Object[permission].get_dn_if_exists(permission_name_rel) > > And for translated messages, use: > _('message about %(topic)s") % {...} > rather than: > _('message about %(topic)s" % {...}) > In other words, _() must be called on a literal string. Otherwise it > couldn't be looked up in the translation database (or even picked up by > gettext). > Thank you for review. Updated patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0076-2-Fix-incompatible-DNS-permission.patch Type: text/x-patch Size: 2472 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 25 15:07:24 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 17:07:24 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <53AAC23E.2050406@redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> <53A98D08.1090005@redhat.com> <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> <53AAC23E.2050406@redhat.com> Message-ID: <1403708844.2323.8.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-25 at 14:36 +0200, Martin Kosek wrote: > On 06/24/2014 04:52 PM, Martin Basti wrote: > > On Tue, 2014-06-24 at 16:36 +0200, Martin Kosek wrote: > >> On 06/18/2014 01:46 PM, Martin Basti wrote: > >>> On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: > >>>> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: > >>>>> Patches attached, require patches mbasti 0052-0055. > >>>>> _______________________________________________ > >>>>> Freeipa-devel mailing list > >>>>> Freeipa-devel at redhat.com > >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >>>> Rebased patches attached. > >>>> PEP8 fixes. > >>>> > >>> Sorry, patches are here > >> > >> 66.2: > >> > >> 1) Is it OK to just change constants in the update plugins? > >> > >> -PRE_UPDATE = 1 > >> -POST_UPDATE = 2 > >> +PRE_SCHEMA_UPDATE = 1 > >> +PRE_UPDATE = 2 > >> +POST_UPDATE = 3 > >> > >> When people refer to the types via names, it should be OK. It just seemed > >> unnecessary to me. > >> > > I checked where the constants are used, and it shouldn't broke anything. > > It looks weird to me to have something which happens first with last > > number. > > Should I set PRE_SCHEMA_UPDATE = 3 and leave other unchanged then? > > Ok, either update it or set it to 0. Up to you. > > > > >> 67.2: > >> > >> 1) update_check_forwardzones: > >> > >> I think we should set update_to_forward_zones to False when the objectclass is > >> there and add a check at the beginning of the execute to simply bail out, if > >> update_to_forward_zones is present in the sysupgrade file. > >> > >> This will prevent the objectclass check (which takes some time) to run again > >> and again. > > Good point thanks. > > > >> 2) I would use different backup name: > >> > >> + backup_filename = u'master-zones-transform-backup.ldif' > >> > >> Probably something based on time so that different installations' backup do not > >> step on each other. You can inspire yourself in other backup files we create: > >> > >> # ll /var/lib/ipa/backup/ > >> total 16 > >> drwx------. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13 > >> drwx------. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09 > >> drwx------. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21 > >> -rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif > > Is this better: forward-zones-transform-%datetime%.ldif ? > > It is. I would do something like "dns-forward-zones-backup-YYYY-MM-DD.ldif to > match existing files. > > Martin Updated patches attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0066-2-Added-upgrade-step-executed-before-schmema-is-upgrad.patch Type: text/x-patch Size: 6622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0067-2-Upgrade-special-master-zones-to-forward-zones.patch Type: text/x-patch Size: 9241 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 25 15:17:46 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 17:17:46 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong Message-ID: <53AAE81A.7090805@redhat.com> Hi, Our datetime conversion does not support full LDAP Generalized time syntax. In the unsupported cases, we should fall back to string representation of the attribute. In particular, '0' is used to denote no value of LDAP generalized time attribute. https://fedorahosted.org/freeipa/ticket/4350 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0236-ipaldap-Fallback-to-string-if-datetime-conversion-we.patch Type: text/x-patch Size: 1573 bytes Desc: not available URL: From jcholast at redhat.com Wed Jun 25 15:29:05 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Jun 2014 17:29:05 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53AAE81A.7090805@redhat.com> References: <53AAE81A.7090805@redhat.com> Message-ID: <53AAEAC1.3080106@redhat.com> Hi, On 25.6.2014 17:17, Tomas Babej wrote: > Hi, > > Our datetime conversion does not support full LDAP Generalized > time syntax. In the unsupported cases, we should fall back > to string representation of the attribute. > > In particular, '0' is used to denote no value of LDAP generalized > time attribute. > > https://fedorahosted.org/freeipa/ticket/4350 NACK, this beats the purpose of decoding of the values, because it requires you to check the type of the value before using it. Instead, you should either fix the code that uses the nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value directly, or exclude the attributes from decoding to datetime by overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. Honza -- Jan Cholasta From jcholast at redhat.com Wed Jun 25 15:36:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Jun 2014 17:36:26 +0200 Subject: [Freeipa-devel] [PATCH] 676 rpcserver: fix local vs utc time comparison In-Reply-To: <53A984DC.3040609@redhat.com> References: <53A984DC.3040609@redhat.com> Message-ID: <53AAEC7A.9040907@redhat.com> Hi, On 24.6.2014 16:02, Petr Vobornik wrote: > login_password did not work properly in timezones other than +0h because > local time was compared with utc time. ACK. > > Bug introduced in: > https://fedorahosted.org/freeipa/ticket/4339 > > We should review other code for invalid usage of datetime.now() All other uses of datetime.now() predate LDAP datetime decoding, so I think we are fine. Honza -- Jan Cholasta From pviktori at redhat.com Wed Jun 25 15:46:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 17:46:26 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <53AADC71.8090509@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> <53A017A8.8080105@redhat.com> <53A145CD.7000500@redhat.com> <53AADC71.8090509@redhat.com> Message-ID: <53AAEED2.5030403@redhat.com> On 06/25/2014 04:28 PM, Tomas Babej wrote: > > On 06/18/2014 09:54 AM, Petr Viktorin wrote: >> On 06/17/2014 12:25 PM, Tomas Babej wrote: >>> >>> On 05/26/2014 06:20 PM, Petr Viktorin wrote: >>>> On 05/20/2014 06:15 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> the following set of patches fixes: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4274 >>>>> https://fedorahosted.org/freeipa/ticket/4263 >>>>> https://fedorahosted.org/freeipa/ticket/4324 >>>>> https://fedorahosted.org/freeipa/ticket/4340 >>>>> https://fedorahosted.org/freeipa/ticket/4341 >>>>> >>>>> and additional minor issues. >>>>> >>>>> The improvemed CI test coverage for the sudorule plugin is added as a >>>>> bonus. >> >> You've dropped most of the long commit messages and ticket URLs. Why? > > Sorry about that.. fixed! > >> >> >>>> 0187: OK >>>> 0188 - sudorule: Allow using hostmasks for setting allowed hosts >> >> If I run sudorule-add-host / sudorule-remove-host with a hostmask, but >> not host/hostgroup, I get prompted for host and hostgroup. I don't >> think that's the intended behavior. > > This problem is beyond this patchset. Observe that same thing happens > with ipa group-add-member --external. I was afraid it wouldn't bee that easy. > I'm not sure if there's a ticket for this though. There is now. https://fedorahosted.org/freeipa/ticket/4400 >> 0189: OK >> 0190: OK >> 0191: OK >> 0192: OK >> >>>> 0193 sudorule: Make sure all the relevant attributes are checked when >>>> setting category to ALL >> >>>> You're missing the `_` for the hostcategory error message. >>>> Did you think about using something like _("%s cannot be set to 'all' >>>> while there are %s")? >>>> >>> Fixed. Initially, I changed the message as you suggested, but then I >>> realized, that this might pose a problem for translations that do not >>> follow the word order in the sentence as it is defined in English >>> language. >> >> Right, sorry for the incorrect example. You can use named >> substitutions for that: >> _("can't %(action)s while %(state)s") % {'action': 'move', >> 'state': 'asleep'} The placeholder syntax is %(xyz)s, not %{xyz}. (Have you been using format() too much?) >> One more thing - the function is only called once, could you move it >> to the for loop? Well, I meant put the function's body in the for loop, getting rid of the function. But that's just a nitpick. >> 0194: OK >> 0195: OK >> 0196-0198: OK >> 0199-0201: OK >> >> 0225: >> Looks good. Could you also document the arguments & return value in >> *_external_post_callback docstrings? >> >> > > I did. The updated patchset attached. Thanks! -- Petr? From tbabej at redhat.com Wed Jun 25 16:23:36 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 18:23:36 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <53AAEED2.5030403@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> <53A017A8.8080105@redhat.com> <53A145CD.7000500@redhat.com> <53AADC71.8090509@redhat.com> <53AAEED2.5030403@redhat.com> Message-ID: <53AAF788.7040200@redhat.com> On 06/25/2014 05:46 PM, Petr Viktorin wrote: > On 06/25/2014 04:28 PM, Tomas Babej wrote: >> >> On 06/18/2014 09:54 AM, Petr Viktorin wrote: >>> On 06/17/2014 12:25 PM, Tomas Babej wrote: >>>> >>>> On 05/26/2014 06:20 PM, Petr Viktorin wrote: >>>>> On 05/20/2014 06:15 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> the following set of patches fixes: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4274 >>>>>> https://fedorahosted.org/freeipa/ticket/4263 >>>>>> https://fedorahosted.org/freeipa/ticket/4324 >>>>>> https://fedorahosted.org/freeipa/ticket/4340 >>>>>> https://fedorahosted.org/freeipa/ticket/4341 >>>>>> >>>>>> and additional minor issues. >>>>>> >>>>>> The improvemed CI test coverage for the sudorule plugin is added >>>>>> as a >>>>>> bonus. >>> >>> You've dropped most of the long commit messages and ticket URLs. Why? >> >> Sorry about that.. fixed! >> >>> >>> >>>>> 0187: OK >>>>> 0188 - sudorule: Allow using hostmasks for setting allowed hosts >>> >>> If I run sudorule-add-host / sudorule-remove-host with a hostmask, but >>> not host/hostgroup, I get prompted for host and hostgroup. I don't >>> think that's the intended behavior. >> >> This problem is beyond this patchset. Observe that same thing happens >> with ipa group-add-member --external. > > I was afraid it wouldn't bee that easy. > >> I'm not sure if there's a ticket for this though. > > There is now. https://fedorahosted.org/freeipa/ticket/4400 > >>> 0189: OK >>> 0190: OK >>> 0191: OK >>> 0192: OK >>> >>>>> 0193 sudorule: Make sure all the relevant attributes are checked when >>>>> setting category to ALL >>> >>>>> You're missing the `_` for the hostcategory error message. >>>>> Did you think about using something like _("%s cannot be set to 'all' >>>>> while there are %s")? >>>>> >>>> Fixed. Initially, I changed the message as you suggested, but then I >>>> realized, that this might pose a problem for translations that do not >>>> follow the word order in the sentence as it is defined in English >>>> language. >>> >>> Right, sorry for the incorrect example. You can use named >>> substitutions for that: >>> _("can't %(action)s while %(state)s") % {'action': 'move', >>> 'state': 'asleep'} > > The placeholder syntax is %(xyz)s, not %{xyz}. > (Have you been using format() too much?) That's some detective insight! Thanks for catching that. > >>> One more thing - the function is only called once, could you move it >>> to the for loop? > > Well, I meant put the function's body in the for loop, getting rid of > the function. But that's just a nitpick. > No, you're right, the function's redundant after all the refactoring that happened. Fixed. >>> 0194: OK >>> 0195: OK >>> 0196-0198: OK >>> 0199-0201: OK >>> >>> 0225: >>> Looks good. Could you also document the arguments & return value in >>> *_external_post_callback docstrings? >>> >>> >> >> I did. The updated patchset attached. > > Thanks! > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0225-3-sudorule-Refactor-add-and-remove-external_post_callb.patch Type: text/x-patch Size: 22803 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0187-5-sudorule-PEP8-fixes-in-sudorule.py.patch Type: text/x-patch Size: 18390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0188-5-sudorule-Allow-using-hostmasks-for-setting-allowed-h.patch Type: text/x-patch Size: 11271 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0189-5-sudorule-Allow-using-external-groups-as-groups-of-ru.patch Type: text/x-patch Size: 14011 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0190-5-sudorule-Make-sure-sudoRunAsGroup-is-dereferencing-t.patch Type: text/x-patch Size: 2864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0191-5-sudorule-Include-externalhost-and-ipasudorunasextgro.patch Type: text/x-patch Size: 1215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0192-5-sudorule-Allow-adding-deny-commands-when-command-cat.patch Type: text/x-patch Size: 1137 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0193-5-sudorule-Make-sure-all-the-relevant-attributes-are-c.patch Type: text/x-patch Size: 4037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0194-5-sudorule-Fix-the-order-of-the-parameters-to-have-les.patch Type: text/x-patch Size: 2984 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0195-5-sudorule-Enforce-category-ALL-checks-on-dirsrv-level.patch Type: text/x-patch Size: 4943 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0196-5-ipatests-test_sudo-Add-tests-for-allowing-hosts-via-.patch Type: text/x-patch Size: 2625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0197-5-ipatests-test_sudo-Add-coverage-for-external-entries.patch Type: text/x-patch Size: 6890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0198-5-ipatests-test_sudo-Add-coverage-for-category-ALL-val.patch Type: text/x-patch Size: 15765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0199-5-ipatests-test_sudo-Fix-assertions-not-assuming-runas.patch Type: text/x-patch Size: 4708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0200-5-ipatests-test_sudo-Do-not-expect-enumeration-of-runa.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0201-5-ipatests-test_sudo-Expect-root-listed-out-if-no-RunA.patch Type: text/x-patch Size: 1544 bytes Desc: not available URL: From pviktori at redhat.com Wed Jun 25 16:25:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 18:25:48 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53AAEAC1.3080106@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> Message-ID: <53AAF80C.7090106@redhat.com> On 06/25/2014 05:29 PM, Jan Cholasta wrote: > Hi, > > On 25.6.2014 17:17, Tomas Babej wrote: >> Hi, >> >> Our datetime conversion does not support full LDAP Generalized >> time syntax. In the unsupported cases, we should fall back >> to string representation of the attribute. >> >> In particular, '0' is used to denote no value of LDAP generalized >> time attribute. >> >> https://fedorahosted.org/freeipa/ticket/4350 > > NACK, this beats the purpose of decoding of the values, because it > requires you to check the type of the value before using it. > > Instead, you should either fix the code that uses the > nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value > directly, or exclude the attributes from decoding to datetime by > overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. > > Honza > I agree that just returning a string when conversion fails is the wrong thing to do. I think that if LDAP generalized can contain the empty/invalid value, we should convert the '0' to what Python uses for that -- None. -- Petr? From pviktori at redhat.com Wed Jun 25 16:31:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 18:31:41 +0200 Subject: [Freeipa-devel] [PATCH 0076] Fix incompatible DNS permission In-Reply-To: <1403708629.2323.7.camel@unused-4-145.brq.redhat.com> References: <1403270888.2336.19.camel@unused-4-145.brq.redhat.com> <53AAD482.4060502@redhat.com> <1403708629.2323.7.camel@unused-4-145.brq.redhat.com> Message-ID: <53AAF96D.8020106@redhat.com> On 06/25/2014 05:03 PM, Martin Basti wrote: > On Wed, 2014-06-25 at 15:54 +0200, Petr Viktorin wrote: >> On 06/20/2014 03:28 PM, Martin Basti wrote: >>> Patch attached. >>> >>> Ticket:https://fedorahosted.org/freeipa/ticket/4383 >> >> This works, just two comments: >> >> To check if an entry exists, instead of calling >> api.Command['permission_show'](permission_name_rel) >> you should call the more light-weight >> api.Object[permission].get_dn_if_exists(permission_name_rel) >> >> And for translated messages, use: >> _('message about %(topic)s") % {...} >> rather than: >> _('message about %(topic)s" % {...}) >> In other words, _() must be called on a literal string. Otherwise it >> couldn't be looked up in the translation database (or even picked up by >> gettext). >> > > Thank you for review. > Updated patch attached. > Thanks! ACK, pushed to master: 816007bdd911065b42170a06aea3cf750a5198fe -- Petr? From mbasti at redhat.com Wed Jun 25 16:47:09 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 18:47:09 +0200 Subject: [Freeipa-devel] [PATCH 0077] Fix ACI in DNS (was Add dnssecinlinesigning attribute to ACI) In-Reply-To: <53AAA0C7.80501@redhat.com> References: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> <53AAA0C7.80501@redhat.com> Message-ID: <1403714829.2323.12.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-25 at 12:13 +0200, Petr Viktorin wrote: > On 06/20/2014 03:32 PM, Martin Basti wrote: > > Required patches: mbasti-0060, mbasti-0073 > > > > Patch attached. > > > > Hi, > > For the raw ACI in dns.ldif, there are some more hoops to jump through. > > Remove the ACI from /install/share/dns.ldif entirely (except for schema, > we're slowly replacing the .ldif content by .update files). > > In install/updates/40-dns.update, you'll notice the "Update DNS entries > in a zone" ACI is already being added. You'll need to replace it, using > a line like: > replace:aci:'::' > This will remove the old value that IPA 3.x users still have. > > I see you already changed the ACI in 7cdc417, in dns.ldif only. Be > sureto use the original value for . > > As we discuss personally, ACI requires more changes than add idnssecinlinesingning only. Updated patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0077-2-Fix-ACI-in-DNS.patch Type: text/x-patch Size: 11798 bytes Desc: not available URL: From mbasti at redhat.com Wed Jun 25 16:49:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 25 Jun 2014 18:49:01 +0200 Subject: [Freeipa-devel] [PATCH 0077] Fix ACI in DNS (was Add dnssecinlinesigning attribute to ACI) In-Reply-To: <1403714829.2323.12.camel@unused-4-145.brq.redhat.com> References: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> <53AAA0C7.80501@redhat.com> <1403714829.2323.12.camel@unused-4-145.brq.redhat.com> Message-ID: <1403714941.2323.13.camel@unused-4-145.brq.redhat.com> On Wed, 2014-06-25 at 18:47 +0200, Martin Basti wrote: > On Wed, 2014-06-25 at 12:13 +0200, Petr Viktorin wrote: > > On 06/20/2014 03:32 PM, Martin Basti wrote: > > > Required patches: mbasti-0060, mbasti-0073 > > > > > > Patch attached. > > > > > > > Hi, > > > > For the raw ACI in dns.ldif, there are some more hoops to jump through. > > > > Remove the ACI from /install/share/dns.ldif entirely (except for schema, > > we're slowly replacing the .ldif content by .update files). > > > > In install/updates/40-dns.update, you'll notice the "Update DNS entries > > in a zone" ACI is already being added. You'll need to replace it, using > > a line like: > > replace:aci:'::' > > This will remove the old value that IPA 3.x users still have. > > > > I see you already changed the ACI in 7cdc417, in dns.ldif only. Be > > sureto use the original value for . > > > > > As we discuss personally, ACI requires more changes than add > idnssecinlinesingning only. > > Updated patch attached. > Patch freeipa-mbasti-0078-DNSSEC-add-TLSA-record-type.patch is required. -- Martin^2 Basti From pvoborni at redhat.com Wed Jun 25 16:58:52 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Jun 2014 18:58:52 +0200 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements Message-ID: <53AAFFCC.3050308@redhat.com> Patch 618 fixes a bug. Patches 680 and 681 were implemented along with it. They address pspacek's usability rant :). [PATCH] 680 webui: show notification instead of modal dialog on validation error [PATCH] 681 webui: fix required error notification in multivalued widget [PATCH] 682 webui: focus invalid widget on validation error -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0682-webui-focus-invalid-widget-on-validation-error.patch Type: text/x-patch Size: 3186 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0681-webui-fix-required-error-notification-in-multivalued.patch Type: text/x-patch Size: 1350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0680-webui-show-notification-instead-of-modal-dialog-on-v.patch Type: text/x-patch Size: 1086 bytes Desc: not available URL: From tbabej at redhat.com Wed Jun 25 17:16:56 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 19:16:56 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AAE3EF.5000005@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> <53AAD91A.2000603@redhat.com> <53AAE3EF.5000005@redhat.com> Message-ID: <53AB0408.40304@redhat.com> On 06/25/2014 04:59 PM, Tomas Babej wrote: > > On 06/25/2014 04:13 PM, Tomas Babej wrote: >> >> On 06/25/2014 04:01 PM, Tomas Babej wrote: >>> >>> On 06/25/2014 10:48 AM, Petr Viktorin wrote: >>>> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>>>> >>>>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>>>> which moves >>>>>>>> the paths from installers to the paths module. >>>>>>> In patch 226, there's another "certificated" typo in >>>>>>> remove_ca_cert_from_systemwide_ca_store >>>>>>> >>>>>>>> I greped the repository, and I do not see many paths lurking >>>>>>>> around any >>>>>>>> more, there are only some in the error messages (as these can't be >>>>>>>> reliably replaced automatically, and will need some manual love). >>>>>>>> >>>>>>>> If you see any forgotten paths, which should be added to the >>>>>>>> module, let >>>>>>>> me know. >>>> >>>> Well, since you asked... >>>> >>>> install/tools/ipa-upgradeconfig:236: >>>> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >>>> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >>>> >>>> ipaserver/install/dsinstance.py:209:InstallLdifFile= >>>> /var/lib/dirsrv/boot.ldif >>>> ipaserver/install/dsinstance.py:210:inst_dir= >>>> /var/lib/dirsrv/scripts-$SERVERID >>>> >>>> ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', >>>> >>>> ipatests/test_integration/tasks.py:451: host.run_command("find >>>> /var/lib/sss/db -name '*.ldb' | " >>>> >>>> install/tools/ipa-replica-conncheck:403: >>>> "/usr/sbin/ipa-replica-conncheck " + >>>> install/tools/ipa-replica-conncheck:414: >>>> print_info("/usr/sbin/ipa-replica-conncheck " + " >>>> ".join(remote_check_opts)) >>>> >>>> ipapython/ipautil.py:296: env["PATH"] = >>>> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >>>> >>>> ipaserver/install/cainstance.py:88:ConfigFile = >>>> /usr/share/pki/ca/conf/database.ldif >>>> >>>> ipaserver/install/bindinstance.py:829: >>>> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >>>> >>> >>> /me will think twice about teasing nex time. >>> >>> This are paths requiring manual changes in one way or the other and >>> as such cannot be handled by my tool. Let's not stall the patcheset >>> on this. We can fix these (and surely there are other) as we go along. >>> >>>> >>>> I guess it'll be a while before we catch them all, but now it's at >>>> least clear where these paths should be, so anyone porting to >>>> another distro can send patches (or tickets) upstream. >>>> >>>>>>> I see another duplicate: >>>>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>>>> "/var/lib/sss/pubconf/krb5.include.d/" >>>> >>>> Could you just pick one instead? Would ipa_backup.py break if it >>>> had a trailing slash here? >>>> >>> >>> Yes. I verified it produces the same result with or without trailing >>> slash, fixed. >>> >>> >>>> In ipa-client-install, if you set: >>>> NSSWITCH_CONF = paths.NSSWITCH_CONF >>>> then you should only use one of those later. (Preferably paths.*, >>>> to get rid of the redundant constants.) >>>> Perhaps this is for another patch that would clean up all the cases >>>> where these trivial module variables are used. >>>> >>> >>> I agree. Fixed this occurence. >>> >>>>>> Fixed all mentioned issues. I also attached a patch 230, which >>>>>> removes >>>>>> the base Authconfig class. >>>> >>>> >>>>> Attaching one additional patch, which removes unnecessary build >>>>> warnings. >>>>> >>>> >>>> 226, 230, 231 look good >>>> >>> >>> Attaching whole updated patchset. >> >> Attaching one more patch which should fix broken CI tests. >> >>> >>> -- >>> Tomas Babej >>> Associate Software Engineer | Red Hat | Identity Management >>> RHCE | Brno Site | IRC: tbabej | freeipa.org >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> -- >> Tomas Babej >> Associate Software Engineer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Self-NACK - It seems I omitted one occurence of NSSWITCH_CONF in > ipa-client-install, fixed now. > > Attaching the whole patchset for your convenience. > -- > Tomas Babej > Associate Software Engineer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org Attaching a correct patchset this time. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-5-ipaplatform-Fix-build-warnings.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0235-ipaplatform-Fix-misspelled-path-constant.patch Type: text/x-patch Size: 1878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0231-2-ipaplatform-Fix-build-warnings.patch Type: text/x-patch Size: 1175 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0230-2-ipaplatform-Drop-the-base-authconfig-class.patch Type: text/x-patch Size: 6053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0226-4-ipaplatform-Document-the-platform-tasks-API.patch Type: text/x-patch Size: 4755 bytes Desc: not available URL: From edewata at redhat.com Wed Jun 25 17:41:06 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Jun 2014 12:41:06 -0500 Subject: [Freeipa-devel] [PATCH] 659-666 Support of password reset with OTP In-Reply-To: <53A450AD.9020908@redhat.com> References: <5398577C.8090605@redhat.com> <53A450AD.9020908@redhat.com> Message-ID: <53AB09B2.3030406@redhat.com> On 6/20/2014 10:18 AM, Petr Vobornik wrote: > On 11.6.2014 15:19, Petr Vobornik wrote: >> Patch set contains both API/server and Web UI parts. >> >> [PATCH] 659 ldap2: add otp support to modify_password >> [PATCH] 660 rpcserver: add otp support to change_password handler >> [PATCH] 661 ipa-passwd: add OTP support >> [PATCH] 662 webui: support password change with OTP in login screen >> [PATCH] 663 webui: placeholder attribute support in textbox and textarea >> [PATCH] 664 webui: add placeholders to login screen >> [PATCH] 665 webui: rebase user password dialog on password dialog and >> add otp support >> [PATCH] 666 webui: support otp in reset_password.html >> >> https://fedorahosted.org/freeipa/ticket/4262 > > attaching rebased patches (mainly because of VERSION conflict) ACK. Possible improvements (some of which are already discussed on IRC): 1. The "clock interval" field in the Add OTP Token dialog could be disabled for HOTP. 2. The "clock interval" and "counter" fields (and probably some other fields too) in the OTP Token details page could be hidden depending on the token type. 3. The Add OTP Token dialog could provide more descriptive token types: time-based or counter-based token instead of just TOTP or HOTP. 4. The OTP Token details page could show the token type (I suppose the model may not be descriptive enough). 5. It would be nice to have a link/button to add OTP Token from the user details page with the owner already set to the user. 6. The "clock interval" should have a unit of measurements (i.e. seconds). 7. When logging in with an expired password, the user will be asked to reset a password and enter an OTP. Although OTP means one-time password, some users could be confusing it with the OTP he/she just entered in the previous page. It would be nicer to say "New OTP" or add an explanation "Wait for a new OTP" to make sure the user enters a new OTP. 8. In the "User authentication types" field it might be better to say "password + OTP" instead of just "otp". The checkbox value can remain "otp". 9. The "User authentication types" is a bit confusing because if none are selected it doesn't mean that no authentication is allowed, but it means it's unset and it will use the global setting. The UI probably should provide a separate radio button to select "Use global setting" or show the effective setting next to it. 10. The "Default user authentication types" in the global setting is a bit confusing because by default nothing is selected but the actual default is supposedly not empty. 11. Ideally the password reset page/dialog should indicate whether the old password and the OTP are required based on the actual authentication type available to the user. 12. Ideally there should be a way to display the QR code of an existing OTP token. 13. The UI could also provide a link to download the OTP app or a list of supported apps. -- Endi S. Dewata From pviktori at redhat.com Wed Jun 25 18:22:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 20:22:16 +0200 Subject: [Freeipa-devel] [PATCHES 187-201] Improvements and coverage for sudorule plugin In-Reply-To: <53AAF788.7040200@redhat.com> References: <537B7FA9.9000909@redhat.com> <538369E1.5020300@redhat.com> <53A017A8.8080105@redhat.com> <53A145CD.7000500@redhat.com> <53AADC71.8090509@redhat.com> <53AAEED2.5030403@redhat.com> <53AAF788.7040200@redhat.com> Message-ID: <53AB1358.4050204@redhat.com> On 06/25/2014 06:23 PM, Tomas Babej wrote: > > On 06/25/2014 05:46 PM, Petr Viktorin wrote: >> On 06/25/2014 04:28 PM, Tomas Babej wrote: >>> >>> On 06/18/2014 09:54 AM, Petr Viktorin wrote: >>>> On 06/17/2014 12:25 PM, Tomas Babej wrote: >>>>> >>>>> On 05/26/2014 06:20 PM, Petr Viktorin wrote: >>>>>> On 05/20/2014 06:15 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> the following set of patches fixes: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4274 >>>>>>> https://fedorahosted.org/freeipa/ticket/4263 >>>>>>> https://fedorahosted.org/freeipa/ticket/4324 >>>>>>> https://fedorahosted.org/freeipa/ticket/4340 >>>>>>> https://fedorahosted.org/freeipa/ticket/4341 >>>>>>> >>>>>>> and additional minor issues. >>>>>>> >>>>>>> The improvemed CI test coverage for the sudorule plugin is added >>>>>>> as a >>>>>>> bonus. >>>> >>>> You've dropped most of the long commit messages and ticket URLs. Why? >>> >>> Sorry about that.. fixed! >>> >>>> >>>> >>>>>> 0187: OK >>>>>> 0188 - sudorule: Allow using hostmasks for setting allowed hosts >>>> >>>> If I run sudorule-add-host / sudorule-remove-host with a hostmask, but >>>> not host/hostgroup, I get prompted for host and hostgroup. I don't >>>> think that's the intended behavior. >>> >>> This problem is beyond this patchset. Observe that same thing happens >>> with ipa group-add-member --external. >> >> I was afraid it wouldn't bee that easy. >> >>> I'm not sure if there's a ticket for this though. >> >> There is now. https://fedorahosted.org/freeipa/ticket/4400 >> >>>> 0189: OK >>>> 0190: OK >>>> 0191: OK >>>> 0192: OK >>>> >>>>>> 0193 sudorule: Make sure all the relevant attributes are checked when >>>>>> setting category to ALL >>>> >>>>>> You're missing the `_` for the hostcategory error message. >>>>>> Did you think about using something like _("%s cannot be set to 'all' >>>>>> while there are %s")? >>>>>> >>>>> Fixed. Initially, I changed the message as you suggested, but then I >>>>> realized, that this might pose a problem for translations that do not >>>>> follow the word order in the sentence as it is defined in English >>>>> language. >>>> >>>> Right, sorry for the incorrect example. You can use named >>>> substitutions for that: >>>> _("can't %(action)s while %(state)s") % {'action': 'move', >>>> 'state': 'asleep'} >> >> The placeholder syntax is %(xyz)s, not %{xyz}. >> (Have you been using format() too much?) > That's some detective insight! Thanks for catching that. > > >> >>>> One more thing - the function is only called once, could you move it >>>> to the for loop? >> >> Well, I meant put the function's body in the for loop, getting rid of >> the function. But that's just a nitpick. >> > No, you're right, the function's redundant after all the refactoring > that happened. Fixed. > >>>> 0194: OK >>>> 0195: OK >>>> 0196-0198: OK >>>> 0199-0201: OK >>>> >>>> 0225: >>>> Looks good. Could you also document the arguments & return value in >>>> *_external_post_callback docstrings? >>>> >>>> >>> >>> I did. The updated patchset attached. >> >> Thanks! >> > ACK, pushed to master: af4518b72882f88a01de0e5c23d423898ba894b4 -- Petr? From pviktori at redhat.com Wed Jun 25 19:35:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Jun 2014 21:35:10 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AB0408.40304@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> <53AAD91A.2000603@redhat.com> <53AAE3EF.5000005@redhat.com> <53AB0408.40304@redhat.com> Message-ID: <53AB246E.9050604@redhat.com> On 06/25/2014 07:16 PM, Tomas Babej wrote: > > On 06/25/2014 04:59 PM, Tomas Babej wrote: >> >> On 06/25/2014 04:13 PM, Tomas Babej wrote: >>> >>> On 06/25/2014 04:01 PM, Tomas Babej wrote: >>>> >>>> On 06/25/2014 10:48 AM, Petr Viktorin wrote: >>>>> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>>>>> >>>>>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>>>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>>>>> which moves >>>>>>>>> the paths from installers to the paths module. >>>>>>>> In patch 226, there's another "certificated" typo in >>>>>>>> remove_ca_cert_from_systemwide_ca_store >>>>>>>> >>>>>>>>> I greped the repository, and I do not see many paths lurking >>>>>>>>> around any >>>>>>>>> more, there are only some in the error messages (as these can't be >>>>>>>>> reliably replaced automatically, and will need some manual love). >>>>>>>>> >>>>>>>>> If you see any forgotten paths, which should be added to the >>>>>>>>> module, let >>>>>>>>> me know. >>>>> >>>>> Well, since you asked... >>>>> >>>>> install/tools/ipa-upgradeconfig:236: >>>>> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >>>>> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >>>>> >>>>> ipaserver/install/dsinstance.py:209:InstallLdifFile= >>>>> /var/lib/dirsrv/boot.ldif >>>>> ipaserver/install/dsinstance.py:210:inst_dir= >>>>> /var/lib/dirsrv/scripts-$SERVERID >>>>> >>>>> ipaserver/install/ipa_backup.py:464: '--exclude=/var/lib/ipa/backup', >>>>> >>>>> ipatests/test_integration/tasks.py:451: host.run_command("find >>>>> /var/lib/sss/db -name '*.ldb' | " >>>>> >>>>> install/tools/ipa-replica-conncheck:403: >>>>> "/usr/sbin/ipa-replica-conncheck " + >>>>> install/tools/ipa-replica-conncheck:414: >>>>> print_info("/usr/sbin/ipa-replica-conncheck " + " >>>>> ".join(remote_check_opts)) >>>>> >>>>> ipapython/ipautil.py:296: env["PATH"] = >>>>> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >>>>> >>>>> ipaserver/install/cainstance.py:88:ConfigFile = >>>>> /usr/share/pki/ca/conf/database.ldif >>>>> >>>>> ipaserver/install/bindinstance.py:829: >>>>> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >>>>> >>>> >>>> /me will think twice about teasing nex time. >>>> >>>> This are paths requiring manual changes in one way or the other and >>>> as such cannot be handled by my tool. Let's not stall the patcheset >>>> on this. We can fix these (and surely there are other) as we go along. OK, not a reason to hold the patch back. But, the fact that the tool can't handle them doesn't make them less important. Let's keep the ticket open, or open a new one. >>>>> I guess it'll be a while before we catch them all, but now it's at >>>>> least clear where these paths should be, so anyone porting to >>>>> another distro can send patches (or tickets) upstream. >>>>> >>>>>>>> I see another duplicate: >>>>>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>>>>> "/var/lib/sss/pubconf/krb5.include.d/" >>>>> >>>>> Could you just pick one instead? Would ipa_backup.py break if it >>>>> had a trailing slash here? >>>>> >>>> >>>> Yes. I verified it produces the same result with or without trailing >>>> slash, fixed. >>>> >>>> >>>>> In ipa-client-install, if you set: >>>>> NSSWITCH_CONF = paths.NSSWITCH_CONF >>>>> then you should only use one of those later. (Preferably paths.*, >>>>> to get rid of the redundant constants.) >>>>> Perhaps this is for another patch that would clean up all the cases >>>>> where these trivial module variables are used. >>>>> >>>> >>>> I agree. Fixed this occurence. I've opened an easyfix ticket for the rest: https://fedorahosted.org/freeipa/ticket/4399 >>>>>>> Fixed all mentioned issues. I also attached a patch 230, which >>>>>>> removes >>>>>>> the base Authconfig class. >>>>> >>>>> >>>>>> Attaching one additional patch, which removes unnecessary build >>>>>> warnings. >>>>>> >>>>> >>>>> 226, 230, 231 look good >>>>> >>>> >>>> Attaching whole updated patchset. >>> >>> Attaching one more patch which should fix broken CI tests. >>> >> >> Self-NACK - It seems I omitted one occurence of NSSWITCH_CONF in >> ipa-client-install, fixed now. >> >> Attaching the whole patchset for your convenience. >> -- > Attaching a correct patchset this time. I hate to break it to you, but... you sent the wrong patch 228 :( They're pretty independent, and there are fixes for failing tests, so I went ahead with the other ones. 226, 230, 231, 235: ACK, pushed to master: c8511d3b3baa389069156bf9991a9f4c7d64cf4a -- Petr? From tbabej at redhat.com Wed Jun 25 19:48:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 25 Jun 2014 21:48:01 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AB246E.9050604@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> <53AAD91A.2000603@redhat.com> <53AAE3EF.5000005@redhat.com> <53AB0408.40304@redhat.com> <53AB246E.9050604@redhat.com> Message-ID: <53AB2771.5020304@redhat.com> On 06/25/2014 09:35 PM, Petr Viktorin wrote: > On 06/25/2014 07:16 PM, Tomas Babej wrote: >> >> On 06/25/2014 04:59 PM, Tomas Babej wrote: >>> >>> On 06/25/2014 04:13 PM, Tomas Babej wrote: >>>> >>>> On 06/25/2014 04:01 PM, Tomas Babej wrote: >>>>> >>>>> On 06/25/2014 10:48 AM, Petr Viktorin wrote: >>>>>> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>>>>>> >>>>>>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>>>>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>>>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>>>>>> which moves >>>>>>>>>> the paths from installers to the paths module. >>>>>>>>> In patch 226, there's another "certificated" typo in >>>>>>>>> remove_ca_cert_from_systemwide_ca_store >>>>>>>>> >>>>>>>>>> I greped the repository, and I do not see many paths lurking >>>>>>>>>> around any >>>>>>>>>> more, there are only some in the error messages (as these >>>>>>>>>> can't be >>>>>>>>>> reliably replaced automatically, and will need some manual >>>>>>>>>> love). >>>>>>>>>> >>>>>>>>>> If you see any forgotten paths, which should be added to the >>>>>>>>>> module, let >>>>>>>>>> me know. >>>>>> >>>>>> Well, since you asked... >>>>>> >>>>>> install/tools/ipa-upgradeconfig:236: >>>>>> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >>>>>> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >>>>>> >>>>>> ipaserver/install/dsinstance.py:209:InstallLdifFile= >>>>>> /var/lib/dirsrv/boot.ldif >>>>>> ipaserver/install/dsinstance.py:210:inst_dir= >>>>>> /var/lib/dirsrv/scripts-$SERVERID >>>>>> >>>>>> ipaserver/install/ipa_backup.py:464: >>>>>> '--exclude=/var/lib/ipa/backup', >>>>>> >>>>>> ipatests/test_integration/tasks.py:451: host.run_command("find >>>>>> /var/lib/sss/db -name '*.ldb' | " >>>>>> >>>>>> install/tools/ipa-replica-conncheck:403: >>>>>> "/usr/sbin/ipa-replica-conncheck " + >>>>>> install/tools/ipa-replica-conncheck:414: >>>>>> print_info("/usr/sbin/ipa-replica-conncheck " + " >>>>>> ".join(remote_check_opts)) >>>>>> >>>>>> ipapython/ipautil.py:296: env["PATH"] = >>>>>> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >>>>>> >>>>>> ipaserver/install/cainstance.py:88:ConfigFile = >>>>>> /usr/share/pki/ca/conf/database.ldif >>>>>> >>>>>> ipaserver/install/bindinstance.py:829: >>>>>> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >>>>>> >>>>> >>>>> /me will think twice about teasing nex time. >>>>> >>>>> This are paths requiring manual changes in one way or the other and >>>>> as such cannot be handled by my tool. Let's not stall the patcheset >>>>> on this. We can fix these (and surely there are other) as we go >>>>> along. > > OK, not a reason to hold the patch back. > But, the fact that the tool can't handle them doesn't make them less > important. Let's keep the ticket open, or open a new one. > >>>>>> I guess it'll be a while before we catch them all, but now it's at >>>>>> least clear where these paths should be, so anyone porting to >>>>>> another distro can send patches (or tickets) upstream. >>>>>> >>>>>>>>> I see another duplicate: >>>>>>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>>>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>>>>>> "/var/lib/sss/pubconf/krb5.include.d/" >>>>>> >>>>>> Could you just pick one instead? Would ipa_backup.py break if it >>>>>> had a trailing slash here? >>>>>> >>>>> >>>>> Yes. I verified it produces the same result with or without trailing >>>>> slash, fixed. >>>>> >>>>> >>>>>> In ipa-client-install, if you set: >>>>>> NSSWITCH_CONF = paths.NSSWITCH_CONF >>>>>> then you should only use one of those later. (Preferably paths.*, >>>>>> to get rid of the redundant constants.) >>>>>> Perhaps this is for another patch that would clean up all the cases >>>>>> where these trivial module variables are used. >>>>>> >>>>> >>>>> I agree. Fixed this occurence. > > I've opened an easyfix ticket for the rest: > https://fedorahosted.org/freeipa/ticket/4399 > >>>>>>>> Fixed all mentioned issues. I also attached a patch 230, which >>>>>>>> removes >>>>>>>> the base Authconfig class. >>>>>> >>>>>> >>>>>>> Attaching one additional patch, which removes unnecessary build >>>>>>> warnings. >>>>>>> >>>>>> >>>>>> 226, 230, 231 look good >>>>>> >>>>> >>>>> Attaching whole updated patchset. >>>> >>>> Attaching one more patch which should fix broken CI tests. >>>> >>> >>> Self-NACK - It seems I omitted one occurence of NSSWITCH_CONF in >>> ipa-client-install, fixed now. >>> >>> Attaching the whole patchset for your convenience. >>> -- >> Attaching a correct patchset this time. > > I hate to break it to you, but... > you sent the wrong patch 228 :( > No way! That's a official fail combo on my part. Here's the correct patch. I checked and it applies cleanly on master. > > They're pretty independent, and there are fixes for failing tests, so > I went ahead with the other ones. > > 226, 230, 231, 235: ACK, pushed to master: > c8511d3b3baa389069156bf9991a9f4c7d64cf4a > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0228-6-ipaplatform-Move-paths-from-installers-to-paths-modu.patch Type: text/x-patch Size: 62606 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 25 20:31:33 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Jun 2014 16:31:33 -0400 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403704392.3523.13.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <1403557986.3263.7.camel@ipa.example.com> <20140625103511.GF7233@redhat.com> <1403704392.3523.13.camel@ipa.example.com> Message-ID: <1403728293.3523.19.camel@ipa.example.com> On Wed, 2014-06-25 at 09:53 -0400, Nathaniel McCallum wrote: > On Wed, 2014-06-25 at 13:35 +0300, Alexander Bokovoy wrote: > > On Mon, 23 Jun 2014, Nathaniel McCallum wrote: > > >On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: > > >> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: > > >> >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: > > >> >> This command behaves almost exactly like otptoken-add except: > > >> >> 1. The new token data is written directly to a YubiKey > > >> >> 2. The vendor/model/serial fields are populated from the YubiKey > > >> >> > > >> >> === NOTE === > > >> >> 1. This patch depends on the new Fedora package: python-yubico. If you > > >> >> would like to help with the package review, please assign yourself here: > > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 > > >> > > > >> >New version of the patch. This one works (yay!). > > >> > > > >> >1. Because of the dependency on python-yubico, is this feature something > > >> >we want in core FreeIPA? As a subpackage? Separate project altogether? > > >> >The only dependency for python-yubico is pyusb. > > >> I'd prefer to have it integrated but have a separate dummy subpackage > > >> that pulls in all required dependencies, like, freeipa-tools-yubico. Instead > > >> of failing when 'ipa otptoken-add-yubikey' is called, please wrap the > > >> python-yubico import into a code that allows reporting a message back to > > >> the user advising to install the package. > > >> > > >> Who is a supposed user for this command? IPA command line interface isn't > > >> usually available on enrolled machines even though underlying Python > > >> modules are all there. Are we talking about admins or just users? > > > > > >As discussed on IRC, we are currently hard-coding lots of optional > > >dependencies. And breaking this apart into subpackages can be solved at > > >a later point. YubiKey is also a unique case: we don't expect to be > > >adding many more plugins like this. > > > > > >For these reasons, I have kept this as a hard dependency. To ease this > > >transition, I have added python-yubico to F20 and EL6. You can help with > > >the update review here: > > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 > > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 > > > > > >> >3. This code currently emits a warning from the call to otptoken-add: > > >> >WARNING: API Version number was not sent, forward compatibility not > > >> >guaranteed. Assuming server's API version, 2.89 > > >> > > > >> >How do I fix this? > > >> Do not filter 'version' field in options in execute(). > > > > > >I opted to not filter out version rather than hard-code it (pviktori's > > >suggestion). This is based on the fact that otptoken-add-yubikey is > > >tightly integrated with otptoken-add (even using some of the class > > >attributes from otptoken). > > > > > >> >4. I am not sure why I have to delete the summary and value keys from > > >> >the return dictionary. It would be nice to display this summary message > > >> >just like otptoken-add. > > > > > >I still need help on this. > > > > > >> >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These > > >> >aren't user settable, but we need to pass them from the yubikey > > >> >(client-side) to the server. > > > > > >This is no longer needed since I am doing everything in forward(). > > >However, listing these three as output params causes them to appear > > >before the token's ID. I don't think this is the right way to output > > >these. But this seems to me a framework issue. > > > > > >> >6. I'm not sure my use of assert or ValueError are correct. What should > > >> >I do here? > > > > > >Still need help here. > > Fixed this part. > > > > > > > >> >7. Considering that this is just a specialized invocation of > > >> >otptoken-add, can't we do this all on the client-side? This is why I had > > >> >originally used frontend.Local rather than frontend.Command. > > >> You don't need to implement execute then, only forward, where you'll > > >> forward your call to the server under otptoken_add name. > > >> > > >> Typically in #forward we call super's forward but that is because we > > >> in Command.forward() we simply forward the command to the remote backend, > > >> using the self.name. In your case we shouldn't really have a separate > > >> command on the server under the same name, so you'll need to avoid > > >> calling > > >> > > >> So, it should look like this: > > >> > > >> def forward(self, *args, **kw): > > >> perform yubikey initialization > > >> filter out kw and args, if needed > > >> return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) > > >> > > >> See service_show implementation for an example. > > > > > >Fixed. > > I'm attaching few fixups to the patch that make it proper reporting for > > non-Yubikey case and also properly update VERSION. > > > > Provisional ACK. > > Merged. This patch includes everything above and fixes the missing ./makeapi run. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0058.4-Add-the-otptoken-add-yubikey-command.patch Type: text/x-patch Size: 8429 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 25 20:32:11 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Jun 2014 16:32:11 -0400 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support In-Reply-To: <20140625102139.GE7233@redhat.com> References: <1401764823.4161.4.camel@ipa.example.com> <1403641921.3523.2.camel@ipa.example.com> <20140625102139.GE7233@redhat.com> Message-ID: <1403728331.3523.20.camel@ipa.example.com> On Wed, 2014-06-25 at 13:21 +0300, Alexander Bokovoy wrote: > On Tue, 24 Jun 2014, Nathaniel McCallum wrote: > >On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: > >> This HTTP call takes the following parameters: > >> * user > >> * password > >> * first_code > >> * second_code > >> * token (optional) > >> > >> Using this information, the server will perform token synchronization. > >> If the token is not specified, all tokens will be searched for > >> synchronization. > >> Otherwise, only the token specified will be searched. > >> > >> This patch depends on my patch #0054. > > > >Attached is a new revision. This version should force an update > >to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. > ACK with condition that you apply attached fixups. > > Since token that is passed by 'ipa otptoken-sync' command is not a full > DN, we need to support both cases, when DN and just a name is passed. > Attached patch fixes this. Applied. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0055.2-Add-session-token_sync-POST-support.patch Type: text/x-patch Size: 10103 bytes Desc: not available URL: From npmccallum at redhat.com Wed Jun 25 20:33:38 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Jun 2014 16:33:38 -0400 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140625101837.GD7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <1403643460.3523.5.camel@ipa.example.com> <20140625101837.GD7233@redhat.com> Message-ID: <1403728418.3523.21.camel@ipa.example.com> On Wed, 2014-06-25 at 13:18 +0300, Alexander Bokovoy wrote: > On Tue, 24 Jun 2014, Nathaniel McCallum wrote: > >On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote: > >> On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: > >> > On 3.6.2014 05:08, Nathaniel McCallum wrote: > >> > > This command calls the token sync HTTP POST call in the server providing > >> > > the CLI interface to synchronization. > >> > > > >> > > https://fedorahosted.org/freeipa/ticket/4260 > >> > > > >> > > This patch depends on my patch #0055. > >> > > > >> > > >> > Build fails on validation. You forgot to update API.txt and also the > >> > command misses __doc__. > >> > > >> > (not a proper review) > >> > >> Thanks, fixed. > > > >Attached is a new revision which is rebased on master. > > > >In addition it: > > > >1. Moves user to a parameter and moves token to an argument. Doing it > >this way both mirrors the existing otptoken APIs and sets us up for > >future Kerberos based syncing where the username/password will be > >optional. > > > >2. Converts the token ID to a DN. > ACK. > > Please do not commit this patch yet, we are not done with its > dependencies. As discussed off list, we also needed to verify the certificate so that passwords were not sent in the clear to a MITM. This has now been implemented. VERSION is bumped and ./makeapi was run. This patch is also rebased on top of my patch 0058 (which is already ACK'd), so 0058 needs to be merged before this patch (0056). Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0056.3-Add-otptoken-sync-command.patch Type: text/x-patch Size: 6701 bytes Desc: not available URL: From npmccallum at redhat.com Thu Jun 26 02:29:32 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Jun 2014 22:29:32 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403558642.3263.9.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> Message-ID: <1403749772.3523.26.camel@ipa.example.com> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: > On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: > > ----- Original Message ----- > > > ----- Original Message ----- > > > > > Can you check if ipaProtectedOperation is in the aci attribute in the > > > > > base tree object ? > > > > > It should be there as excluded, and that should cause admin to not be > > > > > able to retrieve keytabs. > > > > > > > > It was not. While running ipa-ldap-updater I got the following: > > > > InvalidSyntax: ACL Syntax Error(-5):(targetattr= > > > > \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > > > > allowed to rekey any entity\22; allow(write) groupdn = > > > > \22ldap:///cn=admins: Invalid syntax. > > > > > > Uhmm I do not see anything obviously wrong with ACI instruction, it looks > > > just like the one I replace, Ideas ? > > > Do you have ipaProtectedOperation in the schema ? > > > > > > (I rebased patch 3 but will wait to send a patchset until we understand (and > > > fix) why this is failing to update. > > > > Ok, apparently it was a quoting issue in the .update files, hopefully that's > > the only issue (I am at a conference today and do not have my test env. handy). > > > > The attached patches are rebased on the latest master. > > 0001: Line 555 has very wrong indentation. > > I don't see anything else wrong in the other patches. I've tested > everything and it works as designed. > > I have CC'd everyone who was involved with review at any point on these > patches. This serves as my public notice that I'd like to ACK the next > round of patches. If anyone has anything else to add, please do it > before tomorrow evening. Thanks! > > Nathaniel ACK Nathaniel From purpleidea at gmail.com Thu Jun 26 05:28:05 2014 From: purpleidea at gmail.com (James) Date: Thu, 26 Jun 2014 01:28:05 -0400 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid Message-ID: I think it's kind of funny that the cert for: https://www.freeipa.org/ is invalid, particularly since this is a security product. In any case, feel free to forward to whoever maintains this in case someone thinks it matters. Cheers, James From rob.townley at gmail.com Thu Jun 26 06:23:44 2014 From: rob.townley at gmail.com (Rob Townley) Date: Thu, 26 Jun 2014 01:23:44 -0500 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid In-Reply-To: References: Message-ID: StartSSL has free ssl certs. Very inexpensive wildcard certs ~$50.00. StartCom CA that has been trusted by browsers for years. On Jun 26, 2014 12:29 AM, "James" wrote: > I think it's kind of funny that the cert for: https://www.freeipa.org/ > is invalid, particularly since this is a security product. > > In any case, feel free to forward to whoever maintains this in case > someone thinks it matters. > > Cheers, > James > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Jun 26 06:26:15 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Jun 2014 09:26:15 +0300 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid In-Reply-To: References: Message-ID: <20140626062615.GK7233@redhat.com> On Thu, 26 Jun 2014, Rob Townley wrote: >StartSSL has free ssl certs. >Very inexpensive wildcard certs ~$50.00. >StartCom CA that has been trusted by browsers for years. We have proper certificate in place. This looks like OpenShift's misconfiguration. -- / Alexander Bokovoy From jcholast at redhat.com Thu Jun 26 06:30:16 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 08:30:16 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53AAF80C.7090106@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> Message-ID: <53ABBDF8.1080209@redhat.com> On 25.6.2014 18:25, Petr Viktorin wrote: > On 06/25/2014 05:29 PM, Jan Cholasta wrote: >> Hi, >> >> On 25.6.2014 17:17, Tomas Babej wrote: >>> Hi, >>> >>> Our datetime conversion does not support full LDAP Generalized >>> time syntax. In the unsupported cases, we should fall back >>> to string representation of the attribute. >>> >>> In particular, '0' is used to denote no value of LDAP generalized >>> time attribute. >>> >>> https://fedorahosted.org/freeipa/ticket/4350 >> >> NACK, this beats the purpose of decoding of the values, because it >> requires you to check the type of the value before using it. >> >> Instead, you should either fix the code that uses the >> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value >> directly, or exclude the attributes from decoding to datetime by >> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >> >> Honza >> > > I agree that just returning a string when conversion fails is the wrong > thing to do. > > I think that if LDAP generalized can contain the empty/invalid value, we > should convert the '0' to what Python uses for that -- None. > But None already means "empty attribute". -- Jan Cholasta From mkletzan at redhat.com Thu Jun 26 06:37:01 2014 From: mkletzan at redhat.com (Martin Kletzander) Date: Thu, 26 Jun 2014 08:37:01 +0200 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid In-Reply-To: References: Message-ID: <20140626063701.GB11780@wheatley> On Thu, Jun 26, 2014 at 01:23:44AM -0500, Rob Townley wrote: >StartSSL has free ssl certs. >Very inexpensive wildcard certs ~$50.00. >StartCom CA that has been trusted by browsers for years. I've heard of free (or low-cost) SSL certs for open source software and there should be a company providing SSL certs for domains as a part of the ResetTheNet initiative [1], but right now, I'm unable to find that, so I might have misunderstood some statement. Martin [1] https://www.resetthenet.org/ > On Jun 26, 2014 12:29 AM, "James" wrote: > >> I think it's kind of funny that the cert for: https://www.freeipa.org/ >> is invalid, particularly since this is a security product. >> >> In any case, feel free to forward to whoever maintains this in case >> someone thinks it matters. >> >> Cheers, >> James >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pviktori at redhat.com Thu Jun 26 07:21:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 09:21:34 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABBDF8.1080209@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> Message-ID: <53ABC9FE.9010505@redhat.com> On 06/26/2014 08:30 AM, Jan Cholasta wrote: > On 25.6.2014 18:25, Petr Viktorin wrote: >> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 25.6.2014 17:17, Tomas Babej wrote: >>>> Hi, >>>> >>>> Our datetime conversion does not support full LDAP Generalized >>>> time syntax. In the unsupported cases, we should fall back >>>> to string representation of the attribute. >>>> >>>> In particular, '0' is used to denote no value of LDAP generalized >>>> time attribute. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4350 >>> >>> NACK, this beats the purpose of decoding of the values, because it >>> requires you to check the type of the value before using it. >>> >>> Instead, you should either fix the code that uses the >>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value >>> directly, or exclude the attributes from decoding to datetime by >>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>> >>> Honza >>> >> >> I agree that just returning a string when conversion fails is the wrong >> thing to do. >> >> I think that if LDAP generalized can contain the empty/invalid value, we >> should convert the '0' to what Python uses for that -- None. >> > > But None already means "empty attribute". I don't think you can get [None] currently, can you? None is the default default for get(), but I don't think that's a problem. -- Petr? From pviktori at redhat.com Thu Jun 26 07:23:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 09:23:06 +0200 Subject: [Freeipa-devel] [PATCHES 202-222] Ipaplatform refactoring In-Reply-To: <53AB2771.5020304@redhat.com> References: <538EEA19.2000208@redhat.com> <53906D43.2060707@redhat.com> <5391A03D.1030408@redhat.com> <5396BE1C.8000000@redhat.com> <53971F35.5090006@redhat.com> <539EE8B6.7010003@redhat.com> <539F2E7F.2010600@redhat.com> <539FF95C.2060702@redhat.com> <53A0125D.1030407@ubuntu.com> <53A03152.4010204@redhat.com> <53A1535C.2030402@redhat.com> <53A2C10A.2080406@redhat.com> <53A2EB24.8030404@redhat.com> <53AA8CCD.6000604@redhat.com> <53AAD645.3080102@redhat.com> <53AAD91A.2000603@redhat.com> <53AAE3EF.5000005@redhat.com> <53AB0408.40304@redhat.com> <53AB246E.9050604@redhat.com> <53AB2771.5020304@redhat.com> Message-ID: <53ABCA5A.9020307@redhat.com> On 06/25/2014 09:48 PM, Tomas Babej wrote: > > On 06/25/2014 09:35 PM, Petr Viktorin wrote: >> On 06/25/2014 07:16 PM, Tomas Babej wrote: >>> >>> On 06/25/2014 04:59 PM, Tomas Babej wrote: >>>> >>>> On 06/25/2014 04:13 PM, Tomas Babej wrote: >>>>> >>>>> On 06/25/2014 04:01 PM, Tomas Babej wrote: >>>>>> >>>>>> On 06/25/2014 10:48 AM, Petr Viktorin wrote: >>>>>>> On 06/19/2014 03:52 PM, Tomas Babej wrote: >>>>>>>> >>>>>>>> On 06/19/2014 12:52 PM, Tomas Babej wrote: >>>>>>>>> On 06/18/2014 10:52 AM, Petr Viktorin wrote: >>>>>>>>>> On 06/17/2014 02:15 PM, Tomas Babej wrote: >>>>>>>>>>> On 06/17/2014 12:03 PM, Timo Aaltonen wrote: >>>>>>>>>>>> On 17.06.2014 11:16, Martin Kosek wrote: >>>>>>>>>>> Attached is a new version of patch 226, and a new patch 228, >>>>>>>>>>> which moves >>>>>>>>>>> the paths from installers to the paths module. >>>>>>>>>> In patch 226, there's another "certificated" typo in >>>>>>>>>> remove_ca_cert_from_systemwide_ca_store >>>>>>>>>> >>>>>>>>>>> I greped the repository, and I do not see many paths lurking >>>>>>>>>>> around any >>>>>>>>>>> more, there are only some in the error messages (as these >>>>>>>>>>> can't be >>>>>>>>>>> reliably replaced automatically, and will need some manual >>>>>>>>>>> love). >>>>>>>>>>> >>>>>>>>>>> If you see any forgotten paths, which should be added to the >>>>>>>>>>> module, let >>>>>>>>>>> me know. >>>>>>> >>>>>>> Well, since you asked... >>>>>>> >>>>>>> install/tools/ipa-upgradeconfig:236: >>>>>>> ipautil.run([paths.PKI_SETUP_PROXY, '-pki_instance_root=/var/lib' >>>>>>> ipaserver/install/cainstance.py:1330: "-pki_instance_root=/var/lib", >>>>>>> >>>>>>> ipaserver/install/dsinstance.py:209:InstallLdifFile= >>>>>>> /var/lib/dirsrv/boot.ldif >>>>>>> ipaserver/install/dsinstance.py:210:inst_dir= >>>>>>> /var/lib/dirsrv/scripts-$SERVERID >>>>>>> >>>>>>> ipaserver/install/ipa_backup.py:464: >>>>>>> '--exclude=/var/lib/ipa/backup', >>>>>>> >>>>>>> ipatests/test_integration/tasks.py:451: host.run_command("find >>>>>>> /var/lib/sss/db -name '*.ldb' | " >>>>>>> >>>>>>> install/tools/ipa-replica-conncheck:403: >>>>>>> "/usr/sbin/ipa-replica-conncheck " + >>>>>>> install/tools/ipa-replica-conncheck:414: >>>>>>> print_info("/usr/sbin/ipa-replica-conncheck " + " >>>>>>> ".join(remote_check_opts)) >>>>>>> >>>>>>> ipapython/ipautil.py:296: env["PATH"] = >>>>>>> "/bin:/sbin:/usr/kerberos/bin:/usr/kerberos/sbin:/usr/bin:/usr/sbin" >>>>>>> >>>>>>> ipaserver/install/cainstance.py:88:ConfigFile = >>>>>>> /usr/share/pki/ca/conf/database.ldif >>>>>>> >>>>>>> ipaserver/install/bindinstance.py:829: >>>>>>> ipautil.run(['/usr/libexec/generate-rndc-key.sh']) >>>>>>> >>>>>> >>>>>> /me will think twice about teasing nex time. >>>>>> >>>>>> This are paths requiring manual changes in one way or the other and >>>>>> as such cannot be handled by my tool. Let's not stall the patcheset >>>>>> on this. We can fix these (and surely there are other) as we go >>>>>> along. >> >> OK, not a reason to hold the patch back. >> But, the fact that the tool can't handle them doesn't make them less >> important. Let's keep the ticket open, or open a new one. >> >>>>>>> I guess it'll be a while before we catch them all, but now it's at >>>>>>> least clear where these paths should be, so anyone porting to >>>>>>> another distro can send patches (or tickets) upstream. >>>>>>> >>>>>>>>>> I see another duplicate: >>>>>>>>>> SSS_KRB5_INCLUDE_D = "/var/lib/sss/pubconf/krb5.include.d" >>>>>>>>>> SSSD_PUBCONF_KRB5_INCLUDE_D_DIR = >>>>>>>>>> "/var/lib/sss/pubconf/krb5.include.d/" >>>>>>> >>>>>>> Could you just pick one instead? Would ipa_backup.py break if it >>>>>>> had a trailing slash here? >>>>>>> >>>>>> >>>>>> Yes. I verified it produces the same result with or without trailing >>>>>> slash, fixed. >>>>>> >>>>>> >>>>>>> In ipa-client-install, if you set: >>>>>>> NSSWITCH_CONF = paths.NSSWITCH_CONF >>>>>>> then you should only use one of those later. (Preferably paths.*, >>>>>>> to get rid of the redundant constants.) >>>>>>> Perhaps this is for another patch that would clean up all the cases >>>>>>> where these trivial module variables are used. >>>>>>> >>>>>> >>>>>> I agree. Fixed this occurence. >> >> I've opened an easyfix ticket for the rest: >> https://fedorahosted.org/freeipa/ticket/4399 >> >>>>>>>>> Fixed all mentioned issues. I also attached a patch 230, which >>>>>>>>> removes >>>>>>>>> the base Authconfig class. >>>>>>> >>>>>>> >>>>>>>> Attaching one additional patch, which removes unnecessary build >>>>>>>> warnings. >>>>>>>> >>>>>>> >>>>>>> 226, 230, 231 look good >>>>>>> >>>>>> >>>>>> Attaching whole updated patchset. >>>>> >>>>> Attaching one more patch which should fix broken CI tests. >>>>> >>>> >>>> Self-NACK - It seems I omitted one occurence of NSSWITCH_CONF in >>>> ipa-client-install, fixed now. >>>> >>>> Attaching the whole patchset for your convenience. >>>> -- >>> Attaching a correct patchset this time. >> >> I hate to break it to you, but... >> you sent the wrong patch 228 :( >> > > No way! That's a official fail combo on my part. Here's the correct patch. ACK, pushed to master: e5e42fc83ae74f0e0c68e68417a39fe6f2f2ae63 -- Petr? From jcholast at redhat.com Thu Jun 26 07:33:13 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 09:33:13 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABC9FE.9010505@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> Message-ID: <53ABCCB9.2040208@redhat.com> On 26.6.2014 09:21, Petr Viktorin wrote: > On 06/26/2014 08:30 AM, Jan Cholasta wrote: >> On 25.6.2014 18:25, Petr Viktorin wrote: >>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Our datetime conversion does not support full LDAP Generalized >>>>> time syntax. In the unsupported cases, we should fall back >>>>> to string representation of the attribute. >>>>> >>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>> time attribute. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>> >>>> NACK, this beats the purpose of decoding of the values, because it >>>> requires you to check the type of the value before using it. >>>> >>>> Instead, you should either fix the code that uses the >>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value >>>> directly, or exclude the attributes from decoding to datetime by >>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>> >>>> Honza >>>> >>> >>> I agree that just returning a string when conversion fails is the wrong >>> thing to do. >>> >>> I think that if LDAP generalized can contain the empty/invalid value, we >>> should convert the '0' to what Python uses for that -- None. >>> >> >> But None already means "empty attribute". > > I don't think you can get [None] currently, can you? None is the default > default for get(), but I don't think that's a problem. > You can't, but you can get it from single_value when the attribute is empty or assign it to an attribute to make it empty. I would very much prefer if we avoided None, because it will only create mess and possibly some hard to catch errors. -- Jan Cholasta From pviktori at redhat.com Thu Jun 26 07:40:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 09:40:48 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABCCB9.2040208@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> Message-ID: <53ABCE80.7030802@redhat.com> On 06/26/2014 09:33 AM, Jan Cholasta wrote: > On 26.6.2014 09:21, Petr Viktorin wrote: >> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>> time syntax. In the unsupported cases, we should fall back >>>>>> to string representation of the attribute. >>>>>> >>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>> time attribute. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>> >>>>> NACK, this beats the purpose of decoding of the values, because it >>>>> requires you to check the type of the value before using it. >>>>> >>>>> Instead, you should either fix the code that uses the >>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw value >>>>> directly, or exclude the attributes from decoding to datetime by >>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>> >>>>> Honza >>>>> >>>> >>>> I agree that just returning a string when conversion fails is the wrong >>>> thing to do. >>>> >>>> I think that if LDAP generalized can contain the empty/invalid >>>> value, we >>>> should convert the '0' to what Python uses for that -- None. >>>> >>> >>> But None already means "empty attribute". >> >> I don't think you can get [None] currently, can you? None is the default >> default for get(), but I don't think that's a problem. >> > > You can't, but you can get it from single_value when the attribute is > empty or assign it to an attribute to make it empty. > > I would very much prefer if we avoided None, because it will only create > mess and possibly some hard to catch errors. > The problem is that "unset" is a valid value here, and None is the Python representation for that. If it has to make single_value ambiguous, I'd be fine with that -- single_value is just a helper. But, shouldn't single_value[x] raise KeyError if the attribute is missing? As for setting, there is a difference between entry.single_value[x] = None and del entry[x] and we should use the correct one for each case. -- Petr? From pviktori at redhat.com Thu Jun 26 08:29:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 10:29:31 +0200 Subject: [Freeipa-devel] [PATCH 0229] dsinstance: Detect dynamic plugin support and restart server In-Reply-To: <53A1ACE5.2060600@redhat.com> References: <53A1ACE5.2060600@redhat.com> Message-ID: <53ABD9EB.2070705@redhat.com> On 06/18/2014 05:14 PM, Tomas Babej wrote: > Hi, > > With 389-ds-base 1.3.3. comes the dynamic plugin support. We need to > restart the server right after modifying the schema, as the plugins > will be enabled at the point they are added (and not at the next > server restart). > > Properly handle both situations in the installer. > > https://fedorahosted.org/freeipa/ticket/4203 Installation succeeded with normal DS, but with a build with dynamic plugins, the DS didn't start and installation failed. There were some plugin-related failures in the DS error log: [26/Jun/2014:10:11:41 +0200] ipapwd_start - [file ipa_pwd_extop.c, line 1243]: No config Entry extop? [26/Jun/2014:10:11:41 +0200] ipapwd_post_modadd - [file prepost.c, line 1019]: Internal error, couldn't find pluginextension ?! [26/Jun/2014:10:11:41 +0200] ipapwd_post_modadd - [file prepost.c, line 1019]: Internal error, couldn't find pluginextension ?! [26/Jun/2014:10:13:15 +0200] ipa_winsync_config - [file ipa-winsync-config.c, line 115]: Error: IPA WinSync plug-in already configured. Please remove the plugin config entry [cn=ipa-winsync,cn=plugins,cn=config] [26/Jun/2014:10:13:15 +0200] ipa_winsync_plugin_start - [file ipa-winsync.c, line 651]: configuration failed (Bad parameter to an ldap routine) [26/Jun/2014:10:13:15 +0200] - Failed to start preoperation plugin ipa-winsync [26/Jun/2014:10:13:15 +0200] - plugin_restart: Plugin (cn=ipa-winsync,cn=plugins,cn=config) failed to restart after configuration change (Failed to start plugin "ipa-winsync". See errors log.). Reverting to original plugin entry. [26/Jun/2014:10:13:16 +0200] ipa_winsync_config - [file ipa-winsync-config.c, line 115]: Error: IPA WinSync plug-in already configured. Please remove the plugin config entry [cn=ipa-winsync,cn=plugins,cn=config] [26/Jun/2014:10:13:16 +0200] ipa_winsync_plugin_start - [file ipa-winsync.c, line 651]: configuration failed (Bad parameter to an ldap routine) [26/Jun/2014:10:13:16 +0200] - Failed to start preoperation plugin ipa-winsync [26/Jun/2014:10:13:16 +0200] dse_post_modify_plugin - The configuration change for plugin (cn=ipa-winsync,cn=plugins,cn=config) could not be applied dynamically, and will be ignored until the server is restarted. ... [26/Jun/2014:10:14:30 +0200] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/Jun/2014:10:14:30 +0200] memberof-plugin - Memberof task starts (arg: (objectclass=*)) ... [26/Jun/2014:10:14:31 +0200] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/Jun/2014:10:14:32 +0200] memberof-plugin - Memberof task finished (arg: (objectclass=*)) ... [26/Jun/2014:10:14:40 +0200] NSACLPlugin - The ACL target cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com does not exist [26/Jun/2014:10:14:40 +0200] NSACLPlugin - The ACL target cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com does not exist [26/Jun/2014:10:15:19 +0200] - Entry "cn=adtrust agents,cn=sysaccounts,cn=etc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" -- attribute "memberOf" not allowed [26/Jun/2014:10:15:19 +0200] memberof-plugin - memberof_postop_add: failed to add dn(cn=System: Read system trust accounts,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com), error (-1) If you want I can give access to the VM. For the record, here's how to build 389-ds with the plugins enabled. 1.) Build dependencies & source: yum install 389-ds-base* libicu* icu* bzip* net-snmp net-snmp-devel pcre* pam* mod-nss gdb gcc* perl-Archive-Tar -y --skip-broken git clone git://git.fedorahosted.org/git/389/ds.git cd ds 2.) Apply this diff: diff --git a/ldap/ldif/template-dse.ldif.in b/ldap/ldif/template-dse.ldif.in index 85662a3..f4b32c7 100644 --- a/ldap/ldif/template-dse.ldif.in +++ b/ldap/ldif/template-dse.ldif.in @@ -58,7 +58,7 @@ nsslapd-maxdescriptors: 1024 nsslapd-max-filter-nest-level: 40 nsslapd-ndn-cache-enabled: on nsslapd-sasl-mapping-fallback: off -nsslapd-dynamic-plugins: off +nsslapd-dynamic-plugins: on nsslapd-allow-hashed-passwords: off dn: cn=features,cn=config diff --git a/ldap/servers/slapd/libglobs.c b/ldap/servers/slapd/libglobs.c index e890aed..e13c468 100644 --- a/ldap/servers/slapd/libglobs.c +++ b/ldap/servers/slapd/libglobs.c @@ -1567,7 +1567,7 @@ FrontendConfig_init () { init_plugin_logging = cfg->plugin_logging = LDAP_OFF; init_listen_backlog_size = cfg->listen_backlog_size = DAEMON_LISTEN_SIZE; init_ignore_time_skew = cfg->ignore_time_skew = LDAP_OFF; - init_dynamic_plugins = cfg->dynamic_plugins = LDAP_OFF; + init_dynamic_plugins = cfg->dynamic_plugins = LDAP_ON; init_cn_uses_dn_syntax_in_dns = cfg->cn_uses_dn_syntax_in_dns = LDAP_OFF; #if defined(LINUX) init_malloc_mxfast = cfg->malloc_mxfast = DEFAULT_MALLOC_UNSET; 3.) Build make -j1 -f rpm.mk rpms -- Petr? From jcholast at redhat.com Thu Jun 26 08:33:42 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 10:33:42 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABCE80.7030802@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> Message-ID: <53ABDAE6.2010209@redhat.com> On 26.6.2014 09:40, Petr Viktorin wrote: > On 06/26/2014 09:33 AM, Jan Cholasta wrote: >> On 26.6.2014 09:21, Petr Viktorin wrote: >>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>> to string representation of the attribute. >>>>>>> >>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>> time attribute. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>> >>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>> requires you to check the type of the value before using it. >>>>>> >>>>>> Instead, you should either fix the code that uses the >>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>> value >>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> I agree that just returning a string when conversion fails is the >>>>> wrong >>>>> thing to do. >>>>> >>>>> I think that if LDAP generalized can contain the empty/invalid >>>>> value, we >>>>> should convert the '0' to what Python uses for that -- None. >>>>> >>>> >>>> But None already means "empty attribute". >>> >>> I don't think you can get [None] currently, can you? None is the default >>> default for get(), but I don't think that's a problem. >>> >> >> You can't, but you can get it from single_value when the attribute is >> empty or assign it to an attribute to make it empty. >> >> I would very much prefer if we avoided None, because it will only create >> mess and possibly some hard to catch errors. >> > > The problem is that "unset" is a valid value here, It is not, according to Generalized Time syntax (RFC 4517 section 3.3.13) "0" is an invalid value and we should treat it the same way as any other invalid value (hence my original suggestion). > and None is the > Python representation for that. If it has to make single_value > ambiguous, I'd be fine with that -- single_value is just a helper. > > But, shouldn't single_value[x] raise KeyError if the attribute is missing? It does. When attribute is empty/None, it is unset, not missing. There is old code which depends on this. > As for setting, there is a difference between > entry.single_value[x] = None > and > del entry[x] > and we should use the correct one for each case. > > Yes, but until the old code is fixed, None has a special meaning and can't be used for anything else. -- Jan Cholasta From mkosek at redhat.com Thu Jun 26 08:37:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 10:37:42 +0200 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403749772.3523.26.camel@ipa.example.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> Message-ID: <53ABDBD6.7060800@redhat.com> On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: > On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: >> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the >>>>>> base tree object ? >>>>>> It should be there as excluded, and that should cause admin to not be >>>>>> able to retrieve keytabs. >>>>> >>>>> It was not. While running ipa-ldap-updater I got the following: >>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= >>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are >>>>> allowed to rekey any entity\22; allow(write) groupdn = >>>>> \22ldap:///cn=admins: Invalid syntax. >>>> >>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks >>>> just like the one I replace, Ideas ? >>>> Do you have ipaProtectedOperation in the schema ? >>>> >>>> (I rebased patch 3 but will wait to send a patchset until we understand (and >>>> fix) why this is failing to update. >>> >>> Ok, apparently it was a quoting issue in the .update files, hopefully that's >>> the only issue (I am at a conference today and do not have my test env. handy). >>> >>> The attached patches are rebased on the latest master. >> >> 0001: Line 555 has very wrong indentation. >> >> I don't see anything else wrong in the other patches. I've tested >> everything and it works as designed. >> >> I have CC'd everyone who was involved with review at any point on these >> patches. This serves as my public notice that I'd like to ACK the next >> round of patches. If anyone has anything else to add, please do it >> before tomorrow evening. Thanks! >> >> Nathaniel > > ACK > > Nathaniel Pushed all 6 patches to master. Thanks for careful review! Martin From pviktori at redhat.com Thu Jun 26 08:39:04 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 10:39:04 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABDAE6.2010209@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> Message-ID: <53ABDC28.1040607@redhat.com> On 06/26/2014 10:33 AM, Jan Cholasta wrote: > On 26.6.2014 09:40, Petr Viktorin wrote: >> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>> to string representation of the attribute. >>>>>>>> >>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>> time attribute. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>> >>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>> requires you to check the type of the value before using it. >>>>>>> >>>>>>> Instead, you should either fix the code that uses the >>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>> value >>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>> >>>>>>> Honza >>>>>>> [...] >> >> The problem is that "unset" is a valid value here, > > It is not, according to Generalized Time syntax (RFC 4517 section > 3.3.13) "0" is an invalid value and we should treat it the same way as > any other invalid value (hence my original suggestion). OK, in that case ignore what I said here. So am I correct that 389-ds storing a value that doesn't comply with the attribute's syntax? Should we file a DS bug? -- Petr? From mkosek at redhat.com Thu Jun 26 08:39:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 10:39:31 +0200 Subject: [Freeipa-devel] FYI: Cert for https://www.freeipa.org/ is invalid In-Reply-To: References: Message-ID: <53ABDC43.9050904@redhat.com> On 06/26/2014 07:28 AM, James wrote: > I think it's kind of funny that the cert for: https://www.freeipa.org/ > is invalid, particularly since this is a security product. > > In any case, feel free to forward to whoever maintains this in case > someone thinks it matters. > > Cheers, > James You are of course right. Given that OpenShift (where the wiki is running) now supports certificates for aliases, it is possible to configure the certificate. I have started the machinery, stay tuned. Thanks, Martin From jcholast at redhat.com Thu Jun 26 08:44:29 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 10:44:29 +0200 Subject: [Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong In-Reply-To: <53ABDC28.1040607@redhat.com> References: <53AAE81A.7090805@redhat.com> <53AAEAC1.3080106@redhat.com> <53AAF80C.7090106@redhat.com> <53ABBDF8.1080209@redhat.com> <53ABC9FE.9010505@redhat.com> <53ABCCB9.2040208@redhat.com> <53ABCE80.7030802@redhat.com> <53ABDAE6.2010209@redhat.com> <53ABDC28.1040607@redhat.com> Message-ID: <53ABDD6D.6050905@redhat.com> On 26.6.2014 10:39, Petr Viktorin wrote: > On 06/26/2014 10:33 AM, Jan Cholasta wrote: >> On 26.6.2014 09:40, Petr Viktorin wrote: >>> On 06/26/2014 09:33 AM, Jan Cholasta wrote: >>>> On 26.6.2014 09:21, Petr Viktorin wrote: >>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote: >>>>>> On 25.6.2014 18:25, Petr Viktorin wrote: >>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Our datetime conversion does not support full LDAP Generalized >>>>>>>>> time syntax. In the unsupported cases, we should fall back >>>>>>>>> to string representation of the attribute. >>>>>>>>> >>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized >>>>>>>>> time attribute. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350 >>>>>>>> >>>>>>>> NACK, this beats the purpose of decoding of the values, because it >>>>>>>> requires you to check the type of the value before using it. >>>>>>>> >>>>>>>> Instead, you should either fix the code that uses the >>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw >>>>>>>> value >>>>>>>> directly, or exclude the attributes from decoding to datetime by >>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE. >>>>>>>> >>>>>>>> Honza >>>>>>>> > [...] >>> >>> The problem is that "unset" is a valid value here, >> >> It is not, according to Generalized Time syntax (RFC 4517 section >> 3.3.13) "0" is an invalid value and we should treat it the same way as >> any other invalid value (hence my original suggestion). > > OK, in that case ignore what I said here. > > So am I correct that 389-ds storing a value that doesn't comply with the > attribute's syntax? Should we file a DS bug? > AFAIK syntax checks are done only on LDAP adds and mods, so unless we are setting "0" somewhere and DS does not complain, it is not a bug. -- Jan Cholasta From pspacek at redhat.com Thu Jun 26 10:02:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 26 Jun 2014 12:02:07 +0200 Subject: [Freeipa-devel] [Freeipa-interest] Announcing bind-dyndb-ldap version 5.0 Message-ID: <53ABEF9F.7050303@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 5.0. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 20 and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-5.0-1.fc20 Release to Fedora 'updates' repo will be coordinated with FreeIPA 4.0 release to prevent breakages. == Changes in 5.0 == [1] Support for DNSSEC in-line signing was added. Now any LDAP zone can be signed with keys provided by user. [2] DNSKEY, RRSIG, NSEC and NSEC3 records are automatically managed by BIND+bind-dyndb-ldap. Respective attributes in LDAP are ignored. [3] Forwarder semantic was changed to match BIND's semantics: - idnsZone object always represents master zone - idnsForwardZone object (new) always represents forward zone [4] Master root zone can be stored in LDAP. == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. !!! CAUTION !!! idnsZone object class changed it's semantics. Please read https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/plain/README and update idnsForwarders and idnsForward policy attributes in your DNS zones accordingly. Transition from idnsZone to idnsForwardZone object class can be made seamless if you change data in LDAP before you upgrade to version 5.x. All bind-dyndb-ldap versions >= 3.0 support the idnsForwardZone object class. Users of FreeIPA < 4.0 should be careful when upgrading bind-dyndb-ldap to version >= 5.0 (if they do not upgrade to FreeIPA 4.x at the same time). Configuration semantics related to conditional (per-zone) forwarding has changed and FreeIPA < 4.0 doesn't have appropriate user interface and API. It is safe to upgrade if you use *only* global forwarders (shown by 'ipa dnsconfig-show') and *do not* use per-zone forwarders (shown by 'ipa dnszone-show'). Don't hesitate to ask freeipa-users mailing list if you need help with upgrade. !!! CAUTION !!! Downgrading back to any 4.x version is supported. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek @ Red Hat From mkosek at redhat.com Thu Jun 26 10:18:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 12:18:30 +0200 Subject: [Freeipa-devel] [PATCH] 302 Do not corrupt sshd_config in client install when trailing newline is missing In-Reply-To: <53A19A94.7010504@redhat.com> References: <53A19A94.7010504@redhat.com> Message-ID: <53ABF376.3010602@redhat.com> On 06/18/2014 03:56 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza Works fine, tested with # perl -i -pe 'chomp if eof' /etc/ssh/sshd_config trick. ACK, pushed to master. Martin From pvoborni at redhat.com Thu Jun 26 10:39:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Jun 2014 12:39:46 +0200 Subject: [Freeipa-devel] [PATCH] 676 rpcserver: fix local vs utc time comparison In-Reply-To: <53AAEC7A.9040907@redhat.com> References: <53A984DC.3040609@redhat.com> <53AAEC7A.9040907@redhat.com> Message-ID: <53ABF872.8070100@redhat.com> On 25.6.2014 17:36, Jan Cholasta wrote: > Hi, > > On 24.6.2014 16:02, Petr Vobornik wrote: >> login_password did not work properly in timezones other than +0h because >> local time was compared with utc time. > > ACK. pushed to master: 1c94edd3a09711d85ba099bd815c0bdd8f0210c1 rpcserver: fix local vs utc time comparison > >> >> Bug introduced in: >> https://fedorahosted.org/freeipa/ticket/4339 >> >> We should review other code for invalid usage of datetime.now() > > All other uses of datetime.now() predate LDAP datetime decoding, so I > think we are fine. > > Honza > -- Petr Vobornik From pviktori at redhat.com Thu Jun 26 10:43:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Jun 2014 12:43:15 +0200 Subject: [Freeipa-devel] [PATCH] 302 Do not corrupt sshd_config in client install when trailing newline is missing In-Reply-To: <53ABF376.3010602@redhat.com> References: <53A19A94.7010504@redhat.com> <53ABF376.3010602@redhat.com> Message-ID: <53ABF943.8020405@redhat.com> On 06/26/2014 12:18 PM, Martin Kosek wrote: > On 06/18/2014 03:56 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Works fine, tested with > # perl -i -pe 'chomp if eof' /etc/ssh/sshd_config > trick. > > ACK, pushed to master. > > Martin > It would be really nice to have some tests for this function. -- Petr? From pvoborni at redhat.com Thu Jun 26 10:53:56 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Jun 2014 12:53:56 +0200 Subject: [Freeipa-devel] [PATCH] 659-666 Support of password reset with OTP In-Reply-To: <53AB09B2.3030406@redhat.com> References: <5398577C.8090605@redhat.com> <53A450AD.9020908@redhat.com> <53AB09B2.3030406@redhat.com> Message-ID: <53ABFBC4.7010009@redhat.com> On 25.6.2014 19:41, Endi Sukma Dewata wrote: > On 6/20/2014 10:18 AM, Petr Vobornik wrote: >> On 11.6.2014 15:19, Petr Vobornik wrote: >>> Patch set contains both API/server and Web UI parts. >>> >>> [PATCH] 659 ldap2: add otp support to modify_password >>> [PATCH] 660 rpcserver: add otp support to change_password handler >>> [PATCH] 661 ipa-passwd: add OTP support >>> [PATCH] 662 webui: support password change with OTP in login screen >>> [PATCH] 663 webui: placeholder attribute support in textbox and textarea >>> [PATCH] 664 webui: add placeholders to login screen >>> [PATCH] 665 webui: rebase user password dialog on password dialog and >>> add otp support >>> [PATCH] 666 webui: support otp in reset_password.html >>> >>> https://fedorahosted.org/freeipa/ticket/4262 >> >> attaching rebased patches (mainly because of VERSION conflict) > > ACK. Possible improvements (some of which are already discussed on IRC): pushed to master: * 7fca783ec554e525465221af13e17f419769c760 ldap2: add otp support to modify_password * 896920ed12a4601a60ac6a7e6f4f13d9ca48df77 rpcserver: add otp support to change_password handler * 2df654223259ca336843f37a229838e125c874d6 ipa-passwd: add OTP support * f9adc5a5f3ed84ae23c4261f7316ad2e84952d68 webui: support password change with OTP in login screen * 6e7d4ad468854cce8a9a76f3abf8268e3813ff93 webui: placeholder attribute support in textbox and textarea * e3de46767683c5050377cc5e683cd6e3d28ea4e9 webui: add placeholders to login screen * 870db2f677dff01750aeec104c90fce3ca0e54be webui: rebase user password dialog on password dialog and add otp support * 70c77e6a3cfe1a4fbfb5f053a4d47dd2e47d8b3b webui: support otp in reset_password.html I've shamelessly copied all 13 items into new trac ticket https://fedorahosted.org/freeipa/ticket/4402 to track these possible improvements. We can create separate tickets for issues 8,9,11,12,13 if needed. > > 1. The "clock interval" field in the Add OTP Token dialog could be > disabled for HOTP. > > 2. The "clock interval" and "counter" fields (and probably some other > fields too) in the OTP Token details page could be hidden depending on > the token type. > > 3. The Add OTP Token dialog could provide more descriptive token types: > time-based or counter-based token instead of just TOTP or HOTP. > > 4. The OTP Token details page could show the token type (I suppose the > model may not be descriptive enough). > > 5. It would be nice to have a link/button to add OTP Token from the user > details page with the owner already set to the user. > > 6. The "clock interval" should have a unit of measurements (i.e. seconds). > > 7. When logging in with an expired password, the user will be asked to > reset a password and enter an OTP. Although OTP means one-time password, > some users could be confusing it with the OTP he/she just entered in the > previous page. It would be nicer to say "New OTP" or add an explanation > "Wait for a new OTP" to make sure the user enters a new OTP. > > 8. In the "User authentication types" field it might be better to say > "password + OTP" instead of just "otp". The checkbox value can remain > "otp". > > 9. The "User authentication types" is a bit confusing because if none > are selected it doesn't mean that no authentication is allowed, but it > means it's unset and it will use the global setting. The UI probably > should provide a separate radio button to select "Use global setting" or > show the effective setting next to it. > > 10. The "Default user authentication types" in the global setting is a > bit confusing because by default nothing is selected but the actual > default is supposedly not empty. > > 11. Ideally the password reset page/dialog should indicate whether the > old password and the OTP are required based on the actual authentication > type available to the user. > > 12. Ideally there should be a way to display the QR code of an existing > OTP token. > > 13. The UI could also provide a link to download the OTP app or a list > of supported apps. > -- Petr Vobornik From abokovoy at redhat.com Thu Jun 26 11:00:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Jun 2014 14:00:20 +0300 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403728293.3523.19.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <1403557986.3263.7.camel@ipa.example.com> <20140625103511.GF7233@redhat.com> <1403704392.3523.13.camel@ipa.example.com> <1403728293.3523.19.camel@ipa.example.com> Message-ID: <20140626110020.GL7233@redhat.com> On Wed, 25 Jun 2014, Nathaniel McCallum wrote: >On Wed, 2014-06-25 at 09:53 -0400, Nathaniel McCallum wrote: >> On Wed, 2014-06-25 at 13:35 +0300, Alexander Bokovoy wrote: >> > On Mon, 23 Jun 2014, Nathaniel McCallum wrote: >> > >On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: >> > >> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >> > >> >On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: >> > >> >> This command behaves almost exactly like otptoken-add except: >> > >> >> 1. The new token data is written directly to a YubiKey >> > >> >> 2. The vendor/model/serial fields are populated from the YubiKey >> > >> >> >> > >> >> === NOTE === >> > >> >> 1. This patch depends on the new Fedora package: python-yubico. If you >> > >> >> would like to help with the package review, please assign yourself here: >> > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 >> > >> > >> > >> >New version of the patch. This one works (yay!). >> > >> > >> > >> >1. Because of the dependency on python-yubico, is this feature something >> > >> >we want in core FreeIPA? As a subpackage? Separate project altogether? >> > >> >The only dependency for python-yubico is pyusb. >> > >> I'd prefer to have it integrated but have a separate dummy subpackage >> > >> that pulls in all required dependencies, like, freeipa-tools-yubico. Instead >> > >> of failing when 'ipa otptoken-add-yubikey' is called, please wrap the >> > >> python-yubico import into a code that allows reporting a message back to >> > >> the user advising to install the package. >> > >> >> > >> Who is a supposed user for this command? IPA command line interface isn't >> > >> usually available on enrolled machines even though underlying Python >> > >> modules are all there. Are we talking about admins or just users? >> > > >> > >As discussed on IRC, we are currently hard-coding lots of optional >> > >dependencies. And breaking this apart into subpackages can be solved at >> > >a later point. YubiKey is also a unique case: we don't expect to be >> > >adding many more plugins like this. >> > > >> > >For these reasons, I have kept this as a hard dependency. To ease this >> > >transition, I have added python-yubico to F20 and EL6. You can help with >> > >the update review here: >> > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 >> > >https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 >> > > >> > >> >3. This code currently emits a warning from the call to otptoken-add: >> > >> >WARNING: API Version number was not sent, forward compatibility not >> > >> >guaranteed. Assuming server's API version, 2.89 >> > >> > >> > >> >How do I fix this? >> > >> Do not filter 'version' field in options in execute(). >> > > >> > >I opted to not filter out version rather than hard-code it (pviktori's >> > >suggestion). This is based on the fact that otptoken-add-yubikey is >> > >tightly integrated with otptoken-add (even using some of the class >> > >attributes from otptoken). >> > > >> > >> >4. I am not sure why I have to delete the summary and value keys from >> > >> >the return dictionary. It would be nice to display this summary message >> > >> >just like otptoken-add. >> > > >> > >I still need help on this. >> > > >> > >> >5. Am I doing the ipatoken(vendor|model|serial) options correctly? These >> > >> >aren't user settable, but we need to pass them from the yubikey >> > >> >(client-side) to the server. >> > > >> > >This is no longer needed since I am doing everything in forward(). >> > >However, listing these three as output params causes them to appear >> > >before the token's ID. I don't think this is the right way to output >> > >these. But this seems to me a framework issue. >> > > >> > >> >6. I'm not sure my use of assert or ValueError are correct. What should >> > >> >I do here? >> > > >> > >Still need help here. >> > Fixed this part. >> > >> > > >> > >> >7. Considering that this is just a specialized invocation of >> > >> >otptoken-add, can't we do this all on the client-side? This is why I had >> > >> >originally used frontend.Local rather than frontend.Command. >> > >> You don't need to implement execute then, only forward, where you'll >> > >> forward your call to the server under otptoken_add name. >> > >> >> > >> Typically in #forward we call super's forward but that is because we >> > >> in Command.forward() we simply forward the command to the remote backend, >> > >> using the self.name. In your case we shouldn't really have a separate >> > >> command on the server under the same name, so you'll need to avoid >> > >> calling >> > >> >> > >> So, it should look like this: >> > >> >> > >> def forward(self, *args, **kw): >> > >> perform yubikey initialization >> > >> filter out kw and args, if needed >> > >> return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) >> > >> >> > >> See service_show implementation for an example. >> > > >> > >Fixed. >> > I'm attaching few fixups to the patch that make it proper reporting for >> > non-Yubikey case and also properly update VERSION. >> > >> > Provisional ACK. >> >> Merged. > >This patch includes everything above and fixes the missing ./makeapi >run. ACK. Please do not commit it yet as there is a specific order in which all these patches should be committed. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jun 26 11:01:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Jun 2014 14:01:21 +0300 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support In-Reply-To: <1403728331.3523.20.camel@ipa.example.com> References: <1401764823.4161.4.camel@ipa.example.com> <1403641921.3523.2.camel@ipa.example.com> <20140625102139.GE7233@redhat.com> <1403728331.3523.20.camel@ipa.example.com> Message-ID: <20140626110120.GM7233@redhat.com> On Wed, 25 Jun 2014, Nathaniel McCallum wrote: >On Wed, 2014-06-25 at 13:21 +0300, Alexander Bokovoy wrote: >> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >> >On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: >> >> This HTTP call takes the following parameters: >> >> * user >> >> * password >> >> * first_code >> >> * second_code >> >> * token (optional) >> >> >> >> Using this information, the server will perform token synchronization. >> >> If the token is not specified, all tokens will be searched for >> >> synchronization. >> >> Otherwise, only the token specified will be searched. >> >> >> >> This patch depends on my patch #0054. >> > >> >Attached is a new revision. This version should force an update >> >to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. >> ACK with condition that you apply attached fixups. >> >> Since token that is passed by 'ipa otptoken-sync' command is not a full >> DN, we need to support both cases, when DN and just a name is passed. >> Attached patch fixes this. > >Applied. ACK. This should be committed first one. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Jun 26 11:02:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Jun 2014 14:02:44 +0300 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <1403728418.3523.21.camel@ipa.example.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <1403643460.3523.5.camel@ipa.example.com> <20140625101837.GD7233@redhat.com> <1403728418.3523.21.camel@ipa.example.com> Message-ID: <20140626110244.GN7233@redhat.com> On Wed, 25 Jun 2014, Nathaniel McCallum wrote: >On Wed, 2014-06-25 at 13:18 +0300, Alexander Bokovoy wrote: >> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >> >On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote: >> >> On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >> >> > On 3.6.2014 05:08, Nathaniel McCallum wrote: >> >> > > This command calls the token sync HTTP POST call in the server providing >> >> > > the CLI interface to synchronization. >> >> > > >> >> > > https://fedorahosted.org/freeipa/ticket/4260 >> >> > > >> >> > > This patch depends on my patch #0055. >> >> > > >> >> > >> >> > Build fails on validation. You forgot to update API.txt and also the >> >> > command misses __doc__. >> >> > >> >> > (not a proper review) >> >> >> >> Thanks, fixed. >> > >> >Attached is a new revision which is rebased on master. >> > >> >In addition it: >> > >> >1. Moves user to a parameter and moves token to an argument. Doing it >> >this way both mirrors the existing otptoken APIs and sets us up for >> >future Kerberos based syncing where the username/password will be >> >optional. >> > >> >2. Converts the token ID to a DN. >> ACK. >> >> Please do not commit this patch yet, we are not done with its >> dependencies. > >As discussed off list, we also needed to verify the certificate so that >passwords were not sent in the clear to a MITM. This has now been >implemented. VERSION is bumped and ./makeapi was run. This patch is also >rebased on top of my patch 0058 (which is already ACK'd), so 0058 needs >to be merged before this patch (0056). Right. There is one small fix that need to be squashed prior to committing as pylint cannot get insights into function states. The patch attached. With it, ACK. -- / Alexander Bokovoy -------------- next part -------------- >From b1e75c884fd5303dce038e4f3dc6158d93785671 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 26 Jun 2014 13:16:47 +0300 Subject: [PATCH 4/4] fixup! Add otptoken-sync command --- ipalib/plugins/otptoken.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index 46ad77a..7b9e256 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -394,7 +394,7 @@ class otptoken_remove_managedby(LDAPRemoveMember): class HTTPSConnection(httplib.HTTPConnection): "Generates an SSL HTTP connection that performs hostname validation." - ssl_kwargs = ssl.wrap_socket.func_code.co_varnames[1:ssl.wrap_socket.func_code.co_argcount] + ssl_kwargs = ssl.wrap_socket.func_code.co_varnames[1:ssl.wrap_socket.func_code.co_argcount] #pylint: disable=E1101 default_port = httplib.HTTPS_PORT def __init__(self, host, **kwargs): -- 1.9.3 From jcholast at redhat.com Thu Jun 26 11:36:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 13:36:26 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53995B8A.1090409@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> <5374E16D.9050509@redhat.com> <537BAF42.5060502@redhat.com> <53995B8A.1090409@redhat.com> Message-ID: <53AC05BA.6010903@redhat.com> On 12.6.2014 09:49, Jan Cholasta wrote: > On 20.5.2014 21:38, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 25.4.2014 10:51, Jan Cholasta wrote: >>>> On 24.4.2014 23:16, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>>>>> Some in-line, a whole ton of data appended to end. >>>>>>> >>>>>>> Jan Cholasta wrote: >>>>>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>>>>> Rob Crittenden wrote: >>>>>>>>>> >>>>>>>>>> 247 >>>>>>>>>> >>>>>>>>>> We've been burned by hardcoded timeouts in the past. Should >>>>>>>>>> this be >>>>>>>>>> configurable? This module doesn't currently do any logging but it >>>>>>>>>> might >>>>>>>>>> be worth spitting out a "waiting" message, at least for >>>>>>>>>> debugging. >>>>>>>> >>>>>>>> Added a timeout argument. >>>>>>> >>>>>>> Did you forget to send this one, I didn't see an update to 247. >>>>>> >>>>>> Are you sure you have 247.1 (now 247.2)? >>>>>> >>>>>> I can see at >>>>>> >>>>>> >>>>>> that I have sent the correct version of the patches. >>>>> >>>>> The call has a timeout, the callers don't use it. I guess it'll do for >>>>> now, but these almost always come back to bite us. >>>> >>>> Well, I can add --certmonger-timeout option to ipa-cacert-manage, if >>>> that's what you want. >>>> >>>>> >>>>>> >>>>>>>>>> >>>>>>>>>> 251 >>>>>>>>>> >>>>>>>>>> The tool should provide some feedback while it's running. For the >>>>>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>>>>> what is >>>>>>>>>> going on, something in between nothing and full debug output. >>>>>>>> >>>>>>>> Added some messages about what's going on. >>>>>>> >>>>>>> I dpn't see an update to 251 either. >>>>>> >>>>>> Please make sure you have 251.1 (now 251.2). >>>>> >>>>> There is a little bit more output but there are still very long >>>>> periods >>>>> of waiting between any visual activity, particularly when doing it >>>>> on an >>>>> IPA self-signed CA. >>>> >>>> This stuff takes time :-) What would you like to see in the output, >>>> that's not already there? >>>> >>>>>>> >>>>>>> I think the ipa-cacert-manage man page is missing one really >>>>>>> important >>>>>>> piece: why would you ever need to run this? And when? >>>>>> >>>>>> Added a paragraph about this. >>>>> >>>>> It's better, couple of comments: >>>>> >>>>> Add "the" in between renew and CA in "used to manually renew CA >>>>> certificate of" and "When IPA CA...". >>>> >>>> OK. >>>> >>>>> I haven't had any luck renewing >>>>> the CA certificate yet. I see that it is tracked now. I started moving >>>>> the system clock forward in order to get to renewal and about the 3rd >>>>> iteration the requests started failing with an XML error. Did you see >>>>> this? >>>>> >>>>> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most >>>>> recent call last): >>>>> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>>>> 344, in >>>>> wsgi_execute >>>>> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >>>>> self.Command[name](*args, **options) >>>>> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>> __call__ >>>>> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >>>>> self.run(*args, **options) >>>>> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>> run >>>>> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >>>>> self.execute(*args, **options) >>>>> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>> 382, in >>>>> execute >>>>> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >>>>> api.Command['cert_show'](unicode(serial))['result'] >>>>> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>> __call__ >>>>> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >>>>> self.run(*args, **options) >>>>> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>> run >>>>> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >>>>> self.execute(*args, **options) >>>>> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>> 514, in >>>>> execute >>>>> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >>>>> result=self.Backend.ra.get_certificate(serial_number) >>>>> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>> 1502, in get_certificate >>>>> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] >>>>> parse_result >>>>> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >>>>> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>> 1363, in get_parse_result_xml >>>>> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >>>>> etree.fromstring(xml_text, parser) >>>>> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >>>>> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >>>>> (src/lxml/lxml.etree.c:68129) >>>>> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >>>>> (src/lxml/lxml.etree.c:102493) >>>>> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 1673, in lxml.etree._parseDoc >>>>> (src/lxml/lxml.etree.c:101322) >>>>> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >>>>> (src/lxml/lxml.etree.c:96504) >>>>> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 582, in >>>>> lxml.etree._ParserContext._handleParseResultDoc >>>>> (src/lxml/lxml.etree.c:91308) >>>>> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 683, in lxml.etree._handleParseResult >>>>> (src/lxml/lxml.etree.c:92494) >>>>> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >>>>> "parser.pxi", line 633, in lxml.etree._raiseParseError >>>>> (src/lxml/lxml.etree.c:91957) >>>>> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: >>>>> None >>>>> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >>>>> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >>>>> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm! 8! >>>>> > V! >> P! >>>>> >>> Z! >>>>> >>>> gm! >>>>> >>>>> 3VCtgMvPVk >>>>> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >>>>> >>>>> >>>>> >>>>> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >>>>> version=u'2.51'): XMLSyntaxError >>>> >>>> I have never seen this. The error message does not say much... Is there >>>> anything interesting in other logs? >>> >>> I was able to get the CA certificate to be renewed after moving system >>> time forward step by step. >>> >>> One thing I haven't noticed before is that the renewed certificate's >>> validity never exceeds that of the original certificate. This is most >>> likely Dogtag issue (something along the lines of "certificate validity >>> cannot exceed validity of the CA certificate", except it shouldn't apply >>> to the CA certificate itself). >>> >>> There were other issues here and there, all of them were caused by race >>> conditions between concurrent renewals (unreachable CA, XML syntax >>> errors, etc. because Dogtag was stopped by stop_pkicad in another >>> request, CMS internal error because it used old subsystem cert to >>> authenticate to LDAP while the cert was being renewed, etc.) and all of >>> them could be fixed by restarting relevant IPA services and resubmitting >>> the requests manually. Some synchronization is really missing there. >> >> I hadn't noticed that, but my CA was issued externally so I expected >> this. I also saw the bumps during renewal but things always tended to >> smooth out, with the errors generally restricted to restarts and >> certmonger. This backtrace was the only thing that really stood out. >> IIRC at this point things were pretty much blocked. >> >> In any case, these patches basically seem to work. I never did work out >> whether the above error was due to dogtag, IPA or something else. >> >> rob > > Rebased the patches on top of current master. > > Give up retrieving certificate from LDAP in patch 265 after a few > unsuccessful attempts. This is to prevent certmonger requests from > staying in CA_WORKING state forever when you manually resubmit a request. > > Added patch 266 which adds ACIs missing after the permission refactoring. Rebased again. Converted all permissions to managed permissions. Added dependency on certmonger >= 0.74 in patch 251, because CSR export is broken with older versions. There is an update to certmonger 0.75.5 for F20: . (It segfaults for me during server install, I and Nalin are investigating.) -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.4-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.4-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.4-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.4-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.4-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.4-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.4-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.4-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.4-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.4-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.4-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.4-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.4-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.3-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.2-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.2-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.2-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.1-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: From jcholast at redhat.com Thu Jun 26 11:39:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 13:39:26 +0200 Subject: [Freeipa-devel] [PATCH] 302 Do not corrupt sshd_config in client install when trailing newline is missing In-Reply-To: <53ABF943.8020405@redhat.com> References: <53A19A94.7010504@redhat.com> <53ABF376.3010602@redhat.com> <53ABF943.8020405@redhat.com> Message-ID: <53AC066E.9030704@redhat.com> On 26.6.2014 12:43, Petr Viktorin wrote: > On 06/26/2014 12:18 PM, Martin Kosek wrote: >> On 06/18/2014 03:56 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Works fine, tested with >> # perl -i -pe 'chomp if eof' /etc/ssh/sshd_config >> trick. >> >> ACK, pushed to master. >> >> Martin >> > > It would be really nice to have some tests for this function. > It would be even nicer to use Augeas to handle this. -- Jan Cholasta From pvoborni at redhat.com Thu Jun 26 11:57:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Jun 2014 13:57:30 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSEC: Add TLSA record In-Reply-To: <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> Message-ID: <53AC0AAA.1090403@redhat.com> On 25.6.2014 14:35, Martin Basti wrote: > On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: >> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 >> Patches attached. >> >> Note: ACI will be updated in another patch which fix ACIs in DNS plugin > > Patches are here > What are patch 0078's dependencies? I'm missing necessary blobs.. (current master). Also it requires rebase because of today's pushes to master (VERSION conflict). -- Petr Vobornik From abokovoy at redhat.com Thu Jun 26 12:33:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Jun 2014 15:33:02 +0300 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <53ABDBD6.7060800@redhat.com> References: <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> Message-ID: <20140626123302.GO7233@redhat.com> On Thu, 26 Jun 2014, Martin Kosek wrote: >On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: >> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: >>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: >>>> ----- Original Message ----- >>>>> ----- Original Message ----- >>>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the >>>>>>> base tree object ? >>>>>>> It should be there as excluded, and that should cause admin to not be >>>>>>> able to retrieve keytabs. >>>>>> >>>>>> It was not. While running ipa-ldap-updater I got the following: >>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= >>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are >>>>>> allowed to rekey any entity\22; allow(write) groupdn = >>>>>> \22ldap:///cn=admins: Invalid syntax. >>>>> >>>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks >>>>> just like the one I replace, Ideas ? >>>>> Do you have ipaProtectedOperation in the schema ? >>>>> >>>>> (I rebased patch 3 but will wait to send a patchset until we understand (and >>>>> fix) why this is failing to update. >>>> >>>> Ok, apparently it was a quoting issue in the .update files, hopefully that's >>>> the only issue (I am at a conference today and do not have my test env. handy). >>>> >>>> The attached patches are rebased on the latest master. >>> >>> 0001: Line 555 has very wrong indentation. >>> >>> I don't see anything else wrong in the other patches. I've tested >>> everything and it works as designed. >>> >>> I have CC'd everyone who was involved with review at any point on these >>> patches. This serves as my public notice that I'd like to ACK the next >>> round of patches. If anyone has anything else to add, please do it >>> before tomorrow evening. Thanks! >>> >>> Nathaniel >> >> ACK >> >> Nathaniel > >Pushed all 6 patches to master. Thanks for careful review! Unfortunately, at least enctype marshalling is wrong with these patches. Samba does not work anymore with the keytab fetched in new version. We see following in the keytab: Keytab name: FILE:/etc/samba/samba.keytab KVNO Timestamp Principal ---- ------------------------------------------------------------------------- 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 274) 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 273) 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 272) 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 279) Note that etype is unresolvable. In the build without these patches we get something like 1 06/23/2014 16:28:59 cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (aes256-cts-hmac-sha1-96) So this patchset needs an improvement before release. -- / Alexander Bokovoy From tbabej at redhat.com Thu Jun 26 12:55:40 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Jun 2014 14:55:40 +0200 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <20140626123302.GO7233@redhat.com> References: <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> <20140626123302.GO7233@redhat.com> Message-ID: <53AC184C.2090100@redhat.com> On 06/26/2014 02:33 PM, Alexander Bokovoy wrote: > On Thu, 26 Jun 2014, Martin Kosek wrote: >> On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: >>> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: >>>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: >>>>> ----- Original Message ----- >>>>>> ----- Original Message ----- >>>>>>>> Can you check if ipaProtectedOperation is in the aci attribute >>>>>>>> in the >>>>>>>> base tree object ? >>>>>>>> It should be there as excluded, and that should cause admin to >>>>>>>> not be >>>>>>>> able to retrieve keytabs. >>>>>>> >>>>>>> It was not. While running ipa-ldap-updater I got the following: >>>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= >>>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl >>>>>>> \22Admins are >>>>>>> allowed to rekey any entity\22; allow(write) groupdn = >>>>>>> \22ldap:///cn=admins: Invalid syntax. >>>>>> >>>>>> Uhmm I do not see anything obviously wrong with ACI instruction, >>>>>> it looks >>>>>> just like the one I replace, Ideas ? >>>>>> Do you have ipaProtectedOperation in the schema ? >>>>>> >>>>>> (I rebased patch 3 but will wait to send a patchset until we >>>>>> understand (and >>>>>> fix) why this is failing to update. >>>>> >>>>> Ok, apparently it was a quoting issue in the .update files, >>>>> hopefully that's >>>>> the only issue (I am at a conference today and do not have my test >>>>> env. handy). >>>>> >>>>> The attached patches are rebased on the latest master. >>>> >>>> 0001: Line 555 has very wrong indentation. >>>> >>>> I don't see anything else wrong in the other patches. I've tested >>>> everything and it works as designed. >>>> >>>> I have CC'd everyone who was involved with review at any point on >>>> these >>>> patches. This serves as my public notice that I'd like to ACK the next >>>> round of patches. If anyone has anything else to add, please do it >>>> before tomorrow evening. Thanks! >>>> >>>> Nathaniel >>> >>> ACK >>> >>> Nathaniel >> >> Pushed all 6 patches to master. Thanks for careful review! > > Unfortunately, at least enctype marshalling is wrong with these patches. > Samba does not work anymore with the keytab fetched in new version. > > We see following in the keytab: > Keytab name: FILE:/etc/samba/samba.keytab > KVNO Timestamp Principal > ---- > ------------------------------------------------------------------------- > 1 06/26/2014 13:03:01 > cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > (etype 274) 1 06/26/2014 13:03:01 > cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > (etype 273) 1 06/26/2014 13:03:01 > cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > (etype 272) 1 06/26/2014 13:03:01 > cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > (etype 279) > Note that etype is unresolvable. In the build without these patches we > get something like > 1 06/23/2014 16:28:59 > cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > (aes256-cts-hmac-sha1-96) > So this patchset needs an improvement before release. FYI: I filed https://fedorahosted.org/freeipa/ticket/4404 , setting up this as blocker. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From jcholast at redhat.com Thu Jun 26 13:42:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 15:42:26 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <53AAAED7.7070705@redhat.com> References: <5399E749.6070806@redhat.com> <539F0593.9060007@redhat.com> <539F5552.9070005@redhat.com> <53AAAED7.7070705@redhat.com> Message-ID: <53AC2342.9030101@redhat.com> On 25.6.2014 13:13, Jan Cholasta wrote: > On 16.6.2014 22:36, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches implement >>>> and >>>> . >>>> >>>> This work depends on my patches 241-253 and 262-266 >>>> (). >>>> >>>> >>>> Note that automatic distribution of CA certificates to IPA systems is >>>> not implemented yet (it's planned for IPA 4.2, see >>>> ), so /etc/ipa/ca.crt, >>>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are >>>> updated >>>> *only* during client/server install. >>> >>> 267 >>> >>> What is the purpose of this change? Won't this cause no certificates to >>> be exported in the default case? >>> >>> diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py >>> index 61a954f..3cd7a53 100644 >>> --- a/ipaserver/install/certs.py >>> +++ b/ipaserver/install/certs.py >>> @@ -463,7 +463,7 @@ class CertDB(object): >>> do that step.""" >>> # export the CA cert for use with other apps >>> ipautil.backup_file(self.cacert_fname) >>> - root_nicknames = self.find_root_cert(nickname) >>> + root_nicknames = self.find_root_cert(nickname)[:-1] >>> fd = open(self.cacert_fname, "w") >>> for root in root_nicknames: >>> (cert, stderr, returncode) = self.run_certutil(["-L", >>> "-n", >>> root, "-a"]) >>> >>> Or are you separating out issuing CA from the rest of the chain? > > find_root_cert() returns the certificate chain *including* the > end-entity certificate. We want only CA certificates here. This is an > error introduced in the CA-less rewrite. > >>> >>> 268 ACK >>> >>> 269 ACK >>> >>> 270 >>> >>> If a user has their own CA installed, such as the case where they used >>> ipa-server-certinstall, this will break it. > > You can't install own CA with ipa-server-certinstall. I did not see > anything break. > >>> >>> What can be in the other set? Docs are needed. > > The "trusted" set is for trusted CA certs and the "other" set is for > other CA certs. I will add a comment... > >>> >>> You potentially add a bunch of certs with no trust, what is the purpose? > > "No trust" in this context means "trust only for issuing CA > certificates". The certs are there for the sole purpose of forming the > CA chain, so they don't need to be trusted for anything else. > >>> >>> 271 >>> >>> ipaSecretKey isn't mentioned on >>> http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and >>> does it need to be added now? > > This is the schema from > . > It is shared with DNSSEC. I will add a comment. > >>> >>> 272 ACK >>> >>> 273 ACK >>> >>> 274 ACK >>> >>> 275 ACK >>> >>> 276 >>> >>> There isn't any error handling around the ASN.1 decoder. Is that wise? > > Probably not, but it's consistent with the rest of the x509 module - > none of its functions do error handling, it is up to the caller. > > BTW I have started refactoring x509 code, but didn't have time to > finish. The new code will include error handling. > >>> >>> There should be unit tests > > Yes. > >>> >>> 277 >>> >>> There should be unit tests > > Yes. > >>> >>> 278 >>> >>> When the certificate must be passed in as DER can you use dercert as the >>> argument name so it's clear what is needed? > > OK. > >>> >>> In update_ca_cert() and get_ca_certs() should the values for trust be >>> case insensitive? > > It already is in update_ca_cert(), but get_ca_certs() does indeed need > to be fixed. > >>> >>> This breaks the convention where attribute names are always lower-case. > > I wasn't aware there is such a convention, especially so after seeing > loads of mixed case attribute names all over IPA code. > > Anyway, I don't think it matters anymore, the new LDAP code has > case-insensitive attribute names. > >>> >>> I can't really grok add_ca_cert(). You are adding certs but removing >>> values? Is this un-setting the list of trusted CA's maybe? > > It is unsetting ipaConfigString values from entries that should no > longer have them. I will add a comment. > >>> >>> There isn't a single comment in this file beyond the header. > > Sorry, will fix. > >>> >>> 279 >>> >>> Looks ok >>> >>> 280 >>> >>> Why add the chain with no trust? > > See my comment for patch 270. > >>> >>> 281 / 282 >>> >>> What is the difference between add_cert and import_cert other than >>> passing in trust and not having the db password? Do we even need >>> add_single_pem_cert anymore? > > add_cert adds certificate by value, import_cert loads it from a file. We > don't need add_single_pem_cert anymore. > >>> >>> 283 / 284 >>> >>> In __import_ca_certs() I assume the pass is there for NotFound for the >>> case of creating a replica with an older master that doesn't have these? >>> How is SSL trust setup then? > > It is for the case where there is no cn=certificates nor cn=CAcert. The > trust is setup as usual, failed import does not affect it. > >>> >>> This code looks awfully similar. > > Will fix. > >>> >>> 285 >>> >>> ACK >>> >>> 286 >>> >>> It looks ok, just one wild thought. If writing the certificate fails and >>> you go to clean up by removing ca_file, what if that removal fails, for >>> the same reason the write failed, SELinux for example? > > Good point, will fix. > >>> >>> 287 >>> >>> If this weren't addressed in a later patch I've have dinged you on the: >>> >>> + return [cert] >>> >>> There are some places where you pluralize the variables (certs) and >>> others where you do not (ca_cert, existing_ca_cert). > > Right, will fix. > >>> >>> 288 >>> >>> Is a rawcert a dercert? I'd use that name instead for consistency. > > It can be both DER or PEM, I used it for consistency with > write_certificate(). > >>> >>> normalize_certificate() can raise exceptions. Those should be handled in >>> write_certificate_list() > > Actually they should be handled by the caller, the same way as with > write_certificate(). (See my comment for patch 276.) > >>> >>> 289 >>> >>> ACK >>> >>> 290 >>> >>> This can be dangerous because if another database is opened in the >>> process things may fail. Additional warnings and red flags should be >>> provided, or the context should be compared to known places this will >>> blow up (e.g server). > > This is used only in ipa-client-install (in patch 291) and it does not > blow up. > >>> >>> 291 >>> >>> You use a temporary database to make cleanup easier I suppose? Did you >>> test this in enforcing? > > Yes, it works fine. > >>> >>> 292 >>> >>> Need unit tests > > OK. > >>> >>> 293 >>> >>> Why the fixme for the x509 import? > > Because it's import from ipalib to ipapython. > >>> >>> Isn't this changing already published API for >>> [insert|remove]_ca_cert_into_systemwide_ca_store? > > Yes. I don't think this is a public API and it is changed in Tom??'s > platform code refactoring anyway. > >>> >>> 294 >>> >>> Can you change the old occurances of >>> >>> cafile = config.dir + "/ca.crt" >>> >>> to use CACERT instead? > > No, config.dir is the directory where the replica info is unpacked, not > "/etc/ipa". > >>> >>> Bad case in exception, "Ca cert file is not available". Is there any >>> additional information we can provide, like what to do about it and >>> where we looked? > > Maybe. This code is cut-and-pasted from install_ca_cert(), I did not > touch it otherwise. > >>> >>> You actually remove one occurrence of CACERT and replace it with a >>> hardcoded path, is that on purpose? > > Yes. Currently, the CA certificate from the replica info is copied > directly to /etc/ipa/ca.crt, but I want to use it only for connecting to > LDAP and use whatever is in there to create /etc/ipa/ca.crt. > >>> >>> --- >>> >>> I still need to do functional testing and will probably take another >>> pass the changes through but this patchset generally looks ok. >> >> Several issues found during testing: >> >> 1. Enrollment from RHEL-5 fails because the entire cert chain is not >> retrieved, only the issuing CA cert. >> >> Joining realm failed: libcurl failed to execute the HTTP POST >> transaction. SSL certificate problem, verify that the CA cert is OK. >> Details: >> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >> verify failed >> Installation failed. Rolling back changes. > > I couldn't reproduce this, I have the full certificate chain in > http:///ipa/config/ca.crt. > >> >> 2. Not quite sure the cause, but this is on a replica: >> >> # ldapsearch -x -Z >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> ldap_start_tls: Operations error (1) >> additional info: SSL connection already established. >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: (objectclass=*) >> >> Same command on initial master doesn't spit out the p11-kit errors. >> >> Get similar errors out of certutil: >> >> # certutil -L -d /etc/httpd/alias >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> GREYOAK.COM IPA CA CT,C,C >> Server-Cert u,u,u >> CN=External Authority ,, >> ipaCert u,u,u >> >> Same version of p11-kit on both machines. >> >> p11-kit-trust-0.20.2-1.fc20.x86_64 >> p11-kit-0.20.2-1.fc20.x86_64 > > This does not happen for me. I don't touch basic constraints anywhere in > the code. Can I see the "CN=External Authority" certificate? > >> >> 3. On uninstall the CA's are not removed from /etc/pki/nssdb and >> /etc/httpd/alias in one of my tests (the first one, so I no longer have >> the logs). > > Will fix. > >> >> 4. This one isn't your issue AFAICT, not sure if you've seen this one: >> >> # ipa-ca-install ... >> >> [snip] >> >> 2014-06-16T18:07:44Z DEBUG stdout=Loading deployment configuration from >> /tmp/tmprI2isq. >> >> 2014-06-16T18:07:44Z DEBUG stderr=Traceback (most recent call last): >> File "/usr/sbin/pkispawn", line 530, in >> main(sys.argv) >> File "/usr/sbin/pkispawn", line 439, in main >> info = parser.sd_get_info() >> File >> "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", >> line 442, in sd_get_info >> info = sd.getSecurityDomainInfo() >> File "/usr/lib/python2.7/site-packages/pki/system.py", line 40, in >> getSecurityDomainInfo >> info.name = j['DomainInfo']['@id'] >> KeyError: 'DomainInfo' >> >> 2014-06-16T18:07:44Z CRITICAL failed to configure ca instance Command >> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmprI2isq'' returned non-zero >> exit status 1 >> 2014-06-16T18:07:44Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 639, in run_script >> return_value = main_function() > > I haven't seen this one. Can it be reproduced? > >> >> 5. This one may be for Tomas, but: >> >> 2014-06-16T19:01:28Z INFO Deleting schedule 2358-2359 0 from agreement >> cn=meTogrindle.greyoak.com,cn=replica,cn=dc\=greyoak\,dc\=com,cn=mapping >> tree,cn=config >> 2014-06-16T19:01:29Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:29Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:30Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:30Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:31Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:31Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:32Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:32Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 > > I believe this is . > >> >> 6. With an external CA install of F-20 vanilla, upgraded to this patch, >> the external CA is not added to /etc/pki/nssdb. On a pure install of >> this patch, it is added. Not sure if we care since the cert is in the >> global cert store. > > Yes, that's one of the effects of "automatic distribution to clients is > not implemented yet". > >> >> 7. Something for the future, but I wonder if test test_0002_find_CA in >> ipatests/test_xmlrpc/test_cert_plugin.py should be able to handle >> external CAs. >> >> rob >> > > Updated and rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.1-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.1-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.1-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.1-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 9990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.1-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 3709 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.1-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.1-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.1-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.1-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 13369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.1-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.1-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.1-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 14520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.1-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.1-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.1-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.1-Add-method-for-adding-certificates-by-value-to-NSSDa.patch Type: text/x-patch Size: 3420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.1-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.1-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.1-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.1-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.1-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.1-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 3612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.1-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.1-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.1-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.1-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.1-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.1-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3231 bytes Desc: not available URL: From jcholast at redhat.com Thu Jun 26 13:48:59 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Jun 2014 15:48:59 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <539EF2A1.6060706@redhat.com> References: <539EF2A1.6060706@redhat.com> Message-ID: <53AC24CB.607@redhat.com> On 16.6.2014 15:35, Jan Cholasta wrote: > Hi, > > the attached patches implement > . > > My patches 241-253 and 262-294 are required for this > (, > ). > > The installation/testing guidelines from > > apply here as well. > > Honza Rebased on top of current master. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.1-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296.1-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 5791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297.1-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3067 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298.1-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299.1-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 14029 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 26 13:57:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 15:57:02 +0200 Subject: [Freeipa-devel] [PATCH 0055] Add /session/token_sync POST support In-Reply-To: <20140626110120.GM7233@redhat.com> References: <1401764823.4161.4.camel@ipa.example.com> <1403641921.3523.2.camel@ipa.example.com> <20140625102139.GE7233@redhat.com> <1403728331.3523.20.camel@ipa.example.com> <20140626110120.GM7233@redhat.com> Message-ID: <53AC26AE.9060700@redhat.com> On 06/26/2014 01:01 PM, Alexander Bokovoy wrote: > On Wed, 25 Jun 2014, Nathaniel McCallum wrote: >> On Wed, 2014-06-25 at 13:21 +0300, Alexander Bokovoy wrote: >>> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >>> >On Mon, 2014-06-02 at 23:07 -0400, Nathaniel McCallum wrote: >>> >> This HTTP call takes the following parameters: >>> >> * user >>> >> * password >>> >> * first_code >>> >> * second_code >>> >> * token (optional) >>> >> >>> >> Using this information, the server will perform token synchronization. >>> >> If the token is not specified, all tokens will be searched for >>> >> synchronization. >>> >> Otherwise, only the token specified will be searched. >>> >> >>> >> This patch depends on my patch #0054. >>> > >>> >Attached is a new revision. This version should force an update >>> >to /etc/httpd/conf.d/ipa.conf on update. It is also rebased on master. >>> ACK with condition that you apply attached fixups. >>> >>> Since token that is passed by 'ipa otptoken-sync' command is not a full >>> DN, we need to support both cases, when DN and just a name is passed. >>> Attached patch fixes this. >> >> Applied. > ACK. This should be committed first one. Pushed to master. I just added link to https://fedorahosted.org/freeipa/ticket/4218 to the patch description. Martin From mkosek at redhat.com Thu Jun 26 14:11:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 16:11:32 +0200 Subject: [Freeipa-devel] [PATCH 0058] Add the otptoken-add-yubikey command In-Reply-To: <1403704392.3523.13.camel@ipa.example.com> References: <1403209851.6477.25.camel@ipa.example.com> <1403279219.4808.1.camel@ipa.example.com> <20140623072939.GV7233@redhat.com> <1403557986.3263.7.camel@ipa.example.com> <20140625103511.GF7233@redhat.com> <1403704392.3523.13.camel@ipa.example.com> Message-ID: <53AC2A14.9030005@redhat.com> On 06/25/2014 03:53 PM, Nathaniel McCallum wrote: > On Wed, 2014-06-25 at 13:35 +0300, Alexander Bokovoy wrote: >> On Mon, 23 Jun 2014, Nathaniel McCallum wrote: >>> On Mon, 2014-06-23 at 10:29 +0300, Alexander Bokovoy wrote: >>>> On Fri, 20 Jun 2014, Nathaniel McCallum wrote: >>>>> On Thu, 2014-06-19 at 16:30 -0400, Nathaniel McCallum wrote: >>>>>> This command behaves almost exactly like otptoken-add except: >>>>>> 1. The new token data is written directly to a YubiKey >>>>>> 2. The vendor/model/serial fields are populated from the YubiKey >>>>>> >>>>>> === NOTE === >>>>>> 1. This patch depends on the new Fedora package: python-yubico. If you >>>>>> would like to help with the package review, please assign yourself here: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1111334 >>>>> >>>>> New version of the patch. This one works (yay!). >>>>> >>>>> 1. Because of the dependency on python-yubico, is this feature something >>>>> we want in core FreeIPA? As a subpackage? Separate project altogether? >>>>> The only dependency for python-yubico is pyusb. >>>> I'd prefer to have it integrated but have a separate dummy subpackage >>>> that pulls in all required dependencies, like, freeipa-tools-yubico. Instead >>>> of failing when 'ipa otptoken-add-yubikey' is called, please wrap the >>>> python-yubico import into a code that allows reporting a message back to >>>> the user advising to install the package. >>>> >>>> Who is a supposed user for this command? IPA command line interface isn't >>>> usually available on enrolled machines even though underlying Python >>>> modules are all there. Are we talking about admins or just users? >>> >>> As discussed on IRC, we are currently hard-coding lots of optional >>> dependencies. And breaking this apart into subpackages can be solved at >>> a later point. YubiKey is also a unique case: we don't expect to be >>> adding many more plugins like this. >>> >>> For these reasons, I have kept this as a hard dependency. To ease this >>> transition, I have added python-yubico to F20 and EL6. You can help with >>> the update review here: >>> https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.fc20 >>> https://admin.fedoraproject.org/updates/python-yubico-1.2.1-3.el6 >>> >>>>> 3. This code currently emits a warning from the call to otptoken-add: >>>>> WARNING: API Version number was not sent, forward compatibility not >>>>> guaranteed. Assuming server's API version, 2.89 >>>>> >>>>> How do I fix this? >>>> Do not filter 'version' field in options in execute(). >>> >>> I opted to not filter out version rather than hard-code it (pviktori's >>> suggestion). This is based on the fact that otptoken-add-yubikey is >>> tightly integrated with otptoken-add (even using some of the class >>> attributes from otptoken). >>> >>>>> 4. I am not sure why I have to delete the summary and value keys from >>>>> the return dictionary. It would be nice to display this summary message >>>>> just like otptoken-add. >>> >>> I still need help on this. >>> >>>>> 5. Am I doing the ipatoken(vendor|model|serial) options correctly? These >>>>> aren't user settable, but we need to pass them from the yubikey >>>>> (client-side) to the server. >>> >>> This is no longer needed since I am doing everything in forward(). >>> However, listing these three as output params causes them to appear >>> before the token's ID. I don't think this is the right way to output >>> these. But this seems to me a framework issue. >>> >>>>> 6. I'm not sure my use of assert or ValueError are correct. What should >>>>> I do here? >>> >>> Still need help here. >> Fixed this part. >> >>> >>>>> 7. Considering that this is just a specialized invocation of >>>>> otptoken-add, can't we do this all on the client-side? This is why I had >>>>> originally used frontend.Local rather than frontend.Command. >>>> You don't need to implement execute then, only forward, where you'll >>>> forward your call to the server under otptoken_add name. >>>> >>>> Typically in #forward we call super's forward but that is because we >>>> in Command.forward() we simply forward the command to the remote backend, >>>> using the self.name. In your case we shouldn't really have a separate >>>> command on the server under the same name, so you'll need to avoid >>>> calling >>>> >>>> So, it should look like this: >>>> >>>> def forward(self, *args, **kw): >>>> perform yubikey initialization >>>> filter out kw and args, if needed >>>> return self.Backend.rpcclient.forward('otptoken_add', *args, **kw) >>>> >>>> See service_show implementation for an example. >>> >>> Fixed. >> I'm attaching few fixups to the patch that make it proper reporting for >> non-Yubikey case and also properly update VERSION. >> >> Provisional ACK. > > Merged. > > Nathaniel There was a conflict on VERSION (thanks, Petr!) and API.txt was not regenerated. I fixed both and pushed to master. Martin From pvoborni at redhat.com Thu Jun 26 14:11:37 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Jun 2014 16:11:37 +0200 Subject: [Freeipa-devel] [PATCH] 683-690 webui: OTP token sync Message-ID: <53AC2A19.5000805@redhat.com> This set of patches creates page(s) for OTP Token Sync. there are two options: 1. from login page by "Sync OTP Token" link. - user can navigate between those two pages 2. standalone page on `ipa/ui/sync_otp.html` which is not linked to UI and can be used separately. Both share the same code. All dependencies should be in master. This implements only ticket: https://fedorahosted.org/freeipa/ticket/4218 Sync by authenticated user will be implemented later in tickets: https://fedorahosted.org/freeipa/ticket/4365 https://fedorahosted.org/freeipa/ticket/4366 Patch descriptions: == [PATCH] 683 webui: base class for LoginScreen-like facets == LoginScreen has layout which can be reused for other facets/widgets, e.g. for Sync OTP facet == [PATCH] 684 webui: add OTP token synchronization == New SyncOTPScreen widget and related facet == [PATCH] 685 webui: add link pointing to OTP sync page to login == == [PATCH] 686 webui: support global notifications in all containers == Global notifications were limited to "main" container. Now they have their own container which is displayed over other ones. It makes them usable everywhere. == [PATCH] 687 webui: bind Login facet and OTP sync facet == Simple plugin which handles transition from login facet to OTP sync facet and vice versa. == [PATCH] 688 webui: fix confirmation mixin origin check == Current check is not enough. == [PATCH] 689 webui: layer for standalone pages which use WebUI framework == Current compiled Web UI layer (app.js) contains every FreeIPA plugin and not just the UI framework. It's not possible to start just a simple facet. This commit creates a basis for a layer (core.js) which contains only framework code and not entity related code. == [PATCH] 690 webui: add sync_otp.html == standalone page for OTP token synchronization. It reuses SyncOTPScreen widget instead of reimplementing the logic as in other standalone pages. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0690-webui-add-sync_otp.html.patch Type: text/x-patch Size: 3752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0689-webui-layer-for-standalone-pages-which-use-WebUI-fra.patch Type: text/x-patch Size: 7959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0688-webui-fix-confirmation-mixin-origin-check.patch Type: text/x-patch Size: 1669 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0687-webui-bind-Login-facet-and-OTP-sync-facet.patch Type: text/x-patch Size: 4574 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0686-webui-support-global-notifications-in-all-containers.patch Type: text/x-patch Size: 2963 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0685-webui-add-link-pointing-to-OTP-sync-page-to-login.patch Type: text/x-patch Size: 3951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0684-webui-add-OTP-token-synchronization.patch Type: text/x-patch Size: 16877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0683-webui-base-class-for-LoginScreen-like-facets.patch Type: text/x-patch Size: 22866 bytes Desc: not available URL: From pvoborni at redhat.com Thu Jun 26 14:15:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Jun 2014 16:15:15 +0200 Subject: [Freeipa-devel] [PATCH] 691 webui-ci: fix action list action visibility and enablement assertion Message-ID: <53AC2AF3.6020701@redhat.com> Fixes CA-less CI test fail The new html structure was not addressed properly. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0691-webui-ci-fix-action-list-action-visibility-and-enabl.patch Type: text/x-patch Size: 1686 bytes Desc: not available URL: From mkosek at redhat.com Thu Jun 26 14:16:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Jun 2014 16:16:08 +0200 Subject: [Freeipa-devel] [PATCH 0056] Add otptoken-sync command In-Reply-To: <20140626110244.GN7233@redhat.com> References: <1401764897.4161.6.camel@ipa.example.com> <538D86E4.5050605@redhat.com> <1401801502.4161.7.camel@ipa.example.com> <1403643460.3523.5.camel@ipa.example.com> <20140625101837.GD7233@redhat.com> <1403728418.3523.21.camel@ipa.example.com> <20140626110244.GN7233@redhat.com> Message-ID: <53AC2B28.50707@redhat.com> On 06/26/2014 01:02 PM, Alexander Bokovoy wrote: > On Wed, 25 Jun 2014, Nathaniel McCallum wrote: >> On Wed, 2014-06-25 at 13:18 +0300, Alexander Bokovoy wrote: >>> On Tue, 24 Jun 2014, Nathaniel McCallum wrote: >>> >On Tue, 2014-06-03 at 09:18 -0400, Nathaniel McCallum wrote: >>> >> On Tue, 2014-06-03 at 10:27 +0200, Petr Vobornik wrote: >>> >> > On 3.6.2014 05:08, Nathaniel McCallum wrote: >>> >> > > This command calls the token sync HTTP POST call in the server providing >>> >> > > the CLI interface to synchronization. >>> >> > > >>> >> > > https://fedorahosted.org/freeipa/ticket/4260 >>> >> > > >>> >> > > This patch depends on my patch #0055. >>> >> > > >>> >> > >>> >> > Build fails on validation. You forgot to update API.txt and also the >>> >> > command misses __doc__. >>> >> > >>> >> > (not a proper review) >>> >> >>> >> Thanks, fixed. >>> > >>> >Attached is a new revision which is rebased on master. >>> > >>> >In addition it: >>> > >>> >1. Moves user to a parameter and moves token to an argument. Doing it >>> >this way both mirrors the existing otptoken APIs and sets us up for >>> >future Kerberos based syncing where the username/password will be >>> >optional. >>> > >>> >2. Converts the token ID to a DN. >>> ACK. >>> >>> Please do not commit this patch yet, we are not done with its >>> dependencies. >> >> As discussed off list, we also needed to verify the certificate so that >> passwords were not sent in the clear to a MITM. This has now been >> implemented. VERSION is bumped and ./makeapi was run. This patch is also >> rebased on top of my patch 0058 (which is already ACK'd), so 0058 needs >> to be merged before this patch (0056). > Right. There is one small fix that need to be squashed prior to > committing as pylint cannot get insights into function states. > > The patch attached. With it, ACK. Fixed VERSION conflict, squashed fixup patch and pushed to master. Martin From simo at redhat.com Thu Jun 26 14:20:29 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 26 Jun 2014 10:20:29 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <20140626123302.GO7233@redhat.com> References: <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> <20140626123302.GO7233@redhat.com> Message-ID: <1403792429.11352.44.camel@willson.usersys.redhat.com> On Thu, 2014-06-26 at 15:33 +0300, Alexander Bokovoy wrote: > On Thu, 26 Jun 2014, Martin Kosek wrote: > >On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: > >> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: > >>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: > >>>> ----- Original Message ----- > >>>>> ----- Original Message ----- > >>>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the > >>>>>>> base tree object ? > >>>>>>> It should be there as excluded, and that should cause admin to not be > >>>>>>> able to retrieve keytabs. > >>>>>> > >>>>>> It was not. While running ipa-ldap-updater I got the following: > >>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= > >>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > >>>>>> allowed to rekey any entity\22; allow(write) groupdn = > >>>>>> \22ldap:///cn=admins: Invalid syntax. > >>>>> > >>>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks > >>>>> just like the one I replace, Ideas ? > >>>>> Do you have ipaProtectedOperation in the schema ? > >>>>> > >>>>> (I rebased patch 3 but will wait to send a patchset until we understand (and > >>>>> fix) why this is failing to update. > >>>> > >>>> Ok, apparently it was a quoting issue in the .update files, hopefully that's > >>>> the only issue (I am at a conference today and do not have my test env. handy). > >>>> > >>>> The attached patches are rebased on the latest master. > >>> > >>> 0001: Line 555 has very wrong indentation. > >>> > >>> I don't see anything else wrong in the other patches. I've tested > >>> everything and it works as designed. > >>> > >>> I have CC'd everyone who was involved with review at any point on these > >>> patches. This serves as my public notice that I'd like to ACK the next > >>> round of patches. If anyone has anything else to add, please do it > >>> before tomorrow evening. Thanks! > >>> > >>> Nathaniel > >> > >> ACK > >> > >> Nathaniel > > > >Pushed all 6 patches to master. Thanks for careful review! > > Unfortunately, at least enctype marshalling is wrong with these patches. > Samba does not work anymore with the keytab fetched in new version. > > We see following in the keytab: > Keytab name: FILE:/etc/samba/samba.keytab > KVNO Timestamp Principal > ---- ------------------------------------------------------------------------- > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 274) > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 273) > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 272) > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 279) > > Note that etype is unresolvable. In the build without these patches we > get something like > 1 06/23/2014 16:28:59 cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (aes256-cts-hmac-sha1-96) > > So this patchset needs an improvement before release. Working on this. I know, roughly what's going on, but still trying to pinpoint exactly the offender. (It is the ber marshalling/unmarshalling indeed). Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jun 26 14:24:03 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jun 2014 10:24:03 -0400 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <53AAAED7.7070705@redhat.com> References: <5399E749.6070806@redhat.com> <539F0593.9060007@redhat.com> <539F5552.9070005@redhat.com> <53AAAED7.7070705@redhat.com> Message-ID: <53AC2D03.6050206@redhat.com> Comments buried deep inline. Jan Cholasta wrote: > On 16.6.2014 22:36, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches implement >>>> and >>>> . >>>> >>>> This work depends on my patches 241-253 and 262-266 >>>> (). >>>> >>>> >>>> Note that automatic distribution of CA certificates to IPA systems is >>>> not implemented yet (it's planned for IPA 4.2, see >>>> ), so /etc/ipa/ca.crt, >>>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are >>>> updated >>>> *only* during client/server install. >>> >>> 267 >>> >>> What is the purpose of this change? Won't this cause no certificates to >>> be exported in the default case? >>> >>> diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py >>> index 61a954f..3cd7a53 100644 >>> --- a/ipaserver/install/certs.py >>> +++ b/ipaserver/install/certs.py >>> @@ -463,7 +463,7 @@ class CertDB(object): >>> do that step.""" >>> # export the CA cert for use with other apps >>> ipautil.backup_file(self.cacert_fname) >>> - root_nicknames = self.find_root_cert(nickname) >>> + root_nicknames = self.find_root_cert(nickname)[:-1] >>> fd = open(self.cacert_fname, "w") >>> for root in root_nicknames: >>> (cert, stderr, returncode) = self.run_certutil(["-L", >>> "-n", >>> root, "-a"]) >>> >>> Or are you separating out issuing CA from the rest of the chain? > > find_root_cert() returns the certificate chain *including* the > end-entity certificate. We want only CA certificates here. This is an > error introduced in the CA-less rewrite. OK. > >>> >>> 268 ACK >>> >>> 269 ACK >>> >>> 270 >>> >>> If a user has their own CA installed, such as the case where they used >>> ipa-server-certinstall, this will break it. > > You can't install own CA with ipa-server-certinstall. I did not see > anything break. Sorry, I wasn't very clear. Imagine the case where the user has replaced the server certificate in Apache with something issued by some other CA that requires that some CA certificates also be installed. This is a not-too-common but seen scenario, mostly to avoid having to trust the IPA CA in browsers. The way I read fix_trust_flags() is that it would remove the trust from unknown CA's which could cause the server to not start. IMHO you should leave alone certs you don't know about. > >>> >>> What can be in the other set? Docs are needed. > > The "trusted" set is for trusted CA certs and the "other" set is for > other CA certs. I will add a comment... > >>> >>> You potentially add a bunch of certs with no trust, what is the purpose? > > "No trust" in this context means "trust only for issuing CA > certificates". The certs are there for the sole purpose of forming the > CA chain, so they don't need to be trusted for anything else. > >>> >>> 271 >>> >>> ipaSecretKey isn't mentioned on >>> http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and >>> does it need to be added now? > > This is the schema from > . > It is shared with DNSSEC. I will add a comment. > >>> >>> 272 ACK >>> >>> 273 ACK >>> >>> 274 ACK >>> >>> 275 ACK >>> >>> 276 >>> >>> There isn't any error handling around the ASN.1 decoder. Is that wise? > > Probably not, but it's consistent with the rest of the x509 module - > none of its functions do error handling, it is up to the caller. > > BTW I have started refactoring x509 code, but didn't have time to > finish. The new code will include error handling. Well, sure, but it isn't doing ASN.1 decoding of raw certs either. A lot can go wrong there. >>> >>> There should be unit tests > > Yes. > >>> >>> 277 >>> >>> There should be unit tests > > Yes. > >>> >>> 278 >>> >>> When the certificate must be passed in as DER can you use dercert as the >>> argument name so it's clear what is needed? > > OK. > >>> >>> In update_ca_cert() and get_ca_certs() should the values for trust be >>> case insensitive? > > It already is in update_ca_cert(), but get_ca_certs() does indeed need > to be fixed. > >>> >>> This breaks the convention where attribute names are always lower-case. > > I wasn't aware there is such a convention, especially so after seeing > loads of mixed case attribute names all over IPA code. > > Anyway, I don't think it matters anymore, the new LDAP code has > case-insensitive attribute names. Ok, I won't fight it, but look in ipalib/plugins. The majority of objectclasses/attributes are lower case. Anything otherwise was missed in review. > >>> >>> I can't really grok add_ca_cert(). You are adding certs but removing >>> values? Is this un-setting the list of trusted CA's maybe? > > It is unsetting ipaConfigString values from entries that should no > longer have them. I will add a comment. > >>> >>> There isn't a single comment in this file beyond the header. > > Sorry, will fix. > >>> >>> 279 >>> >>> Looks ok >>> >>> 280 >>> >>> Why add the chain with no trust? > > See my comment for patch 270. OK > >>> >>> 281 / 282 >>> >>> What is the difference between add_cert and import_cert other than >>> passing in trust and not having the db password? Do we even need >>> add_single_pem_cert anymore? > > add_cert adds certificate by value, import_cert loads it from a file. We > don't need add_single_pem_cert anymore. > >>> >>> 283 / 284 >>> >>> In __import_ca_certs() I assume the pass is there for NotFound for the >>> case of creating a replica with an older master that doesn't have these? >>> How is SSL trust setup then? > > It is for the case where there is no cn=certificates nor cn=CAcert. The > trust is setup as usual, failed import does not affect it. > >>> >>> This code looks awfully similar. > > Will fix. > >>> >>> 285 >>> >>> ACK >>> >>> 286 >>> >>> It looks ok, just one wild thought. If writing the certificate fails and >>> you go to clean up by removing ca_file, what if that removal fails, for >>> the same reason the write failed, SELinux for example? > > Good point, will fix. > >>> >>> 287 >>> >>> If this weren't addressed in a later patch I've have dinged you on the: >>> >>> + return [cert] >>> >>> There are some places where you pluralize the variables (certs) and >>> others where you do not (ca_cert, existing_ca_cert). > > Right, will fix. > >>> >>> 288 >>> >>> Is a rawcert a dercert? I'd use that name instead for consistency. > > It can be both DER or PEM, I used it for consistency with > write_certificate(). Ok. John was all over me long ago for using rather generic names for cert values with the contents being implicit. This is why there are type=PEM/DER options and explicit variable names. It does help a newcomer get a handle on what is going on without having to read a lot of extra code. >>> >>> normalize_certificate() can raise exceptions. Those should be handled in >>> write_certificate_list() > > Actually they should be handled by the caller, the same way as with > write_certificate(). (See my comment for patch 276.) Ok I guess, but only because install_ca_cert() is called so early in the replica install process. I suppose that missing a CA would be rather catastrophic and things need to stop, not super happy about catching broad Exception. >>> >>> 289 >>> >>> ACK >>> >>> 290 >>> >>> This can be dangerous because if another database is opened in the >>> process things may fail. Additional warnings and red flags should be >>> provided, or the context should be compared to known places this will >>> blow up (e.g server). > > This is used only in ipa-client-install (in patch 291) and it does not > blow up. Yes, I saw that too, but I think a comment should be added that this can be dangerous so some doesn't stumble upon this and try to use it in the future, at least not until we switch to using NSS contexts. >>> >>> 291 >>> >>> You use a temporary database to make cleanup easier I suppose? Did you >>> test this in enforcing? > > Yes, it works fine. Ok, wasn't sure what the contexts would be. >>> >>> 292 >>> >>> Need unit tests > > OK. > >>> >>> 293 >>> >>> Why the fixme for the x509 import? > > Because it's import from ipalib to ipapython. Ok, I guess I'd expand on it so it's more obvious. Is there a ticket open to move it to ipapython? >>> >>> Isn't this changing already published API for >>> [insert|remove]_ca_cert_into_systemwide_ca_store? > > Yes. I don't think this is a public API and it is changed in Tom??'s > platform code refactoring anyway. ok > >>> >>> 294 >>> >>> Can you change the old occurances of >>> >>> cafile = config.dir + "/ca.crt" >>> >>> to use CACERT instead? > > No, config.dir is the directory where the replica info is unpacked, not > "/etc/ipa". Ah right. Ok. > >>> >>> Bad case in exception, "Ca cert file is not available". Is there any >>> additional information we can provide, like what to do about it and >>> where we looked? > > Maybe. This code is cut-and-pasted from install_ca_cert(), I did not > touch it otherwise. Maybe fix both? >>> >>> You actually remove one occurrence of CACERT and replace it with a >>> hardcoded path, is that on purpose? > > Yes. Currently, the CA certificate from the replica info is copied > directly to /etc/ipa/ca.crt, but I want to use it only for connecting to > LDAP and use whatever is in there to create /etc/ipa/ca.crt. OK > >>> >>> --- >>> >>> I still need to do functional testing and will probably take another >>> pass the changes through but this patchset generally looks ok. >> >> Several issues found during testing: >> >> 1. Enrollment from RHEL-5 fails because the entire cert chain is not >> retrieved, only the issuing CA cert. >> >> Joining realm failed: libcurl failed to execute the HTTP POST >> transaction. SSL certificate problem, verify that the CA cert is OK. >> Details: >> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >> verify failed >> Installation failed. Rolling back changes. > > I couldn't reproduce this, I have the full certificate chain in > http:///ipa/config/ca.crt. > >> >> 2. Not quite sure the cause, but this is on a replica: >> >> # ldapsearch -x -Z >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> ldap_start_tls: Operations error (1) >> additional info: SSL connection already established. >> # extended LDIF >> # >> # LDAPv3 >> # base (default) with scope subtree >> # filter: (objectclass=*) >> >> Same command on initial master doesn't spit out the p11-kit errors. >> >> Get similar errors out of certutil: >> >> # certutil -L -d /etc/httpd/alias >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> p11-kit: invalid basic constraints certificate extension >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> GREYOAK.COM IPA CA CT,C,C >> Server-Cert u,u,u >> CN=External Authority ,, >> ipaCert u,u,u >> >> Same version of p11-kit on both machines. >> >> p11-kit-trust-0.20.2-1.fc20.x86_64 >> p11-kit-0.20.2-1.fc20.x86_64 > > This does not happen for me. I don't touch basic constraints anywhere in > the code. Can I see the "CN=External Authority" certificate? -----BEGIN CERTIFICATE----- MIIB5jCCAU+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMRswGQYDVQQDExJFeHRl cm5hbCBBdXRob3JpdHkwHhcNMTAwNDAxMTg0MDA1WhcNMTUwNDAxMTg0MDA1WjAd MRswGQYDVQQDExJFeHRlcm5hbCBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMU/XhUTSym+9O7emUkQ8ZAHz3wC+6q0QX+BmQTDPoorbueM51HT ZnG88QbiocU6EEr2KWCJjw692HDnf9o+L4t5xiUwn5pObcgNp/nqfX0K+vfcw/wN 1bU+dWACiDk2bi5+CCKpZDUbO+9kMVIQXmKmSaqhdoXmVgiDymi4/HQZAgMBAAGj NjA0MBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB /wQEAwICxDANBgkqhkiG9w0BAQUFAAOBgQCitCb19cGgqdJu0rPkUXFsJlqWJ1OQ ++4iKCPmwflN3FoVrrwVmOcvr+zvZsG2Szt4BpwvxItOHR0sL/++egGUrHY5Fb0t Dbroovs7TgnTlkcf/1PDcV0jM3TaIZKVEiKH4c+0Hpy/aGYgMWG6gm7LwyCjhNYj MSWA/5N6caTD/g== -----END CERTIFICATE----- >> 3. On uninstall the CA's are not removed from /etc/pki/nssdb and >> /etc/httpd/alias in one of my tests (the first one, so I no longer have >> the logs). > > Will fix. > >> >> 4. This one isn't your issue AFAICT, not sure if you've seen this one: >> >> # ipa-ca-install ... >> >> [snip] >> >> 2014-06-16T18:07:44Z DEBUG stdout=Loading deployment configuration from >> /tmp/tmprI2isq. >> >> 2014-06-16T18:07:44Z DEBUG stderr=Traceback (most recent call last): >> File "/usr/sbin/pkispawn", line 530, in >> main(sys.argv) >> File "/usr/sbin/pkispawn", line 439, in main >> info = parser.sd_get_info() >> File >> "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", >> line 442, in sd_get_info >> info = sd.getSecurityDomainInfo() >> File "/usr/lib/python2.7/site-packages/pki/system.py", line 40, in >> getSecurityDomainInfo >> info.name = j['DomainInfo']['@id'] >> KeyError: 'DomainInfo' >> >> 2014-06-16T18:07:44Z CRITICAL failed to configure ca instance Command >> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmprI2isq'' returned non-zero >> exit status 1 >> 2014-06-16T18:07:44Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 639, in run_script >> return_value = main_function() > > I haven't seen this one. Can it be reproduced? Not sure. I'll see if I can make time to try to reproduce and will file a ticket if I can. >> >> 5. This one may be for Tomas, but: >> >> 2014-06-16T19:01:28Z INFO Deleting schedule 2358-2359 0 from agreement >> cn=meTogrindle.greyoak.com,cn=replica,cn=dc\=greyoak\,dc\=com,cn=mapping >> tree,cn=config >> 2014-06-16T19:01:29Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:29Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:30Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:30Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:31Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:31Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 >> 2014-06-16T19:01:32Z ERROR unable to convert the attribute >> u'nsds5replicalastupdateend' value '0' to type >> 2014-06-16T19:01:32Z INFO Replication Update in progress: TRUE: status: >> 0 Replica acquired successfully: Incremental update started: start: 0: >> end: 0 > > I believe this is . > >> >> 6. With an external CA install of F-20 vanilla, upgraded to this patch, >> the external CA is not added to /etc/pki/nssdb. On a pure install of >> this patch, it is added. Not sure if we care since the cert is in the >> global cert store. > > Yes, that's one of the effects of "automatic distribution to clients is > not implemented yet". But this is on an IPA Master so we have a bit more control over things. Can't this be added to ipa-upgradeconfig at least? >> >> 7. Something for the future, but I wonder if test test_0002_find_CA in >> ipatests/test_xmlrpc/test_cert_plugin.py should be able to handle >> external CAs. >> >> rob >> > > From simo at redhat.com Thu Jun 26 17:21:44 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 26 Jun 2014 13:21:44 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403792429.11352.44.camel@willson.usersys.redhat.com> References: <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> <20140626123302.GO7233@redhat.com> <1403792429.11352.44.camel@willson.usersys.redhat.com> Message-ID: <1403803304.9460.4.camel@willson.usersys.redhat.com> On Thu, 2014-06-26 at 10:20 -0400, Simo Sorce wrote: > On Thu, 2014-06-26 at 15:33 +0300, Alexander Bokovoy wrote: > > On Thu, 26 Jun 2014, Martin Kosek wrote: > > >On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: > > >> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: > > >>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: > > >>>> ----- Original Message ----- > > >>>>> ----- Original Message ----- > > >>>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the > > >>>>>>> base tree object ? > > >>>>>>> It should be there as excluded, and that should cause admin to not be > > >>>>>>> able to retrieve keytabs. > > >>>>>> > > >>>>>> It was not. While running ipa-ldap-updater I got the following: > > >>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= > > >>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > > >>>>>> allowed to rekey any entity\22; allow(write) groupdn = > > >>>>>> \22ldap:///cn=admins: Invalid syntax. > > >>>>> > > >>>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks > > >>>>> just like the one I replace, Ideas ? > > >>>>> Do you have ipaProtectedOperation in the schema ? > > >>>>> > > >>>>> (I rebased patch 3 but will wait to send a patchset until we understand (and > > >>>>> fix) why this is failing to update. > > >>>> > > >>>> Ok, apparently it was a quoting issue in the .update files, hopefully that's > > >>>> the only issue (I am at a conference today and do not have my test env. handy). > > >>>> > > >>>> The attached patches are rebased on the latest master. > > >>> > > >>> 0001: Line 555 has very wrong indentation. > > >>> > > >>> I don't see anything else wrong in the other patches. I've tested > > >>> everything and it works as designed. > > >>> > > >>> I have CC'd everyone who was involved with review at any point on these > > >>> patches. This serves as my public notice that I'd like to ACK the next > > >>> round of patches. If anyone has anything else to add, please do it > > >>> before tomorrow evening. Thanks! > > >>> > > >>> Nathaniel > > >> > > >> ACK > > >> > > >> Nathaniel > > > > > >Pushed all 6 patches to master. Thanks for careful review! > > > > Unfortunately, at least enctype marshalling is wrong with these patches. > > Samba does not work anymore with the keytab fetched in new version. > > > > We see following in the keytab: > > Keytab name: FILE:/etc/samba/samba.keytab > > KVNO Timestamp Principal > > ---- ------------------------------------------------------------------------- > > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 274) > > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 273) > > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 272) > > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 279) > > > > Note that etype is unresolvable. In the build without these patches we > > get something like > > 1 06/23/2014 16:28:59 cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (aes256-cts-hmac-sha1-96) > > > > So this patchset needs an improvement before release. > > Working on this. > I know, roughly what's going on, but still trying to pinpoint exactly > the offender. (It is the ber marshalling/unmarshalling indeed). > > Simo. > The attached patch fixes it for me. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-getkeytab-code-to-always-use-implicit-tagging.patch Type: text/x-patch Size: 4845 bytes Desc: not available URL: From simo at redhat.com Thu Jun 26 17:51:35 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 26 Jun 2014 13:51:35 -0400 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <53ABDBD6.7060800@redhat.com> References: <1402932870.22737.113.camel@willson.usersys.redhat.com> <1403289516.12884.165.camel@willson.usersys.redhat.com> <1403290055.4808.9.camel@ipa.example.com> <1403294745.19579.2.camel@willson.usersys.redhat.com> <1403297459.4808.15.camel@ipa.example.com> <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> Message-ID: <1403805095.9460.9.camel@willson.usersys.redhat.com> On Thu, 2014-06-26 at 10:37 +0200, Martin Kosek wrote: > On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: > > On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: > >> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: > >>> ----- Original Message ----- > >>>> ----- Original Message ----- > >>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the > >>>>>> base tree object ? > >>>>>> It should be there as excluded, and that should cause admin to not be > >>>>>> able to retrieve keytabs. > >>>>> > >>>>> It was not. While running ipa-ldap-updater I got the following: > >>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= > >>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are > >>>>> allowed to rekey any entity\22; allow(write) groupdn = > >>>>> \22ldap:///cn=admins: Invalid syntax. > >>>> > >>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks > >>>> just like the one I replace, Ideas ? > >>>> Do you have ipaProtectedOperation in the schema ? > >>>> > >>>> (I rebased patch 3 but will wait to send a patchset until we understand (and > >>>> fix) why this is failing to update. > >>> > >>> Ok, apparently it was a quoting issue in the .update files, hopefully that's > >>> the only issue (I am at a conference today and do not have my test env. handy). > >>> > >>> The attached patches are rebased on the latest master. > >> > >> 0001: Line 555 has very wrong indentation. > >> > >> I don't see anything else wrong in the other patches. I've tested > >> everything and it works as designed. > >> > >> I have CC'd everyone who was involved with review at any point on these > >> patches. This serves as my public notice that I'd like to ACK the next > >> round of patches. If anyone has anything else to add, please do it > >> before tomorrow evening. Thanks! > >> > >> Nathaniel > > > > ACK > > > > Nathaniel > > Pushed all 6 patches to master. Thanks for careful review! Not sure what happened but the indentation issue I sent a patch for was not fixed in the final push and instead of a tab now there are 4 spaces: Attached find patch that fixes the issue as seen in master. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-incorrect-indentation.patch Type: text/x-patch Size: 1049 bytes Desc: not available URL: From rcritten at redhat.com Thu Jun 26 18:05:41 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jun 2014 14:05:41 -0400 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53AC05BA.6010903@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> <5374E16D.9050509@redhat.com> <537BAF42.5060502@redhat.com> <53995B8A.1090409@redhat.com> <53AC05BA.6010903@redhat.com> Message-ID: <53AC60F5.1080409@redhat.com> Jan Cholasta wrote: > On 12.6.2014 09:49, Jan Cholasta wrote: >> On 20.5.2014 21:38, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 25.4.2014 10:51, Jan Cholasta wrote: >>>>> On 24.4.2014 23:16, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>>>>>> Some in-line, a whole ton of data appended to end. >>>>>>>> >>>>>>>> Jan Cholasta wrote: >>>>>>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> >>>>>>>>>>> 247 >>>>>>>>>>> >>>>>>>>>>> We've been burned by hardcoded timeouts in the past. Should >>>>>>>>>>> this be >>>>>>>>>>> configurable? This module doesn't currently do any logging >>>>>>>>>>> but it >>>>>>>>>>> might >>>>>>>>>>> be worth spitting out a "waiting" message, at least for >>>>>>>>>>> debugging. >>>>>>>>> >>>>>>>>> Added a timeout argument. >>>>>>>> >>>>>>>> Did you forget to send this one, I didn't see an update to 247. >>>>>>> >>>>>>> Are you sure you have 247.1 (now 247.2)? >>>>>>> >>>>>>> I can see at >>>>>>> >>>>>>> >>>>>>> >>>>>>> that I have sent the correct version of the patches. >>>>>> >>>>>> The call has a timeout, the callers don't use it. I guess it'll do >>>>>> for >>>>>> now, but these almost always come back to bite us. >>>>> >>>>> Well, I can add --certmonger-timeout option to ipa-cacert-manage, if >>>>> that's what you want. >>>>> >>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>>> 251 >>>>>>>>>>> >>>>>>>>>>> The tool should provide some feedback while it's running. For >>>>>>>>>>> the >>>>>>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>>>>>> what is >>>>>>>>>>> going on, something in between nothing and full debug output. >>>>>>>>> >>>>>>>>> Added some messages about what's going on. >>>>>>>> >>>>>>>> I dpn't see an update to 251 either. >>>>>>> >>>>>>> Please make sure you have 251.1 (now 251.2). >>>>>> >>>>>> There is a little bit more output but there are still very long >>>>>> periods >>>>>> of waiting between any visual activity, particularly when doing it >>>>>> on an >>>>>> IPA self-signed CA. >>>>> >>>>> This stuff takes time :-) What would you like to see in the output, >>>>> that's not already there? >>>>> >>>>>>>> >>>>>>>> I think the ipa-cacert-manage man page is missing one really >>>>>>>> important >>>>>>>> piece: why would you ever need to run this? And when? >>>>>>> >>>>>>> Added a paragraph about this. >>>>>> >>>>>> It's better, couple of comments: >>>>>> >>>>>> Add "the" in between renew and CA in "used to manually renew CA >>>>>> certificate of" and "When IPA CA...". >>>>> >>>>> OK. >>>>> >>>>>> I haven't had any luck renewing >>>>>> the CA certificate yet. I see that it is tracked now. I started >>>>>> moving >>>>>> the system clock forward in order to get to renewal and about the 3rd >>>>>> iteration the requests started failing with an XML error. Did you see >>>>>> this? >>>>>> >>>>>> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback >>>>>> (most >>>>>> recent call last): >>>>>> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>>>>> 344, in >>>>>> wsgi_execute >>>>>> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >>>>>> self.Command[name](*args, **options) >>>>>> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>>> __call__ >>>>>> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >>>>>> self.run(*args, **options) >>>>>> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>>> run >>>>>> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >>>>>> self.execute(*args, **options) >>>>>> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>>> 382, in >>>>>> execute >>>>>> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >>>>>> api.Command['cert_show'](unicode(serial))['result'] >>>>>> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>>> __call__ >>>>>> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >>>>>> self.run(*args, **options) >>>>>> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>>> run >>>>>> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >>>>>> self.execute(*args, **options) >>>>>> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>>> 514, in >>>>>> execute >>>>>> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >>>>>> result=self.Backend.ra.get_certificate(serial_number) >>>>>> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>>> 1502, in get_certificate >>>>>> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] >>>>>> parse_result >>>>>> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >>>>>> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>>> 1363, in get_parse_result_xml >>>>>> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >>>>>> etree.fromstring(xml_text, parser) >>>>>> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >>>>>> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >>>>>> (src/lxml/lxml.etree.c:68129) >>>>>> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >>>>>> (src/lxml/lxml.etree.c:102493) >>>>>> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 1673, in lxml.etree._parseDoc >>>>>> (src/lxml/lxml.etree.c:101322) >>>>>> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >>>>>> (src/lxml/lxml.etree.c:96504) >>>>>> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 582, in >>>>>> lxml.etree._ParserContext._handleParseResultDoc >>>>>> (src/lxml/lxml.etree.c:91308) >>>>>> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 683, in lxml.etree._handleParseResult >>>>>> (src/lxml/lxml.etree.c:92494) >>>>>> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >>>>>> "parser.pxi", line 633, in lxml.etree._raiseParseError >>>>>> (src/lxml/lxml.etree.c:91957) >>>>>> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] >>>>>> XMLSyntaxError: >>>>>> None >>>>>> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >>>>>> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >>>>>> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/W! m! >>>>>> > 8! >>>>>> >> V! >>> P! >>>>>> >>>> Z! >>>>>> >>>>> gm! >>>>>> >>>>>> 3VCtgMvPVk >>>>>> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >>>>>> version=u'2.51'): XMLSyntaxError >>>>> >>>>> I have never seen this. The error message does not say much... Is >>>>> there >>>>> anything interesting in other logs? >>>> >>>> I was able to get the CA certificate to be renewed after moving system >>>> time forward step by step. >>>> >>>> One thing I haven't noticed before is that the renewed certificate's >>>> validity never exceeds that of the original certificate. This is most >>>> likely Dogtag issue (something along the lines of "certificate validity >>>> cannot exceed validity of the CA certificate", except it shouldn't >>>> apply >>>> to the CA certificate itself). >>>> >>>> There were other issues here and there, all of them were caused by race >>>> conditions between concurrent renewals (unreachable CA, XML syntax >>>> errors, etc. because Dogtag was stopped by stop_pkicad in another >>>> request, CMS internal error because it used old subsystem cert to >>>> authenticate to LDAP while the cert was being renewed, etc.) and all of >>>> them could be fixed by restarting relevant IPA services and >>>> resubmitting >>>> the requests manually. Some synchronization is really missing there. >>> >>> I hadn't noticed that, but my CA was issued externally so I expected >>> this. I also saw the bumps during renewal but things always tended to >>> smooth out, with the errors generally restricted to restarts and >>> certmonger. This backtrace was the only thing that really stood out. >>> IIRC at this point things were pretty much blocked. >>> >>> In any case, these patches basically seem to work. I never did work out >>> whether the above error was due to dogtag, IPA or something else. >>> >>> rob >> >> Rebased the patches on top of current master. >> >> Give up retrieving certificate from LDAP in patch 265 after a few >> unsuccessful attempts. This is to prevent certmonger requests from >> staying in CA_WORKING state forever when you manually resubmit a request. >> >> Added patch 266 which adds ACIs missing after the permission refactoring. > > Rebased again. > > Converted all permissions to managed permissions. > > Added dependency on certmonger >= 0.74 in patch 251, because CSR export > is broken with older versions. There is an update to certmonger 0.75.5 > for F20: > . > (It segfaults for me during server install, I and Nalin are investigating.) > I need a full set of patches, 241-299 from the same tree. Trying to piece together more than 50 patches from three long threads is proving impossible. Provided some feedback on 295-299 in that thread but I can't get much applied so I can do any functional testing. rob From rcritten at redhat.com Thu Jun 26 18:05:45 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jun 2014 14:05:45 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53AC24CB.607@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> Message-ID: <53AC60F9.9030900@redhat.com> Jan Cholasta wrote: > On 16.6.2014 15:35, Jan Cholasta wrote: >> Hi, >> >> the attached patches implement >> . >> >> My patches 241-253 and 262-294 are required for this >> (, >> ). >> >> The installation/testing guidelines from >> >> apply here as well. >> >> Honza > > Rebased on top of current master. 295 ACK 296, 297 & 299 TBD, need to test but no problems seen so far. 298 The man page, if not usage, should include what the valid trust flags are or point to NSS documentation. rob From edewata at redhat.com Fri Jun 27 04:34:12 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Jun 2014 23:34:12 -0500 Subject: [Freeipa-devel] [PATCH] 670-675 webui: dns forward zones In-Reply-To: <53A98DAF.9000306@redhat.com> References: <53A95AD0.5060905@redhat.com> <53A98DAF.9000306@redhat.com> Message-ID: <53ACF444.60803@redhat.com> On 6/24/2014 9:39 AM, Petr Vobornik wrote: > On 24.6.2014 13:02, Petr Vobornik wrote: >> ticket: https://fedorahosted.org/freeipa/ticket/4357 >> >> - patch 673 is compressed >> - CI patches functionally depends on #667, #668 >> >> == PATCH] 670 webui: add confirmation for dns zone permission actions == >> All header actions should require confirmation. >> >> == [PATCH] 671 webui: dns forward zones == >> Add DNS Forward Zones Web UI. >> >> - pages under: Identity/DNS/DNS Forward Zones >> >> == [PATCH] 672 webui-ci: dns forward zone tests == >> Selenium CI sanity tests for DNS Forward Zones >> >> == [PATCH] 673 webui-test: static metadata update == >> Regular update of static metadata for testing and presentation purposes. >> It should also contain new DNS Forward Zones metadata. >> >> == [PATCH] 674 webui-test: dns forward zone json data == >> Fake API results for testing and presentation purposes of DNS Forward >> Zones. >> >> == [PATCH] 675 webui: fix detection of RPC command == >> old detection did not work with the static version used for test and >> demonstration purposes. > > Attaching an updated version of #675 with a fix for unit tests. ACK. Some comments below. > Btw I'm > not very satisfied with patch #675's approach. I'm open to suggestions > for better approaches. How about adding another parameter to get_record() to indicate the type of the data? Possible improvements: 1. In the Add DNS Forward Zone dialog, if the "Zone forwarders" is empty and you click Add, there is no error message. 2. In the same dialog, by default there probably should be an empty field to enter the "Zone forwarders" because it's required. The admin can click Add to add additional forwarders. 3. The permission name is only displayed briefly after creation. It would be nice to display the permission name or a link to it in the details page. 4. Unrelated. Should "undo" and "undo all" be capitalized? They seem to be inconsistent with other buttons. -- Endi S. Dewata From edewata at redhat.com Fri Jun 27 04:34:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 26 Jun 2014 23:34:27 -0500 Subject: [Freeipa-devel] [PATCH] 678-679 webui: send API version in RPC requests and adapt to new response format In-Reply-To: <53AAD3F6.3070101@redhat.com> References: <53AAD3F6.3070101@redhat.com> Message-ID: <53ACF453.1080209@redhat.com> On 6/25/2014 8:51 AM, Petr Vobornik wrote: > ticket: https://fedorahosted.org/freeipa/ticket/4394 > > == [PATCH] 678 webui: send API version in RPC requests == > Currently there is an incorrect behavior that server doesn't send datetime > and dnsname data in new format. > > This patch adds the version to each RPC request making the UI look as the > latest client. Server then sends data in correct format. It also removes > the "unknown version" warning from each RPC response. > > > == [PATCH] 679 webui: extract rpc value from object envelope == > adapt Web UI to a newer style of encapsulation object data ACK. -- Endi S. Dewata From pspacek at redhat.com Fri Jun 27 07:34:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 09:34:12 +0200 Subject: [Freeipa-devel] [PATCH 0274] Add TLSARecord to idnsRecord object class Message-ID: <53AD1E74.5020606@redhat.com> Hello, Add TLSARecord to idnsRecord object class. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0274-Add-TLSARecord-to-idnsRecord-object-class.patch Type: text/x-patch Size: 828 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jun 27 07:48:50 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 27 Jun 2014 17:48:50 +1000 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <53AAFFCC.3050308@redhat.com> References: <53AAFFCC.3050308@redhat.com> Message-ID: <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: > Patch 618 fixes a bug. > > Patches 680 and 681 were implemented along with it. They address pspacek's > usability rant :). > > [PATCH] 680 webui: show notification instead of modal dialog on validation > error > [PATCH] 681 webui: fix required error notification in multivalued widget > [PATCH] 682 webui: focus invalid widget on validation error > -- > Petr Vobornik ACK on 680 and 682. On 681: diff makes sense; I'm not 100% sure my testing has covered cases that were previously failing. ACK if you're confident, otherwise could you provide steps to verify? Cheers, Fraser > From 5c3fcd240d61f378a8bb7e8cd4c2129cd11930df Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Wed, 25 Jun 2014 15:17:26 +0200 > Subject: [PATCH] webui: focus invalid widget on validation error > > --- > install/ui/src/freeipa/add.js | 7 +++++-- > install/ui/src/freeipa/details.js | 4 +++- > install/ui/src/freeipa/widget.js | 22 ++++++++++++++++++++++ > 3 files changed, 30 insertions(+), 3 deletions(-) > > diff --git a/install/ui/src/freeipa/add.js b/install/ui/src/freeipa/add.js > index a4b5d3649d2df2933cb7eb7c8a24a18b7b789f50..78f3890ad2320cbc3afd5cb9ae1e4ae2359d8023 100644 > --- a/install/ui/src/freeipa/add.js > +++ b/install/ui/src/freeipa/add.js > @@ -20,7 +20,7 @@ > */ > > define(['./ipa', './jquery', './navigation', './rpc', './text', './field', './widget', './dialog'], > - function(IPA, $, navigation, rpc, text) { > + function(IPA, $, navigation, rpc, text, field_mod, widget_mod) { > > /** > * Entity adder dialog > @@ -219,7 +219,10 @@ IPA.entity_adder_dialog = function(spec) { > */ > that.add = function(on_success, on_error) { > > - if (!that.validate()) return; > + if (!that.validate()) { > + widget_mod.focus_invalid(that); > + return; > + } > > var record = {}; > that.save(record); > diff --git a/install/ui/src/freeipa/details.js b/install/ui/src/freeipa/details.js > index ed057e98c14e8ee72e5f1596ed24599eb27abfa5..7aa4c0ef6541900d6fa5b14b16ec964b50349015 100644 > --- a/install/ui/src/freeipa/details.js > +++ b/install/ui/src/freeipa/details.js > @@ -31,9 +31,10 @@ define([ > './rpc', > './spec_util', > './text', > + './widget', > './facet', > './add'], > - function(lang, builder, IPA, $, phases, reg, rpc, su, text) { > + function(lang, builder, IPA, $, phases, reg, rpc, su, text, widget_mod) { > > /** > * Details module > @@ -1436,6 +1437,7 @@ exp.update_action = IPA.update_action = function(spec) { > > if (!facet.validate()) { > facet.show_validation_error(); > + widget_mod.focus_invalid(facet); > return; > } > > diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js > index 3d3f427af43e429124f5e19a2604bd443a6e39c8..ab86c72d1abfae87984fa2212040a3e6c63f2f31 100644 > --- a/install/ui/src/freeipa/widget.js > +++ b/install/ui/src/freeipa/widget.js > @@ -5747,6 +5747,28 @@ exp.activity_widget = IPA.activity_widget = function(spec) { > }; > > /** > + * Find and focus first focusable invalid widget > + * @member widget > + * @param {IPA.widget|facet.facet} widget Widget container > + * @return {boolean} A widget was focused > + */ > +exp.focus_invalid = function(widget) { > + > + var widgets = widget.widgets.widgets; > + var focused = false; > + for (var i=0, l=widgets.length; i + var w = widgets.values[i]; > + if (w.valid === false && w.focus_input) { > + w.focus_input(); > + focused = true; > + } > + else if (w.widgets) focused = exp.focus_invalid(w); > + if (focused) break; > + } > + return focused; > +}; > + > +/** > * pre_op operations for widgets > * - sets facet and entity if present in context > * @member widget > -- > 1.9.0 > > From 431dad35cbcb02351786fd75bd34aa86781d42fb Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Wed, 25 Jun 2014 14:50:16 +0200 > Subject: [PATCH] webui: fix required error notification in multivalued widget > > --- > install/ui/src/freeipa/widget.js | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js > index a49c6282b1977008e80a9c02754df44de31c8b02..3d3f427af43e429124f5e19a2604bd443a6e39c8 100644 > --- a/install/ui/src/freeipa/widget.js > +++ b/install/ui/src/freeipa/widget.js > @@ -909,7 +909,7 @@ IPA.multivalued_widget = function(spec) { > var old = that.valid; > that.valid = result.valid; > > - if (!result.valid && result.errors) { > + if (!result.valid && result.results) { > var offset = 0; > for (var i=0; i > @@ -928,10 +928,9 @@ IPA.multivalued_widget = function(spec) { > var error_link = that.get_error_link(); > error_link.css('display', 'none'); > error_link.html(''); > - } else { > - that.show_error(result.message); > } > - > + } else if (!result.valid) { > + that.show_error(result.message); > } else { > that.hide_error(); > } > -- > 1.9.0 > > From 65ce6fcd7578e0dbe03adf1ba8b9ae3fc67c09bb Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Wed, 25 Jun 2014 14:49:26 +0200 > Subject: [PATCH] webui: show notification instead of modal dialog on > validation error > > --- > install/ui/src/freeipa/details.js | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/install/ui/src/freeipa/details.js b/install/ui/src/freeipa/details.js > index b7fa3646921dd8a3229d1bb397373d808877fa17..ed057e98c14e8ee72e5f1596ed24599eb27abfa5 100644 > --- a/install/ui/src/freeipa/details.js > +++ b/install/ui/src/freeipa/details.js > @@ -930,12 +930,7 @@ exp.details_facet = IPA.details_facet = function(spec, no_init) { > * @protected > */ > that.show_validation_error = function() { > - var dialog = IPA.message_dialog({ > - name: 'validation_error', > - title: '@i18n:dialogs.validation_title', > - message: '@i18n:dialogs.validation_message' > - }); > - dialog.open(); > + IPA.notify('@i18n:dialogs.validation_message', 'error'); > }; > > /** > -- > 1.9.0 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Fri Jun 27 08:00:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 11:00:16 +0300 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <1403803304.9460.4.camel@willson.usersys.redhat.com> References: <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> <20140626123302.GO7233@redhat.com> <1403792429.11352.44.camel@willson.usersys.redhat.com> <1403803304.9460.4.camel@willson.usersys.redhat.com> Message-ID: <20140627080016.GR7233@redhat.com> On Thu, 26 Jun 2014, Simo Sorce wrote: >On Thu, 2014-06-26 at 10:20 -0400, Simo Sorce wrote: >> On Thu, 2014-06-26 at 15:33 +0300, Alexander Bokovoy wrote: >> > On Thu, 26 Jun 2014, Martin Kosek wrote: >> > >On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: >> > >> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: >> > >>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: >> > >>>> ----- Original Message ----- >> > >>>>> ----- Original Message ----- >> > >>>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the >> > >>>>>>> base tree object ? >> > >>>>>>> It should be there as excluded, and that should cause admin to not be >> > >>>>>>> able to retrieve keytabs. >> > >>>>>> >> > >>>>>> It was not. While running ipa-ldap-updater I got the following: >> > >>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= >> > >>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are >> > >>>>>> allowed to rekey any entity\22; allow(write) groupdn = >> > >>>>>> \22ldap:///cn=admins: Invalid syntax. >> > >>>>> >> > >>>>> Uhmm I do not see anything obviously wrong with ACI instruction, it looks >> > >>>>> just like the one I replace, Ideas ? >> > >>>>> Do you have ipaProtectedOperation in the schema ? >> > >>>>> >> > >>>>> (I rebased patch 3 but will wait to send a patchset until we understand (and >> > >>>>> fix) why this is failing to update. >> > >>>> >> > >>>> Ok, apparently it was a quoting issue in the .update files, hopefully that's >> > >>>> the only issue (I am at a conference today and do not have my test env. handy). >> > >>>> >> > >>>> The attached patches are rebased on the latest master. >> > >>> >> > >>> 0001: Line 555 has very wrong indentation. >> > >>> >> > >>> I don't see anything else wrong in the other patches. I've tested >> > >>> everything and it works as designed. >> > >>> >> > >>> I have CC'd everyone who was involved with review at any point on these >> > >>> patches. This serves as my public notice that I'd like to ACK the next >> > >>> round of patches. If anyone has anything else to add, please do it >> > >>> before tomorrow evening. Thanks! >> > >>> >> > >>> Nathaniel >> > >> >> > >> ACK >> > >> >> > >> Nathaniel >> > > >> > >Pushed all 6 patches to master. Thanks for careful review! >> > >> > Unfortunately, at least enctype marshalling is wrong with these patches. >> > Samba does not work anymore with the keytab fetched in new version. >> > >> > We see following in the keytab: >> > Keytab name: FILE:/etc/samba/samba.keytab >> > KVNO Timestamp Principal >> > ---- ------------------------------------------------------------------------- >> > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 274) >> > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 273) >> > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 272) >> > 1 06/26/2014 13:03:01 cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (etype 279) >> > >> > Note that etype is unresolvable. In the build without these patches we >> > get something like >> > 1 06/23/2014 16:28:59 cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM (aes256-cts-hmac-sha1-96) >> > >> > So this patchset needs an improvement before release. >> >> Working on this. >> I know, roughly what's going on, but still trying to pinpoint exactly >> the offender. (It is the ber marshalling/unmarshalling indeed). >> >> Simo. >> > >The attached patch fixes it for me. ACK, works for me too. Martin: it makes sense to merge both this and the indentation fix together prior to commit. -- / Alexander Bokovoy From mkosek at redhat.com Fri Jun 27 08:06:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 10:06:25 +0200 Subject: [Freeipa-devel] Design Review Keytab Retrieval In-Reply-To: <20140627080016.GR7233@redhat.com> References: <1403308559.19579.5.camel@willson.usersys.redhat.com> <1403528846.23272.3.camel@ipa.example.com> <231397244.28957909.1403542137994.JavaMail.zimbra@redhat.com> <37546403.29025381.1403548506101.JavaMail.zimbra@redhat.com> <1403558642.3263.9.camel@ipa.example.com> <1403749772.3523.26.camel@ipa.example.com> <53ABDBD6.7060800@redhat.com> <20140626123302.GO7233@redhat.com> <1403792429.11352.44.camel@willson.usersys.redhat.com> <1403803304.9460.4.camel@willson.usersys.redhat.com> <20140627080016.GR7233@redhat.com> Message-ID: <53AD2601.9080506@redhat.com> On 06/27/2014 10:00 AM, Alexander Bokovoy wrote: > On Thu, 26 Jun 2014, Simo Sorce wrote: >> On Thu, 2014-06-26 at 10:20 -0400, Simo Sorce wrote: >>> On Thu, 2014-06-26 at 15:33 +0300, Alexander Bokovoy wrote: >>> > On Thu, 26 Jun 2014, Martin Kosek wrote: >>> > >On 06/26/2014 04:29 AM, Nathaniel McCallum wrote: >>> > >> On Mon, 2014-06-23 at 17:24 -0400, Nathaniel McCallum wrote: >>> > >>> On Mon, 2014-06-23 at 14:35 -0400, Simo Sorce wrote: >>> > >>>> ----- Original Message ----- >>> > >>>>> ----- Original Message ----- >>> > >>>>>>> Can you check if ipaProtectedOperation is in the aci attribute in the >>> > >>>>>>> base tree object ? >>> > >>>>>>> It should be there as excluded, and that should cause admin to not be >>> > >>>>>>> able to retrieve keytabs. >>> > >>>>>> >>> > >>>>>> It was not. While running ipa-ldap-updater I got the following: >>> > >>>>>> InvalidSyntax: ACL Syntax Error(-5):(targetattr= >>> > >>>>>> \22ipaProtectedOperation;write_keys\22)(version 3.0; acl \22Admins are >>> > >>>>>> allowed to rekey any entity\22; allow(write) groupdn = >>> > >>>>>> \22ldap:///cn=admins: Invalid syntax. >>> > >>>>> >>> > >>>>> Uhmm I do not see anything obviously wrong with ACI instruction, it >>> looks >>> > >>>>> just like the one I replace, Ideas ? >>> > >>>>> Do you have ipaProtectedOperation in the schema ? >>> > >>>>> >>> > >>>>> (I rebased patch 3 but will wait to send a patchset until we >>> understand (and >>> > >>>>> fix) why this is failing to update. >>> > >>>> >>> > >>>> Ok, apparently it was a quoting issue in the .update files, hopefully >>> that's >>> > >>>> the only issue (I am at a conference today and do not have my test >>> env. handy). >>> > >>>> >>> > >>>> The attached patches are rebased on the latest master. >>> > >>> >>> > >>> 0001: Line 555 has very wrong indentation. >>> > >>> >>> > >>> I don't see anything else wrong in the other patches. I've tested >>> > >>> everything and it works as designed. >>> > >>> >>> > >>> I have CC'd everyone who was involved with review at any point on these >>> > >>> patches. This serves as my public notice that I'd like to ACK the next >>> > >>> round of patches. If anyone has anything else to add, please do it >>> > >>> before tomorrow evening. Thanks! >>> > >>> >>> > >>> Nathaniel >>> > >> >>> > >> ACK >>> > >> >>> > >> Nathaniel >>> > > >>> > >Pushed all 6 patches to master. Thanks for careful review! >>> > >>> > Unfortunately, at least enctype marshalling is wrong with these patches. >>> > Samba does not work anymore with the keytab fetched in new version. >>> > >>> > We see following in the keytab: >>> > Keytab name: FILE:/etc/samba/samba.keytab >>> > KVNO Timestamp Principal >>> > ---- >>> ------------------------------------------------------------------------- >>> > 1 06/26/2014 13:03:01 >>> cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >>> (etype 274) >>> > 1 06/26/2014 13:03:01 >>> cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >>> (etype 273) >>> > 1 06/26/2014 13:03:01 >>> cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >>> (etype 272) >>> > 1 06/26/2014 13:03:01 >>> cifs/vm-136.dom136.tbad.idm.lab.eng.brq.redhat.com at DOM136.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >>> (etype 279) >>> > >>> > Note that etype is unresolvable. In the build without these patches we >>> > get something like >>> > 1 06/23/2014 16:28:59 >>> cifs/vm-139.dom139.tbad.idm.lab.eng.brq.redhat.com at DOM139.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >>> (aes256-cts-hmac-sha1-96) >>> > >>> > So this patchset needs an improvement before release. >>> >>> Working on this. >>> I know, roughly what's going on, but still trying to pinpoint exactly >>> the offender. (It is the ber marshalling/unmarshalling indeed). >>> >>> Simo. >>> >> >> The attached patch fixes it for me. > ACK, works for me too. > > Martin: it makes sense to merge both this and the indentation fix > together prior to commit. +1. (The bad indentation fix is my fault as I wanted to fix that before pushing, based on Nathaniel's point, but did not notice the source use tabs). Merged both patches, pushed to master. Martin From abokovoy at redhat.com Fri Jun 27 08:15:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 11:15:16 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> Message-ID: <20140627081516.GS7233@redhat.com> On Fri, 20 Jun 2014, Martin Basti wrote: >On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >> On 18.6.2014 16:49, Martin Basti wrote: >> > Due to compability with older versions, only IDNA domains should be >> > checked >> > Patch attached. >> >> I'm not particularly happy about the u'\xdf' special case. Isn't there a >> better way to do this check? >I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN string. > >Or just remove this validation. > >> (BTW I really think this should be a warning, not an error, but that >> would require larger amount of work, so I guess it's OK for now.) >(More pain than gain) Main thing in this patch is that the check should not be done against non-IDN strings. I want this version of the patch to go in for that reason as currently you cannot even complete ipa-adtrust-install run due to IDN normalisation check being applied to non-IDN domains. -- / Alexander Bokovoy From mkosek at redhat.com Fri Jun 27 08:18:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 10:18:42 +0200 Subject: [Freeipa-devel] [PATCH] 470 Add python-yubico to BuildRequires Message-ID: <53AD28E2.6080507@redhat.com> python-yubico needs to be on a machine to be able to build FreeIPA. Without it, even ./makeapi and ./makeaci fails. -- Pushed to master under one-liner rule. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-470-add-python-yubico-to-buildrequires.patch Type: text/x-patch Size: 876 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 27 08:27:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 10:27:48 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627081516.GS7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> Message-ID: <53AD2B04.40405@redhat.com> On 27.6.2014 10:15, Alexander Bokovoy wrote: > On Fri, 20 Jun 2014, Martin Basti wrote: >> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>> On 18.6.2014 16:49, Martin Basti wrote: >>> > Due to compability with older versions, only IDNA domains should be >>> > checked >>> > Patch attached. >>> >>> I'm not particularly happy about the u'\xdf' special case. Isn't there a >>> better way to do this check? >> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >> string. >> >> Or just remove this validation. >> >>> (BTW I really think this should be a warning, not an error, but that >>> would require larger amount of work, so I guess it's OK for now.) >> (More pain than gain) > Main thing in this patch is that the check should not be done against > non-IDN strings. I want this version of the patch to go in for that > reason as currently you cannot even complete ipa-adtrust-install run due > to IDN normalisation check being applied to non-IDN domains. On non-IDN domains, the only effect of IDN normalization is that it lower-cases the names (right?), so the check should compare lower-cased original name with the normalized name, instead of special-casing certain characters etc. -- Jan Cholasta From abokovoy at redhat.com Fri Jun 27 08:29:16 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 11:29:16 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD2B04.40405@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> Message-ID: <20140627082915.GT7233@redhat.com> On Fri, 27 Jun 2014, Jan Cholasta wrote: >On 27.6.2014 10:15, Alexander Bokovoy wrote: >>On Fri, 20 Jun 2014, Martin Basti wrote: >>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>On 18.6.2014 16:49, Martin Basti wrote: >>>>> Due to compability with older versions, only IDNA domains should be >>>>> checked >>>>> Patch attached. >>>> >>>>I'm not particularly happy about the u'\xdf' special case. Isn't there a >>>>better way to do this check? >>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>string. >>> >>>Or just remove this validation. >>> >>>>(BTW I really think this should be a warning, not an error, but that >>>>would require larger amount of work, so I guess it's OK for now.) >>>(More pain than gain) >>Main thing in this patch is that the check should not be done against >>non-IDN strings. I want this version of the patch to go in for that >>reason as currently you cannot even complete ipa-adtrust-install run due >>to IDN normalisation check being applied to non-IDN domains. > >On non-IDN domains, the only effect of IDN normalization is that it >lower-cases the names (right?), so the check should compare >lower-cased original name with the normalized name, instead of >special-casing certain characters etc. .. what's the reason to do such comparison then? lower-cased non-IDN name will be equal to lower-cased normalized non-IDN name by definition, so the check is not needed in this case, at all. Otherwise, we get [15/21]: adding special DNS service records Unexpected error - see /var/log/ipaserver-install.log for details: ConversionError: invalid 'name': domain name '_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs' and normalized domain name '_ldap._tcp.default-first-site-name._sites.dc._msdcs' do not match. Please use only normalized domains -- / Alexander Bokovoy From jcholast at redhat.com Fri Jun 27 08:39:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 10:39:41 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627082915.GT7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> Message-ID: <53AD2DCD.1070401@redhat.com> On 27.6.2014 10:29, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Jan Cholasta wrote: >> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>> Due to compability with older versions, only IDNA domains should be >>>>>> checked >>>>>> Patch attached. >>>>> >>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>> there a >>>>> better way to do this check? >>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>> string. >>>> >>>> Or just remove this validation. >>>> >>>>> (BTW I really think this should be a warning, not an error, but that >>>>> would require larger amount of work, so I guess it's OK for now.) >>>> (More pain than gain) >>> Main thing in this patch is that the check should not be done against >>> non-IDN strings. I want this version of the patch to go in for that >>> reason as currently you cannot even complete ipa-adtrust-install run due >>> to IDN normalisation check being applied to non-IDN domains. >> >> On non-IDN domains, the only effect of IDN normalization is that it >> lower-cases the names (right?), so the check should compare >> lower-cased original name with the normalized name, instead of >> special-casing certain characters etc. > .. what's the reason to do such comparison then? lower-cased non-IDN > name will be equal to lower-cased normalized non-IDN name by definition, > so the check is not needed in this case, at all. The point is that it works for both IDN and non-IDN, without u'\xdf'-style hacks. > > Otherwise, we get > [15/21]: adding special DNS service records > Unexpected error - see /var/log/ipaserver-install.log for details: > ConversionError: invalid 'name': domain name > '_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs' and normalized > domain name '_ldap._tcp.default-first-site-name._sites.dc._msdcs' do not > match. Please use only normalized domains > -- Jan Cholasta From pvoborni at redhat.com Fri Jun 27 08:54:39 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 10:54:39 +0200 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> Message-ID: <53AD314F.50906@redhat.com> On 27.6.2014 09:48, Fraser Tweedale wrote: > On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: >> Patch 618 fixes a bug. >> >> Patches 680 and 681 were implemented along with it. They address pspacek's >> usability rant :). >> >> [PATCH] 680 webui: show notification instead of modal dialog on validation >> error >> [PATCH] 681 webui: fix required error notification in multivalued widget >> [PATCH] 682 webui: focus invalid widget on validation error >> -- >> Petr Vobornik > > ACK on 680 and 682. > > On 681: diff makes sense; I'm not 100% sure my testing has covered > cases that were previously failing. ACK if you're confident, > otherwise could you provide steps to verify? You need to find a required multivalued field. One is in "Identity/Realm Domains". Delete all values and hit update. It's little bit related to ticket: https://fedorahosted.org/freeipa/ticket/4057 Also when verifying validators in multivalued field, it's good to check if errors are provided only for "invalid" values, etc.. good test field is in "DNS/DNS Zones/some zone/Settings/ there is "Allow query" field which accepts network address, "any" or "none". > > Cheers, > > Fraser > -- Petr Vobornik From abokovoy at redhat.com Fri Jun 27 08:58:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 11:58:21 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD2DCD.1070401@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> Message-ID: <20140627085821.GU7233@redhat.com> On Fri, 27 Jun 2014, Jan Cholasta wrote: >On 27.6.2014 10:29, Alexander Bokovoy wrote: >>On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>Due to compability with older versions, only IDNA domains should be >>>>>>>checked >>>>>>>Patch attached. >>>>>> >>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>there a >>>>>>better way to do this check? >>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>string. >>>>> >>>>>Or just remove this validation. >>>>> >>>>>>(BTW I really think this should be a warning, not an error, but that >>>>>>would require larger amount of work, so I guess it's OK for now.) >>>>>(More pain than gain) >>>>Main thing in this patch is that the check should not be done against >>>>non-IDN strings. I want this version of the patch to go in for that >>>>reason as currently you cannot even complete ipa-adtrust-install run due >>>>to IDN normalisation check being applied to non-IDN domains. >>> >>>On non-IDN domains, the only effect of IDN normalization is that it >>>lower-cases the names (right?), so the check should compare >>>lower-cased original name with the normalized name, instead of >>>special-casing certain characters etc. >>.. what's the reason to do such comparison then? lower-cased non-IDN >>name will be equal to lower-cased normalized non-IDN name by definition, >>so the check is not needed in this case, at all. > >The point is that it works for both IDN and non-IDN, without >u'\xdf'-style hacks. No, your proposal of comparing low-cased value and normalized value is not going to work because low-cased value is in general not equal to normalized value for IDN names, only for non-IDN ones, due to the fact that lower case for non-ASCII Unicode character may map to a completely different character than in normalization situation. Take, for example, Turkish alphabet where there are six letters with different case rules (uppercase dotted i, dottless lowercase i, upper- and lowercase G with breve accent, and upper- and lowercase S with cedilla), which will break your generalized check. So you'll anyway will need to split these cases. -- / Alexander Bokovoy From jcholast at redhat.com Fri Jun 27 09:21:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 11:21:30 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627085821.GU7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> Message-ID: <53AD379A.7080605@redhat.com> On 27.6.2014 10:58, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Jan Cholasta wrote: >> On 27.6.2014 10:29, Alexander Bokovoy wrote: >>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>> Due to compability with older versions, only IDNA domains should be >>>>>>>> checked >>>>>>>> Patch attached. >>>>>>> >>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>> there a >>>>>>> better way to do this check? >>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>> string. >>>>>> >>>>>> Or just remove this validation. >>>>>> >>>>>>> (BTW I really think this should be a warning, not an error, but that >>>>>>> would require larger amount of work, so I guess it's OK for now.) >>>>>> (More pain than gain) >>>>> Main thing in this patch is that the check should not be done against >>>>> non-IDN strings. I want this version of the patch to go in for that >>>>> reason as currently you cannot even complete ipa-adtrust-install >>>>> run due >>>>> to IDN normalisation check being applied to non-IDN domains. >>>> >>>> On non-IDN domains, the only effect of IDN normalization is that it >>>> lower-cases the names (right?), so the check should compare >>>> lower-cased original name with the normalized name, instead of >>>> special-casing certain characters etc. >>> .. what's the reason to do such comparison then? lower-cased non-IDN >>> name will be equal to lower-cased normalized non-IDN name by definition, >>> so the check is not needed in this case, at all. >> >> The point is that it works for both IDN and non-IDN, without >> u'\xdf'-style hacks. > No, your proposal of comparing low-cased value and normalized value is > not going to work because low-cased value is in general not equal to > normalized value for IDN names, only for non-IDN ones, due to the fact > that lower case for non-ASCII Unicode character may map to a completely > different character than in normalization situation. Take, for example, > Turkish alphabet where there are six letters with different case rules > (uppercase dotted i, dottless lowercase i, upper- and lowercase G with > breve accent, and upper- and lowercase S with cedilla), which will break > your generalized check. > So you'll anyway will need to split these cases. > I see. I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in this particular spot. Can we check that a name is IDN some other way than "domain_name.is_idn() or u'\xdf' in value"? -- Jan Cholasta From abokovoy at redhat.com Fri Jun 27 10:04:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 13:04:42 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD379A.7080605@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> Message-ID: <20140627100442.GV7233@redhat.com> On Fri, 27 Jun 2014, Jan Cholasta wrote: >On 27.6.2014 10:58, Alexander Bokovoy wrote: >>On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>>On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>>On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>>On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>>Due to compability with older versions, only IDNA domains should be >>>>>>>>>checked >>>>>>>>>Patch attached. >>>>>>>> >>>>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>>there a >>>>>>>>better way to do this check? >>>>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>>string. >>>>>>> >>>>>>>Or just remove this validation. >>>>>>> >>>>>>>>(BTW I really think this should be a warning, not an error, but that >>>>>>>>would require larger amount of work, so I guess it's OK for now.) >>>>>>>(More pain than gain) >>>>>>Main thing in this patch is that the check should not be done against >>>>>>non-IDN strings. I want this version of the patch to go in for that >>>>>>reason as currently you cannot even complete ipa-adtrust-install >>>>>>run due >>>>>>to IDN normalisation check being applied to non-IDN domains. >>>>> >>>>>On non-IDN domains, the only effect of IDN normalization is that it >>>>>lower-cases the names (right?), so the check should compare >>>>>lower-cased original name with the normalized name, instead of >>>>>special-casing certain characters etc. >>>>.. what's the reason to do such comparison then? lower-cased non-IDN >>>>name will be equal to lower-cased normalized non-IDN name by definition, >>>>so the check is not needed in this case, at all. >>> >>>The point is that it works for both IDN and non-IDN, without >>>u'\xdf'-style hacks. >>No, your proposal of comparing low-cased value and normalized value is >>not going to work because low-cased value is in general not equal to >>normalized value for IDN names, only for non-IDN ones, due to the fact >>that lower case for non-ASCII Unicode character may map to a completely >>different character than in normalization situation. Take, for example, >>Turkish alphabet where there are six letters with different case rules >>(uppercase dotted i, dottless lowercase i, upper- and lowercase G with >>breve accent, and upper- and lowercase S with cedilla), which will break >>your generalized check. >>So you'll anyway will need to split these cases. >> > >I see. > >I'm still not comfortable with carrying the bit of knowledge about >u'\xdf' in this particular spot. Can we check that a name is IDN some >other way than "domain_name.is_idn() or u'\xdf' in value"? Attached patch works for me. Note that nameprep() use should be per-label, not the whole DNS name, and we can use encodings.idna.ToASCII() per lable to check if the label is IDN. If any of the label is IDN, we force strict check. -- / Alexander Bokovoy -------------- next part -------------- >From c782cd9e789b34e588b6e3508c284f597c3423f9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Jun 2014 13:01:28 +0300 Subject: [PATCH 3/3] Perform IDNA normalization check only for IDN domain names --- ipalib/parameters.py | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/ipalib/parameters.py b/ipalib/parameters.py index 1dff13c..09fed28 100644 --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): #compare if IDN normalized and original domain match #there is N:1 mapping between unicode and IDNA names #user should use normalized names to avoid mistakes - normalized_domain_name = encodings.idna.nameprep(value) - if value != normalized_domain_name: - error = _("domain name '%(domain)s' and normalized domain name" - " '%(normalized)s' do not match. Please use only" - " normalized domains") % {'domain': value, - 'normalized': normalized_domain_name} + labels = value.split('.') + is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] + if is_idna: + is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in labels] + if is_nonnorm: + error = _("domain name '%(domain)s' and normalized domain name" + " '%(normalized)s' do not match. Please use only" + " normalized domains") % {'domain': value, + 'normalized': normalized_domain_name} if error: raise ConversionError(name=self.get_param_name(), index=index, error=error) -- 1.9.3 From pspacek at redhat.com Fri Jun 27 10:05:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 12:05:15 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD379A.7080605@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> Message-ID: <53AD41DB.6080901@redhat.com> On 27.6.2014 11:21, Jan Cholasta wrote: > On 27.6.2014 10:58, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>> On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>> Due to compability with older versions, only IDNA domains should be >>>>>>>>> checked >>>>>>>>> Patch attached. >>>>>>>> >>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>> there a >>>>>>>> better way to do this check? >>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>> string. >>>>>>> >>>>>>> Or just remove this validation. >>>>>>> >>>>>>>> (BTW I really think this should be a warning, not an error, but that >>>>>>>> would require larger amount of work, so I guess it's OK for now.) >>>>>>> (More pain than gain) >>>>>> Main thing in this patch is that the check should not be done against >>>>>> non-IDN strings. I want this version of the patch to go in for that >>>>>> reason as currently you cannot even complete ipa-adtrust-install >>>>>> run due >>>>>> to IDN normalisation check being applied to non-IDN domains. >>>>> >>>>> On non-IDN domains, the only effect of IDN normalization is that it >>>>> lower-cases the names (right?), so the check should compare >>>>> lower-cased original name with the normalized name, instead of >>>>> special-casing certain characters etc. >>>> .. what's the reason to do such comparison then? lower-cased non-IDN >>>> name will be equal to lower-cased normalized non-IDN name by definition, >>>> so the check is not needed in this case, at all. >>> >>> The point is that it works for both IDN and non-IDN, without >>> u'\xdf'-style hacks. >> No, your proposal of comparing low-cased value and normalized value is >> not going to work because low-cased value is in general not equal to >> normalized value for IDN names, only for non-IDN ones, due to the fact >> that lower case for non-ASCII Unicode character may map to a completely >> different character than in normalization situation. Take, for example, >> Turkish alphabet where there are six letters with different case rules >> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with >> breve accent, and upper- and lowercase S with cedilla), which will break >> your generalized check. >> So you'll anyway will need to split these cases. >> > > I see. > > I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in > this particular spot. Can we check that a name is IDN some other way than > "domain_name.is_idn() or u'\xdf' in value"? Why can't we simply fix string constants in ipa-adtrust-install and avoid adding hacks for it? -- Petr^2 Spacek From jcholast at redhat.com Fri Jun 27 10:09:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 12:09:31 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627100442.GV7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> Message-ID: <53AD42DB.6020007@redhat.com> On 27.6.2014 12:04, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Jan Cholasta wrote: >> On 27.6.2014 10:58, Alexander Bokovoy wrote: >>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>>> Due to compability with older versions, only IDNA domains >>>>>>>>>> should be >>>>>>>>>> checked >>>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>>> there a >>>>>>>>> better way to do this check? >>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>>> string. >>>>>>>> >>>>>>>> Or just remove this validation. >>>>>>>> >>>>>>>>> (BTW I really think this should be a warning, not an error, but >>>>>>>>> that >>>>>>>>> would require larger amount of work, so I guess it's OK for now.) >>>>>>>> (More pain than gain) >>>>>>> Main thing in this patch is that the check should not be done >>>>>>> against >>>>>>> non-IDN strings. I want this version of the patch to go in for that >>>>>>> reason as currently you cannot even complete ipa-adtrust-install >>>>>>> run due >>>>>>> to IDN normalisation check being applied to non-IDN domains. >>>>>> >>>>>> On non-IDN domains, the only effect of IDN normalization is that it >>>>>> lower-cases the names (right?), so the check should compare >>>>>> lower-cased original name with the normalized name, instead of >>>>>> special-casing certain characters etc. >>>>> .. what's the reason to do such comparison then? lower-cased non-IDN >>>>> name will be equal to lower-cased normalized non-IDN name by >>>>> definition, >>>>> so the check is not needed in this case, at all. >>>> >>>> The point is that it works for both IDN and non-IDN, without >>>> u'\xdf'-style hacks. >>> No, your proposal of comparing low-cased value and normalized value is >>> not going to work because low-cased value is in general not equal to >>> normalized value for IDN names, only for non-IDN ones, due to the fact >>> that lower case for non-ASCII Unicode character may map to a completely >>> different character than in normalization situation. Take, for example, >>> Turkish alphabet where there are six letters with different case rules >>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with >>> breve accent, and upper- and lowercase S with cedilla), which will break >>> your generalized check. >>> So you'll anyway will need to split these cases. >>> >> >> I see. >> >> I'm still not comfortable with carrying the bit of knowledge about >> u'\xdf' in this particular spot. Can we check that a name is IDN some >> other way than "domain_name.is_idn() or u'\xdf' in value"? > > Attached patch works for me. Note that nameprep() use should be > per-label, not the whole DNS name, and we can use > encodings.idna.ToASCII() per lable to check if the label is IDN. If any > of the label is IDN, we force strict check. > Works for me, only I would write "any(...)" instead of "True in [...]". -- Jan Cholasta From pspacek at redhat.com Fri Jun 27 10:09:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 12:09:32 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627100442.GV7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> Message-ID: <53AD42DC.8030303@redhat.com> On 27.6.2014 12:04, Alexander Bokovoy wrote: > diff --git a/ipalib/parameters.py b/ipalib/parameters.py > index 1dff13c..09fed28 100644 > --- a/ipalib/parameters.py > +++ b/ipalib/parameters.py > @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): > #compare if IDN normalized and original domain match > #there is N:1 mapping between unicode and IDNA names > #user should use normalized names to avoid mistakes > - normalized_domain_name = encodings.idna.nameprep(value) > - if value != normalized_domain_name: > - error = _("domain name '%(domain)s' and normalized domain name" > - " '%(normalized)s' do not match. Please use only" > - " normalized domains") % {'domain': value, > - 'normalized': normalized_domain_name} > + labels = value.split('.') NACK. This is going to break with IDNA2003 as there are four different dots. The whole DNS refactoring was about eliminating all places where DNS names are threaded as strings separated by ASCII dots. I would like to hear reasons against fixing ipa-adtrust-install (in the other part of thread). Thank you for understanding. Petr^2 Spacek > + is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] > + if is_idna: > + is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in labels] > + if is_nonnorm: > + error = _("domain name '%(domain)s' and normalized domain name" > + " '%(normalized)s' do not match. Please use only" > + " normalized domains") % {'domain': value, > + 'normalized': normalized_domain_name} > if error: > raise ConversionError(name=self.get_param_name(), index=index, > error=error) From abokovoy at redhat.com Fri Jun 27 10:10:59 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 13:10:59 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD41DB.6080901@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> Message-ID: <20140627101059.GW7233@redhat.com> On Fri, 27 Jun 2014, Petr Spacek wrote: >On 27.6.2014 11:21, Jan Cholasta wrote: >>On 27.6.2014 10:58, Alexander Bokovoy wrote: >>>On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>>>On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>>On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>>>On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>>>On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>>>Due to compability with older versions, only IDNA domains should be >>>>>>>>>>checked >>>>>>>>>>Patch attached. >>>>>>>>> >>>>>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>>>there a >>>>>>>>>better way to do this check? >>>>>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>>>string. >>>>>>>> >>>>>>>>Or just remove this validation. >>>>>>>> >>>>>>>>>(BTW I really think this should be a warning, not an error, but that >>>>>>>>>would require larger amount of work, so I guess it's OK for now.) >>>>>>>>(More pain than gain) >>>>>>>Main thing in this patch is that the check should not be done against >>>>>>>non-IDN strings. I want this version of the patch to go in for that >>>>>>>reason as currently you cannot even complete ipa-adtrust-install >>>>>>>run due >>>>>>>to IDN normalisation check being applied to non-IDN domains. >>>>>> >>>>>>On non-IDN domains, the only effect of IDN normalization is that it >>>>>>lower-cases the names (right?), so the check should compare >>>>>>lower-cased original name with the normalized name, instead of >>>>>>special-casing certain characters etc. >>>>>.. what's the reason to do such comparison then? lower-cased non-IDN >>>>>name will be equal to lower-cased normalized non-IDN name by definition, >>>>>so the check is not needed in this case, at all. >>>> >>>>The point is that it works for both IDN and non-IDN, without >>>>u'\xdf'-style hacks. >>>No, your proposal of comparing low-cased value and normalized value is >>>not going to work because low-cased value is in general not equal to >>>normalized value for IDN names, only for non-IDN ones, due to the fact >>>that lower case for non-ASCII Unicode character may map to a completely >>>different character than in normalization situation. Take, for example, >>>Turkish alphabet where there are six letters with different case rules >>>(uppercase dotted i, dottless lowercase i, upper- and lowercase G with >>>breve accent, and upper- and lowercase S with cedilla), which will break >>>your generalized check. >>>So you'll anyway will need to split these cases. >>> >> >>I see. >> >>I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in >>this particular spot. Can we check that a name is IDN some other way than >>"domain_name.is_idn() or u'\xdf' in value"? > >Why can't we simply fix string constants in ipa-adtrust-install and >avoid adding hacks for it? Because they are correct, in the sense that they follow what is defined for Active Directory. Yes, AD puts them in that case into DNS. There is simply no reason to force lower case for non-IDN names. That said, a newer fix is attached, where error message is formatted properly. -- / Alexander Bokovoy -------------- next part -------------- >From b14576b48d98523e72382161fd22e57db0b84f22 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Jun 2014 13:01:28 +0300 Subject: [PATCH 3/3] Perform IDNA normalization check only for IDN domain names --- ipalib/parameters.py | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/ipalib/parameters.py b/ipalib/parameters.py index 1dff13c..b1b83b3 100644 --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): #compare if IDN normalized and original domain match #there is N:1 mapping between unicode and IDNA names #user should use normalized names to avoid mistakes - normalized_domain_name = encodings.idna.nameprep(value) - if value != normalized_domain_name: - error = _("domain name '%(domain)s' and normalized domain name" - " '%(normalized)s' do not match. Please use only" - " normalized domains") % {'domain': value, - 'normalized': normalized_domain_name} + labels = value.split('.') + is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] + if is_idna: + is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in labels] + if is_nonnorm: + error = _("domain name '%(domain)s' should be normalized to" + " have each label in lower case: %(normalized)s") % { + 'domain': value, + 'normalized': [encodings.idna.nameprep(x) for x in labels].join('.')} if error: raise ConversionError(name=self.get_param_name(), index=index, error=error) -- 1.9.3 From abokovoy at redhat.com Fri Jun 27 10:20:13 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 13:20:13 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD42DC.8030303@redhat.com> References: <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> <53AD42DC.8030303@redhat.com> Message-ID: <20140627102013.GX7233@redhat.com> On Fri, 27 Jun 2014, Petr Spacek wrote: >On 27.6.2014 12:04, Alexander Bokovoy wrote: >>diff --git a/ipalib/parameters.py b/ipalib/parameters.py >>index 1dff13c..09fed28 100644 >>--- a/ipalib/parameters.py >>+++ b/ipalib/parameters.py >>@@ -1965,12 +1965,15 @@ class DNSNameParam(Param): >> #compare if IDN normalized and original domain match >> #there is N:1 mapping between unicode and IDNA names >> #user should use normalized names to avoid mistakes >>- normalized_domain_name = encodings.idna.nameprep(value) >>- if value != normalized_domain_name: >>- error = _("domain name '%(domain)s' and normalized domain name" >>- " '%(normalized)s' do not match. Please use only" >>- " normalized domains") % {'domain': value, >>- 'normalized': normalized_domain_name} >>+ labels = value.split('.') > >NACK. This is going to break with IDNA2003 as there are four different >dots. The whole DNS refactoring was about eliminating all places where >DNS names are threaded as strings separated by ASCII dots. IDNA implementation in FreeIPA git master right now is wrong with regards to nameprep use -- encodings.idna.nameprep(), as well as other functions in encodings.idna should be applied to labels, not to the whole DNS name. Give me a way to split a name to labels properly and we can work on. > >I would like to hear reasons against fixing ipa-adtrust-install (in >the other part of thread). As I said, 'fixing' ipa-adtrust-install is considered a hack. Current IDNA support is broken anyway, *it* needs to be fixed, not a long standing convention to name DNS records in Active Directory implementations (which Samba AD DC setup shares as well). -- / Alexander Bokovoy From pspacek at redhat.com Fri Jun 27 10:21:51 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 12:21:51 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627102013.GX7233@redhat.com> References: <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> <53AD42DC.8030303@redhat.com> <20140627102013.GX7233@redhat.com> Message-ID: <53AD45BF.4090206@redhat.com> On 27.6.2014 12:20, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Petr Spacek wrote: >> On 27.6.2014 12:04, Alexander Bokovoy wrote: >>> diff --git a/ipalib/parameters.py b/ipalib/parameters.py >>> index 1dff13c..09fed28 100644 >>> --- a/ipalib/parameters.py >>> +++ b/ipalib/parameters.py >>> @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): >>> #compare if IDN normalized and original domain match >>> #there is N:1 mapping between unicode and IDNA names >>> #user should use normalized names to avoid mistakes >>> - normalized_domain_name = encodings.idna.nameprep(value) >>> - if value != normalized_domain_name: >>> - error = _("domain name '%(domain)s' and normalized domain >>> name" >>> - " '%(normalized)s' do not match. Please use only" >>> - " normalized domains") % {'domain': value, >>> - 'normalized': normalized_domain_name} >>> + labels = value.split('.') >> >> NACK. This is going to break with IDNA2003 as there are four different dots. >> The whole DNS refactoring was about eliminating all places where DNS names >> are threaded as strings separated by ASCII dots. > IDNA implementation in FreeIPA git master right now is wrong with > regards to nameprep use -- encodings.idna.nameprep(), as well as other > functions in encodings.idna should be applied to labels, not to the > whole DNS name. > > Give me a way to split a name to labels properly and we can work on. > >> >> I would like to hear reasons against fixing ipa-adtrust-install (in the >> other part of thread). > As I said, 'fixing' ipa-adtrust-install is considered a hack. Current > IDNA support is broken anyway, *it* needs to be fixed, not a long > standing convention to name DNS records in Active Directory > implementations (which Samba AD DC setup shares as well). Let me add that DNS protocol is case insensitive so it doesn't matter. Let's wait for mbasti's opinion. -- Petr^2 Spacek From mkosek at redhat.com Fri Jun 27 10:32:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 12:32:11 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627101059.GW7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> Message-ID: <53AD482B.4030107@redhat.com> On 06/27/2014 12:10 PM, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Petr Spacek wrote: >> On 27.6.2014 11:21, Jan Cholasta wrote: >>> On 27.6.2014 10:58, Alexander Bokovoy wrote: >>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>>>> Due to compability with older versions, only IDNA domains should be >>>>>>>>>>> checked >>>>>>>>>>> Patch attached. >>>>>>>>>> >>>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>>>> there a >>>>>>>>>> better way to do this check? >>>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>>>> string. >>>>>>>>> >>>>>>>>> Or just remove this validation. >>>>>>>>> >>>>>>>>>> (BTW I really think this should be a warning, not an error, but that >>>>>>>>>> would require larger amount of work, so I guess it's OK for now.) >>>>>>>>> (More pain than gain) >>>>>>>> Main thing in this patch is that the check should not be done against >>>>>>>> non-IDN strings. I want this version of the patch to go in for that >>>>>>>> reason as currently you cannot even complete ipa-adtrust-install >>>>>>>> run due >>>>>>>> to IDN normalisation check being applied to non-IDN domains. >>>>>>> >>>>>>> On non-IDN domains, the only effect of IDN normalization is that it >>>>>>> lower-cases the names (right?), so the check should compare >>>>>>> lower-cased original name with the normalized name, instead of >>>>>>> special-casing certain characters etc. >>>>>> .. what's the reason to do such comparison then? lower-cased non-IDN >>>>>> name will be equal to lower-cased normalized non-IDN name by definition, >>>>>> so the check is not needed in this case, at all. >>>>> >>>>> The point is that it works for both IDN and non-IDN, without >>>>> u'\xdf'-style hacks. >>>> No, your proposal of comparing low-cased value and normalized value is >>>> not going to work because low-cased value is in general not equal to >>>> normalized value for IDN names, only for non-IDN ones, due to the fact >>>> that lower case for non-ASCII Unicode character may map to a completely >>>> different character than in normalization situation. Take, for example, >>>> Turkish alphabet where there are six letters with different case rules >>>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with >>>> breve accent, and upper- and lowercase S with cedilla), which will break >>>> your generalized check. >>>> So you'll anyway will need to split these cases. >>>> >>> >>> I see. >>> >>> I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in >>> this particular spot. Can we check that a name is IDN some other way than >>> "domain_name.is_idn() or u'\xdf' in value"? >> >> Why can't we simply fix string constants in ipa-adtrust-install and avoid >> adding hacks for it? > Because they are correct, in the sense that they follow what is defined > for Active Directory. Yes, AD puts them in that case into DNS. There is > simply no reason to force lower case for non-IDN names. > > That said, a newer fix is attached, where error message is formatted > properly. I would personally be OK with the change if the is_* are fixed as Honza proposed, current way is not so Python-ic/readable. I.e.: Instead of + is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] Use + is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) Instead of + is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in labels] use + is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) However, we can wait till Monday for Martin2's feedback. Martin From abokovoy at redhat.com Fri Jun 27 11:03:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 14:03:29 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD482B.4030107@redhat.com> References: <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> Message-ID: <20140627110329.GY7233@redhat.com> On Fri, 27 Jun 2014, Martin Kosek wrote: >On 06/27/2014 12:10 PM, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Petr Spacek wrote: >>> On 27.6.2014 11:21, Jan Cholasta wrote: >>>> On 27.6.2014 10:58, Alexander Bokovoy wrote: >>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: >>>>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >>>>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >>>>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >>>>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >>>>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >>>>>>>>>>>> Due to compability with older versions, only IDNA domains should be >>>>>>>>>>>> checked >>>>>>>>>>>> Patch attached. >>>>>>>>>>> >>>>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >>>>>>>>>>> there a >>>>>>>>>>> better way to do this check? >>>>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >>>>>>>>>> string. >>>>>>>>>> >>>>>>>>>> Or just remove this validation. >>>>>>>>>> >>>>>>>>>>> (BTW I really think this should be a warning, not an error, but that >>>>>>>>>>> would require larger amount of work, so I guess it's OK for now.) >>>>>>>>>> (More pain than gain) >>>>>>>>> Main thing in this patch is that the check should not be done against >>>>>>>>> non-IDN strings. I want this version of the patch to go in for that >>>>>>>>> reason as currently you cannot even complete ipa-adtrust-install >>>>>>>>> run due >>>>>>>>> to IDN normalisation check being applied to non-IDN domains. >>>>>>>> >>>>>>>> On non-IDN domains, the only effect of IDN normalization is that it >>>>>>>> lower-cases the names (right?), so the check should compare >>>>>>>> lower-cased original name with the normalized name, instead of >>>>>>>> special-casing certain characters etc. >>>>>>> .. what's the reason to do such comparison then? lower-cased non-IDN >>>>>>> name will be equal to lower-cased normalized non-IDN name by definition, >>>>>>> so the check is not needed in this case, at all. >>>>>> >>>>>> The point is that it works for both IDN and non-IDN, without >>>>>> u'\xdf'-style hacks. >>>>> No, your proposal of comparing low-cased value and normalized value is >>>>> not going to work because low-cased value is in general not equal to >>>>> normalized value for IDN names, only for non-IDN ones, due to the fact >>>>> that lower case for non-ASCII Unicode character may map to a completely >>>>> different character than in normalization situation. Take, for example, >>>>> Turkish alphabet where there are six letters with different case rules >>>>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with >>>>> breve accent, and upper- and lowercase S with cedilla), which will break >>>>> your generalized check. >>>>> So you'll anyway will need to split these cases. >>>>> >>>> >>>> I see. >>>> >>>> I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in >>>> this particular spot. Can we check that a name is IDN some other way than >>>> "domain_name.is_idn() or u'\xdf' in value"? >>> >>> Why can't we simply fix string constants in ipa-adtrust-install and avoid >>> adding hacks for it? >> Because they are correct, in the sense that they follow what is defined >> for Active Directory. Yes, AD puts them in that case into DNS. There is >> simply no reason to force lower case for non-IDN names. >> >> That said, a newer fix is attached, where error message is formatted >> properly. > >I would personally be OK with the change if the is_* are fixed as Honza >proposed, current way is not so Python-ic/readable. I.e.: > >Instead of >+ is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] >Use >+ is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) > >Instead of >+ is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in >labels] >use >+ is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) > >However, we can wait till Monday for Martin2's feedback. I've fixed this and also made a proper split on all dots that could separate labels according to RFC3490: U+002E ( . ) FULL STOP U+FF0E ( ? ) FULLWIDTH FULL STOP U+3002 ( ? ) IDEOGRAPHIC FULL STOP U+FF61 ( ? ) HALFWIDTH IDEOGRAPHIC FULL STOP -- / Alexander Bokovoy -------------- next part -------------- >From 3d495c5f9358dc6708800ba62a9cbbc202010d86 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Jun 2014 13:01:28 +0300 Subject: [PATCH 3/3] Perform IDNA normalization check only for IDN domain names --- ipalib/parameters.py | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/ipalib/parameters.py b/ipalib/parameters.py index 1dff13c..e16b352 100644 --- a/ipalib/parameters.py +++ b/ipalib/parameters.py @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): #compare if IDN normalized and original domain match #there is N:1 mapping between unicode and IDNA names #user should use normalized names to avoid mistakes - normalized_domain_name = encodings.idna.nameprep(value) - if value != normalized_domain_name: - error = _("domain name '%(domain)s' and normalized domain name" - " '%(normalized)s' do not match. Please use only" - " normalized domains") % {'domain': value, - 'normalized': normalized_domain_name} + labels = re.split(u'[.\uff0e\u3002\uff61]', value, flags=re.UNICODE) + is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) + if is_idna: + is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) + if is_nonnorm: + error = _("domain name '%(domain)s' should be normalized to" + " have each label in lower case: %(normalized)s") % { + 'domain': value, + 'normalized': [encodings.idna.nameprep(x) for x in labels].join('.')} if error: raise ConversionError(name=self.get_param_name(), index=index, error=error) -- 1.9.3 From jcholast at redhat.com Fri Jun 27 11:06:53 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 13:06:53 +0200 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal In-Reply-To: <53AC60F5.1080409@redhat.com> References: <53319650.4000303@redhat.com> <533C97B4.4030100@redhat.com> <5342E9DD.2070307@redhat.com> <5346B027.5020407@redhat.com> <5346F9B0.8060600@redhat.com> <534E47A5.9030607@redhat.com> <53597F21.1060706@redhat.com> <535A2226.6080803@redhat.com> <5374E16D.9050509@redhat.com> <537BAF42.5060502@redhat.com> <53995B8A.1090409@redhat.com> <53AC05BA.6010903@redhat.com> <53AC60F5.1080409@redhat.com> Message-ID: <53AD504D.7000001@redhat.com> On 26.6.2014 20:05, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 12.6.2014 09:49, Jan Cholasta wrote: >>> On 20.5.2014 21:38, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> On 25.4.2014 10:51, Jan Cholasta wrote: >>>>>> On 24.4.2014 23:16, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> On 10.4.2014 22:06, Rob Crittenden wrote: >>>>>>>>> Some in-line, a whole ton of data appended to end. >>>>>>>>> >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> On 7.4.2014 20:09, Rob Crittenden wrote: >>>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>>> >>>>>>>>>>>> 247 >>>>>>>>>>>> >>>>>>>>>>>> We've been burned by hardcoded timeouts in the past. Should >>>>>>>>>>>> this be >>>>>>>>>>>> configurable? This module doesn't currently do any logging >>>>>>>>>>>> but it >>>>>>>>>>>> might >>>>>>>>>>>> be worth spitting out a "waiting" message, at least for >>>>>>>>>>>> debugging. >>>>>>>>>> >>>>>>>>>> Added a timeout argument. >>>>>>>>> >>>>>>>>> Did you forget to send this one, I didn't see an update to 247. >>>>>>>> >>>>>>>> Are you sure you have 247.1 (now 247.2)? >>>>>>>> >>>>>>>> I can see at >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> that I have sent the correct version of the patches. >>>>>>> >>>>>>> The call has a timeout, the callers don't use it. I guess it'll do >>>>>>> for >>>>>>> now, but these almost always come back to bite us. >>>>>> >>>>>> Well, I can add --certmonger-timeout option to ipa-cacert-manage, if >>>>>> that's what you want. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 251 >>>>>>>>>>>> >>>>>>>>>>>> The tool should provide some feedback while it's running. For >>>>>>>>>>>> the >>>>>>>>>>>> impatient (me) it takes a really long time and it's hard to know >>>>>>>>>>>> what is >>>>>>>>>>>> going on, something in between nothing and full debug output. >>>>>>>>>> >>>>>>>>>> Added some messages about what's going on. >>>>>>>>> >>>>>>>>> I dpn't see an update to 251 either. >>>>>>>> >>>>>>>> Please make sure you have 251.1 (now 251.2). >>>>>>> >>>>>>> There is a little bit more output but there are still very long >>>>>>> periods >>>>>>> of waiting between any visual activity, particularly when doing it >>>>>>> on an >>>>>>> IPA self-signed CA. >>>>>> >>>>>> This stuff takes time :-) What would you like to see in the output, >>>>>> that's not already there? >>>>>> >>>>>>>>> >>>>>>>>> I think the ipa-cacert-manage man page is missing one really >>>>>>>>> important >>>>>>>>> piece: why would you ever need to run this? And when? >>>>>>>> >>>>>>>> Added a paragraph about this. >>>>>>> >>>>>>> It's better, couple of comments: >>>>>>> >>>>>>> Add "the" in between renew and CA in "used to manually renew CA >>>>>>> certificate of" and "When IPA CA...". >>>>>> >>>>>> OK. >>>>>> >>>>>>> I haven't had any luck renewing >>>>>>> the CA certificate yet. I see that it is tracked now. I started >>>>>>> moving >>>>>>> the system clock forward in order to get to renewal and about the 3rd >>>>>>> iteration the requests started failing with an XML error. Did you see >>>>>>> this? >>>>>>> >>>>>>> [Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback >>>>>>> (most >>>>>>> recent call last): >>>>>>> [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>>>>>> 344, in >>>>>>> wsgi_execute >>>>>>> [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = >>>>>>> self.Command[name](*args, **options) >>>>>>> [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>>>> __call__ >>>>>>> [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = >>>>>>> self.run(*args, **options) >>>>>>> [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>>>> run >>>>>>> [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = >>>>>>> self.execute(*args, **options) >>>>>>> [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>>>> 382, in >>>>>>> execute >>>>>>> [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = >>>>>>> api.Command['cert_show'](unicode(serial))['result'] >>>>>>> [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>>>>>> __call__ >>>>>>> [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = >>>>>>> self.run(*args, **options) >>>>>>> [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in >>>>>>> run >>>>>>> [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = >>>>>>> self.execute(*args, **options) >>>>>>> [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line >>>>>>> 514, in >>>>>>> execute >>>>>>> [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] >>>>>>> result=self.Backend.ra.get_certificate(serial_number) >>>>>>> [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>>>> 1502, in get_certificate >>>>>>> [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] >>>>>>> parse_result >>>>>>> = self.get_parse_result_xml(http_body, parse_display_cert_xml) >>>>>>> [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File >>>>>>> "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line >>>>>>> 1363, in get_parse_result_xml >>>>>>> [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = >>>>>>> etree.fromstring(xml_text, parser) >>>>>>> [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File >>>>>>> "lxml.etree.pyx", line 3032, in lxml.etree.fromstring >>>>>>> (src/lxml/lxml.etree.c:68129) >>>>>>> [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument >>>>>>> (src/lxml/lxml.etree.c:102493) >>>>>>> [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 1673, in lxml.etree._parseDoc >>>>>>> (src/lxml/lxml.etree.c:101322) >>>>>>> [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc >>>>>>> (src/lxml/lxml.etree.c:96504) >>>>>>> [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 582, in >>>>>>> lxml.etree._ParserContext._handleParseResultDoc >>>>>>> (src/lxml/lxml.etree.c:91308) >>>>>>> [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 683, in lxml.etree._handleParseResult >>>>>>> (src/lxml/lxml.etree.c:92494) >>>>>>> [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File >>>>>>> "parser.pxi", line 633, in lxml.etree._raiseParseError >>>>>>> (src/lxml/lxml.etree.c:91957) >>>>>>> [Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] >>>>>>> XMLSyntaxError: >>>>>>> None >>>>>>> [Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: >>>>>>> [xmlserver] host/lyra.greyoak.com at GREYOAK.COM: >>>>>>> cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/! W! > m! >>>>>>> >> 8! >>>>>>> >>> V! >>>> P! >>>>>>> >>>>> Z! >>>>>>> >>>>>> gm! >>>>>>> >>>>>>> 3VCtgMvPVk >>>>>>> 3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> principal=u'HTTP/lyra.greyoak.com at GREYOAK.COM', add=True, >>>>>>> version=u'2.51'): XMLSyntaxError >>>>>> >>>>>> I have never seen this. The error message does not say much... Is >>>>>> there >>>>>> anything interesting in other logs? >>>>> >>>>> I was able to get the CA certificate to be renewed after moving system >>>>> time forward step by step. >>>>> >>>>> One thing I haven't noticed before is that the renewed certificate's >>>>> validity never exceeds that of the original certificate. This is most >>>>> likely Dogtag issue (something along the lines of "certificate validity >>>>> cannot exceed validity of the CA certificate", except it shouldn't >>>>> apply >>>>> to the CA certificate itself). >>>>> >>>>> There were other issues here and there, all of them were caused by race >>>>> conditions between concurrent renewals (unreachable CA, XML syntax >>>>> errors, etc. because Dogtag was stopped by stop_pkicad in another >>>>> request, CMS internal error because it used old subsystem cert to >>>>> authenticate to LDAP while the cert was being renewed, etc.) and all of >>>>> them could be fixed by restarting relevant IPA services and >>>>> resubmitting >>>>> the requests manually. Some synchronization is really missing there. >>>> >>>> I hadn't noticed that, but my CA was issued externally so I expected >>>> this. I also saw the bumps during renewal but things always tended to >>>> smooth out, with the errors generally restricted to restarts and >>>> certmonger. This backtrace was the only thing that really stood out. >>>> IIRC at this point things were pretty much blocked. >>>> >>>> In any case, these patches basically seem to work. I never did work out >>>> whether the above error was due to dogtag, IPA or something else. >>>> >>>> rob >>> >>> Rebased the patches on top of current master. >>> >>> Give up retrieving certificate from LDAP in patch 265 after a few >>> unsuccessful attempts. This is to prevent certmonger requests from >>> staying in CA_WORKING state forever when you manually resubmit a request. >>> >>> Added patch 266 which adds ACIs missing after the permission refactoring. >> >> Rebased again. >> >> Converted all permissions to managed permissions. >> >> Added dependency on certmonger >= 0.74 in patch 251, because CSR export >> is broken with older versions. There is an update to certmonger 0.75.5 >> for F20: >> . >> (It segfaults for me during server install, I and Nalin are investigating.) >> Fixed in 0.75.6: > > I need a full set of patches, 241-299 from the same tree. Trying to > piece together more than 50 patches from three long threads is proving > impossible. OK, I will attach all the required unpushed patches in each of the subsequent threads from now on. (All of the patches I sent yesterday are from the same tree, so I don't really get why it is impossible to put them together.) > > Provided some feedback on 295-299 in that thread but I can't get much > applied so I can do any functional testing. > > rob Updated rebased patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.5-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.5-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.5-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.5-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.5-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.5-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.5-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.5-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.5-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.5-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.5-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.5-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.5-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.4-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.3-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.3-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.3-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.2-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 27 11:08:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 13:08:35 +0200 Subject: [Freeipa-devel] [PATCHES] 267-294 Support multiple CA certificates in LDAP In-Reply-To: <53AC2D03.6050206@redhat.com> References: <5399E749.6070806@redhat.com> <539F0593.9060007@redhat.com> <539F5552.9070005@redhat.com> <53AAAED7.7070705@redhat.com> <53AC2D03.6050206@redhat.com> Message-ID: <53AD50B3.7060101@redhat.com> On 26.6.2014 16:24, Rob Crittenden wrote: > Comments buried deep inline. > > Jan Cholasta wrote: >> On 16.6.2014 22:36, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches implement >>>>> and >>>>> . >>>>> >>>>> This work depends on my patches 241-253 and 262-266 >>>>> (). >>>>> >>>>> >>>>> Note that automatic distribution of CA certificates to IPA systems is >>>>> not implemented yet (it's planned for IPA 4.2, see >>>>> ), so /etc/ipa/ca.crt, >>>>> /etc/pki/nssdb, /etc/dirsrv/slapd-REALM and /etc/httpd/alias are >>>>> updated >>>>> *only* during client/server install. >>>> >>>> 267 >>>> >>>> What is the purpose of this change? Won't this cause no certificates to >>>> be exported in the default case? >>>> >>>> diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py >>>> index 61a954f..3cd7a53 100644 >>>> --- a/ipaserver/install/certs.py >>>> +++ b/ipaserver/install/certs.py >>>> @@ -463,7 +463,7 @@ class CertDB(object): >>>> do that step.""" >>>> # export the CA cert for use with other apps >>>> ipautil.backup_file(self.cacert_fname) >>>> - root_nicknames = self.find_root_cert(nickname) >>>> + root_nicknames = self.find_root_cert(nickname)[:-1] >>>> fd = open(self.cacert_fname, "w") >>>> for root in root_nicknames: >>>> (cert, stderr, returncode) = self.run_certutil(["-L", >>>> "-n", >>>> root, "-a"]) >>>> >>>> Or are you separating out issuing CA from the rest of the chain? >> >> find_root_cert() returns the certificate chain *including* the >> end-entity certificate. We want only CA certificates here. This is an >> error introduced in the CA-less rewrite. > > OK. > >> >>>> >>>> 268 ACK >>>> >>>> 269 ACK >>>> >>>> 270 >>>> >>>> If a user has their own CA installed, such as the case where they used >>>> ipa-server-certinstall, this will break it. >> >> You can't install own CA with ipa-server-certinstall. I did not see >> anything break. > > Sorry, I wasn't very clear. Imagine the case where the user has replaced > the server certificate in Apache with something issued by some other CA > that requires that some CA certificates also be installed. This is a > not-too-common but seen scenario, mostly to avoid having to trust the > IPA CA in browsers. > > The way I read fix_trust_flags() is that it would remove the trust from > unknown CA's which could cause the server to not start. IMHO you should > leave alone certs you don't know about. This is what fix_trust_flags() does: 1. set trust flags of all CA certs to ',,' 2. find all server certs, set trust flags for each of their issuing CA certs to 'C,,' 3. set trust flags of the IPA CA cert to 'CT,C,C' (The code does this a little bit different, but the result is exactly the same.) So even if you install a custom server and CA certificate, the CA certificate will be trusted and the server will start. > >> >>>> >>>> What can be in the other set? Docs are needed. >> >> The "trusted" set is for trusted CA certs and the "other" set is for >> other CA certs. I will add a comment... >> >>>> >>>> You potentially add a bunch of certs with no trust, what is the purpose? >> >> "No trust" in this context means "trust only for issuing CA >> certificates". The certs are there for the sole purpose of forming the >> CA chain, so they don't need to be trusted for anything else. >> >>>> >>>> 271 >>>> >>>> ipaSecretKey isn't mentioned on >>>> http://www.freeipa.org/page/V4/CA_certificate_renewal . What is it and >>>> does it need to be added now? >> >> This is the schema from >> . >> It is shared with DNSSEC. I will add a comment. >> >>>> >>>> 272 ACK >>>> >>>> 273 ACK >>>> >>>> 274 ACK >>>> >>>> 275 ACK >>>> >>>> 276 >>>> >>>> There isn't any error handling around the ASN.1 decoder. Is that wise? >> >> Probably not, but it's consistent with the rest of the x509 module - >> none of its functions do error handling, it is up to the caller. >> >> BTW I have started refactoring x509 code, but didn't have time to >> finish. The new code will include error handling. > > Well, sure, but it isn't doing ASN.1 decoding of raw certs either. A lot > can go wrong there. *All* of the code in x509 does ASN.1 encoding, why should it matter if it is done inside NSS or using pyasn1? A lot can go wrong in both, in which case NSS raises NSPRError and pyasn1 raises PyAsn1Error - not much of a difference if you ask me. > >>>> >>>> There should be unit tests >> >> Yes. >> >>>> >>>> 277 >>>> >>>> There should be unit tests >> >> Yes. >> >>>> >>>> 278 >>>> >>>> When the certificate must be passed in as DER can you use dercert as the >>>> argument name so it's clear what is needed? >> >> OK. >> >>>> >>>> In update_ca_cert() and get_ca_certs() should the values for trust be >>>> case insensitive? >> >> It already is in update_ca_cert(), but get_ca_certs() does indeed need >> to be fixed. >> >>>> >>>> This breaks the convention where attribute names are always lower-case. >> >> I wasn't aware there is such a convention, especially so after seeing >> loads of mixed case attribute names all over IPA code. >> >> Anyway, I don't think it matters anymore, the new LDAP code has >> case-insensitive attribute names. > > Ok, I won't fight it, but look in ipalib/plugins. The majority of > objectclasses/attributes are lower case. Anything otherwise was missed > in review. Well, certstore is not a plugin. If you look in installer code, where it is used most, there is a lot of mixed case attribute names. (But as I already said, case does not matter anymore.) > >> >>>> >>>> I can't really grok add_ca_cert(). You are adding certs but removing >>>> values? Is this un-setting the list of trusted CA's maybe? >> >> It is unsetting ipaConfigString values from entries that should no >> longer have them. I will add a comment. >> >>>> >>>> There isn't a single comment in this file beyond the header. >> >> Sorry, will fix. >> >>>> >>>> 279 >>>> >>>> Looks ok >>>> >>>> 280 >>>> >>>> Why add the chain with no trust? >> >> See my comment for patch 270. > > OK > >> >>>> >>>> 281 / 282 >>>> >>>> What is the difference between add_cert and import_cert other than >>>> passing in trust and not having the db password? Do we even need >>>> add_single_pem_cert anymore? >> >> add_cert adds certificate by value, import_cert loads it from a file. We >> don't need add_single_pem_cert anymore. >> >>>> >>>> 283 / 284 >>>> >>>> In __import_ca_certs() I assume the pass is there for NotFound for the >>>> case of creating a replica with an older master that doesn't have these? >>>> How is SSL trust setup then? >> >> It is for the case where there is no cn=certificates nor cn=CAcert. The >> trust is setup as usual, failed import does not affect it. >> >>>> >>>> This code looks awfully similar. >> >> Will fix. >> >>>> >>>> 285 >>>> >>>> ACK >>>> >>>> 286 >>>> >>>> It looks ok, just one wild thought. If writing the certificate fails and >>>> you go to clean up by removing ca_file, what if that removal fails, for >>>> the same reason the write failed, SELinux for example? >> >> Good point, will fix. >> >>>> >>>> 287 >>>> >>>> If this weren't addressed in a later patch I've have dinged you on the: >>>> >>>> + return [cert] >>>> >>>> There are some places where you pluralize the variables (certs) and >>>> others where you do not (ca_cert, existing_ca_cert). >> >> Right, will fix. >> >>>> >>>> 288 >>>> >>>> Is a rawcert a dercert? I'd use that name instead for consistency. >> >> It can be both DER or PEM, I used it for consistency with >> write_certificate(). > > Ok. John was all over me long ago for using rather generic names for > cert values with the contents being implicit. This is why there are > type=PEM/DER options and explicit variable names. It does help a > newcomer get a handle on what is going on without having to read a lot > of extra code. I plan on encapsulating certificates into objects, so that we can get rid of all of this messy certificate strings + global functions stuff. Once it's done, there will be only "cert" ;-) > >>>> >>>> normalize_certificate() can raise exceptions. Those should be handled in >>>> write_certificate_list() >> >> Actually they should be handled by the caller, the same way as with >> write_certificate(). (See my comment for patch 276.) > > Ok I guess, but only because install_ca_cert() is called so early in the > replica install process. I suppose that missing a CA would be rather > catastrophic and things need to stop, not super happy about catching > broad Exception. Me too, but nobody complained over the years. > >>>> >>>> 289 >>>> >>>> ACK >>>> >>>> 290 >>>> >>>> This can be dangerous because if another database is opened in the >>>> process things may fail. Additional warnings and red flags should be >>>> provided, or the context should be compared to known places this will >>>> blow up (e.g server). >> >> This is used only in ipa-client-install (in patch 291) and it does not >> blow up. > > Yes, I saw that too, but I think a comment should be added that this can > be dangerous so some doesn't stumble upon this and try to use it in the > future, at least not until we switch to using NSS contexts. OK. > >>>> >>>> 291 >>>> >>>> You use a temporary database to make cleanup easier I suppose? Did you >>>> test this in enforcing? >> >> Yes, it works fine. > > Ok, wasn't sure what the contexts would be. > >>>> >>>> 292 >>>> >>>> Need unit tests >> >> OK. >> >>>> >>>> 293 >>>> >>>> Why the fixme for the x509 import? >> >> Because it's import from ipalib to ipapython. > > Ok, I guess I'd expand on it so it's more obvious. OK. > Is there a ticket > open to move it to ipapython? I'm not aware of one. > >>>> >>>> Isn't this changing already published API for >>>> [insert|remove]_ca_cert_into_systemwide_ca_store? >> >> Yes. I don't think this is a public API and it is changed in Tom??'s >> platform code refactoring anyway. > > ok > >> >>>> >>>> 294 >>>> >>>> Can you change the old occurances of >>>> >>>> cafile = config.dir + "/ca.crt" >>>> >>>> to use CACERT instead? >> >> No, config.dir is the directory where the replica info is unpacked, not >> "/etc/ipa". > > Ah right. Ok. > >> >>>> >>>> Bad case in exception, "Ca cert file is not available". Is there any >>>> additional information we can provide, like what to do about it and >>>> where we looked? >> >> Maybe. This code is cut-and-pasted from install_ca_cert(), I did not >> touch it otherwise. > > Maybe fix both? OK. > >>>> >>>> You actually remove one occurrence of CACERT and replace it with a >>>> hardcoded path, is that on purpose? >> >> Yes. Currently, the CA certificate from the replica info is copied >> directly to /etc/ipa/ca.crt, but I want to use it only for connecting to >> LDAP and use whatever is in there to create /etc/ipa/ca.crt. > > OK > >> >>>> >>>> --- >>>> >>>> I still need to do functional testing and will probably take another >>>> pass the changes through but this patchset generally looks ok. >>> >>> Several issues found during testing: >>> >>> 1. Enrollment from RHEL-5 fails because the entire cert chain is not >>> retrieved, only the issuing CA cert. >>> >>> Joining realm failed: libcurl failed to execute the HTTP POST >>> transaction. SSL certificate problem, verify that the CA cert is OK. >>> Details: >>> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate >>> verify failed >>> Installation failed. Rolling back changes. >> >> I couldn't reproduce this, I have the full certificate chain in >> http:///ipa/config/ca.crt. >> >>> >>> 2. Not quite sure the cause, but this is on a replica: >>> >>> # ldapsearch -x -Z >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> ldap_start_tls: Operations error (1) >>> additional info: SSL connection already established. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base (default) with scope subtree >>> # filter: (objectclass=*) >>> >>> Same command on initial master doesn't spit out the p11-kit errors. >>> >>> Get similar errors out of certutil: >>> >>> # certutil -L -d /etc/httpd/alias >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> p11-kit: invalid basic constraints certificate extension >>> >>> Certificate Nickname Trust >>> Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> >>> GREYOAK.COM IPA CA CT,C,C >>> Server-Cert u,u,u >>> CN=External Authority ,, >>> ipaCert u,u,u >>> >>> Same version of p11-kit on both machines. >>> >>> p11-kit-trust-0.20.2-1.fc20.x86_64 >>> p11-kit-0.20.2-1.fc20.x86_64 >> >> This does not happen for me. I don't touch basic constraints anywhere in >> the code. Can I see the "CN=External Authority" certificate? > > -----BEGIN CERTIFICATE----- > MIIB5jCCAU+gAwIBAgIBADANBgkqhkiG9w0BAQUFADAdMRswGQYDVQQDExJFeHRl > cm5hbCBBdXRob3JpdHkwHhcNMTAwNDAxMTg0MDA1WhcNMTUwNDAxMTg0MDA1WjAd > MRswGQYDVQQDExJFeHRlcm5hbCBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQAD > gY0AMIGJAoGBAMU/XhUTSym+9O7emUkQ8ZAHz3wC+6q0QX+BmQTDPoorbueM51HT > ZnG88QbiocU6EEr2KWCJjw692HDnf9o+L4t5xiUwn5pObcgNp/nqfX0K+vfcw/wN > 1bU+dWACiDk2bi5+CCKpZDUbO+9kMVIQXmKmSaqhdoXmVgiDymi4/HQZAgMBAAGj > NjA0MBEGCWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB > /wQEAwICxDANBgkqhkiG9w0BAQUFAAOBgQCitCb19cGgqdJu0rPkUXFsJlqWJ1OQ > ++4iKCPmwflN3FoVrrwVmOcvr+zvZsG2Szt4BpwvxItOHR0sL/++egGUrHY5Fb0t > Dbroovs7TgnTlkcf/1PDcV0jM3TaIZKVEiKH4c+0Hpy/aGYgMWG6gm7LwyCjhNYj > MSWA/5N6caTD/g== > -----END CERTIFICATE----- I still don't see p11-kit complaining. Does it still happen with the latest version of my patches? > >>> 3. On uninstall the CA's are not removed from /etc/pki/nssdb and >>> /etc/httpd/alias in one of my tests (the first one, so I no longer have >>> the logs). >> >> Will fix. >> >>> >>> 4. This one isn't your issue AFAICT, not sure if you've seen this one: >>> >>> # ipa-ca-install ... >>> >>> [snip] >>> >>> 2014-06-16T18:07:44Z DEBUG stdout=Loading deployment configuration from >>> /tmp/tmprI2isq. >>> >>> 2014-06-16T18:07:44Z DEBUG stderr=Traceback (most recent call last): >>> File "/usr/sbin/pkispawn", line 530, in >>> main(sys.argv) >>> File "/usr/sbin/pkispawn", line 439, in main >>> info = parser.sd_get_info() >>> File >>> "/usr/lib/python2.7/site-packages/pki/server/deployment/pkiparser.py", >>> line 442, in sd_get_info >>> info = sd.getSecurityDomainInfo() >>> File "/usr/lib/python2.7/site-packages/pki/system.py", line 40, in >>> getSecurityDomainInfo >>> info.name = j['DomainInfo']['@id'] >>> KeyError: 'DomainInfo' >>> >>> 2014-06-16T18:07:44Z CRITICAL failed to configure ca instance Command >>> ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmprI2isq'' returned non-zero >>> exit status 1 >>> 2014-06-16T18:07:44Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 639, in run_script >>> return_value = main_function() >> >> I haven't seen this one. Can it be reproduced? > > Not sure. I'll see if I can make time to try to reproduce and will file > a ticket if I can. OK, thanks. > >>> >>> 5. This one may be for Tomas, but: >>> >>> 2014-06-16T19:01:28Z INFO Deleting schedule 2358-2359 0 from agreement >>> cn=meTogrindle.greyoak.com,cn=replica,cn=dc\=greyoak\,dc\=com,cn=mapping >>> tree,cn=config >>> 2014-06-16T19:01:29Z ERROR unable to convert the attribute >>> u'nsds5replicalastupdateend' value '0' to type >>> 2014-06-16T19:01:29Z INFO Replication Update in progress: TRUE: status: >>> 0 Replica acquired successfully: Incremental update started: start: 0: >>> end: 0 >>> 2014-06-16T19:01:30Z ERROR unable to convert the attribute >>> u'nsds5replicalastupdateend' value '0' to type >>> 2014-06-16T19:01:30Z INFO Replication Update in progress: TRUE: status: >>> 0 Replica acquired successfully: Incremental update started: start: 0: >>> end: 0 >>> 2014-06-16T19:01:31Z ERROR unable to convert the attribute >>> u'nsds5replicalastupdateend' value '0' to type >>> 2014-06-16T19:01:31Z INFO Replication Update in progress: TRUE: status: >>> 0 Replica acquired successfully: Incremental update started: start: 0: >>> end: 0 >>> 2014-06-16T19:01:32Z ERROR unable to convert the attribute >>> u'nsds5replicalastupdateend' value '0' to type >>> 2014-06-16T19:01:32Z INFO Replication Update in progress: TRUE: status: >>> 0 Replica acquired successfully: Incremental update started: start: 0: >>> end: 0 >> >> I believe this is . >> >>> >>> 6. With an external CA install of F-20 vanilla, upgraded to this patch, >>> the external CA is not added to /etc/pki/nssdb. On a pure install of >>> this patch, it is added. Not sure if we care since the cert is in the >>> global cert store. >> >> Yes, that's one of the effects of "automatic distribution to clients is >> not implemented yet". > > But this is on an IPA Master so we have a bit more control over things. > Can't this be added to ipa-upgradeconfig at least? I don't really want to introduce a server-specific code path for this. It should be done during client update, but we still don't have a script for this :-/ Would running the client CA update tool manually be OK? > >>> >>> 7. Something for the future, but I wonder if test test_0002_find_CA in >>> ipatests/test_xmlrpc/test_cert_plugin.py should be able to handle >>> external CAs. >>> >>> rob >>> >> >> > Added new patch 303 with client certificate update tool. Updated rebased patches attached. Also attaching all the required patches. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.5-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.5-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.5-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.5-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.5-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.5-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.5-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.5-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.5-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.5-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.5-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.5-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.5-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.4-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.3-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.3-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.3-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.2-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.2-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.2-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.2-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.2-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 9990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.2-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 4169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.2-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.2-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.2-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.2-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 13369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.2-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.2-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.2-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 14520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.2-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.2-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.2-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.2-Add-new-add_cert-method-for-adding-certificates-to-N.patch Type: text/x-patch Size: 3420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.2-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.2-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.2-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.2-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.2-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.2-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 3612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.2-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.2-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.2-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.2-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.2-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.2-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3326 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-303-Add-client-certificate-update-tool-ipa-certupdate.patch Type: text/x-patch Size: 8001 bytes Desc: not available URL: From jcholast at redhat.com Fri Jun 27 11:09:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 27 Jun 2014 13:09:54 +0200 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53AC60F9.9030900@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> Message-ID: <53AD5102.1000302@redhat.com> On 26.6.2014 20:05, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 16.6.2014 15:35, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches implement >>> . >>> >>> My patches 241-253 and 262-294 are required for this >>> (, >>> ). >>> >>> The installation/testing guidelines from >>> >>> apply here as well. >>> >>> Honza >> >> Rebased on top of current master. > > 295 ACK > > 296, 297 & 299 > > TBD, need to test but no problems seen so far. > > 298 > > The man page, if not usage, should include what the valid trust flags > are or point to NSS documentation. OK. > > rob > Updated rebased patches attached. Also attaching all the required patches. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241.5-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242.5-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 3220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243.5-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1077 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244.5-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245.5-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246.5-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 2471 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247.5-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 2097 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248.5-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 5954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249.5-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250.5-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 4088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251.5-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 17469 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252.5-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253.5-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1341 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-262.4-Pick-new-CA-renewal-master-when-deleting-a-replica.patch Type: text/x-patch Size: 3778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-263.3-Remove-master-ACIs-when-deleting-a-replica.patch Type: text/x-patch Size: 2614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-264.3-Do-not-use-ldapi-in-certificate-renewal-scripts.patch Type: text/x-patch Size: 12106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-265.3-Check-that-renewed-certificates-coming-from-LDAP-are.patch Type: text/x-patch Size: 2898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-266.2-Allow-IPA-master-hosts-to-read-and-update-IPA-master.patch Type: text/x-patch Size: 3191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-267.2-Do-not-treat-the-IPA-RA-cert-as-CA-cert-in-DS-NSS-da.patch Type: text/x-patch Size: 3572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-268.2-Remove-certificate-External-CA-cert-from-etc-pki-nss.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-269.2-Allow-specifying-trust-flags-in-NSSDatabase-and-Cert.patch Type: text/x-patch Size: 1986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-270.2-Fix-trust-flags-in-HTTP-and-DS-NSS-databases.patch Type: text/x-patch Size: 9990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-271.2-Add-LDAP-schema-for-wrapped-cryptographic-keys.patch Type: text/x-patch Size: 4169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-272.2-Add-LDAP-schema-for-certificate-store.patch Type: text/x-patch Size: 3425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-273.2-Add-container-for-certificate-store.patch Type: text/x-patch Size: 1852 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-274.2-Configure-attribute-uniqueness-for-certificate-store.patch Type: text/x-patch Size: 2379 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-275.2-Add-permissions-for-certificate-store.patch Type: text/x-patch Size: 13369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-276.2-Add-functions-for-extracting-certificates-fields-in-.patch Type: text/x-patch Size: 3376 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-277.2-Add-function-for-extracting-extended-key-usage-from-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-278.2-Add-certificate-store-module-ipalib.certstore.patch Type: text/x-patch Size: 14520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-279.2-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3206 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-280.2-Upload-CA-chain-from-DS-NSS-database-to-certificate-.patch Type: text/x-patch Size: 3815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-281.2-Rename-CertDB-method-add_cert-to-import_cert.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-282.2-Add-new-add_cert-method-for-adding-certificates-to-N.patch Type: text/x-patch Size: 3420 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-283.2-Import-CA-certs-from-certificate-store-to-DS-NSS-dat.patch Type: text/x-patch Size: 3020 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-284.2-Import-CA-certs-from-certificate-store-to-HTTP-NSS-d.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-285.2-Upload-renewed-CA-cert-to-certificate-store-on-renew.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-286.2-Refactor-CA-certificate-fetching-code-in-ipa-client-.patch Type: text/x-patch Size: 7364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-287.2-Support-multiple-CA-certificates-in-etc-ipa-ca.crt-i.patch Type: text/x-patch Size: 11021 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-288.2-Add-function-for-writing-list-of-certificates-to-a-P.patch Type: text/x-patch Size: 3612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-289.2-Get-CA-certs-for-etc-ipa-ca.crt-from-certificate-sto.patch Type: text/x-patch Size: 4372 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-290.2-Allow-overriding-NSS-database-path-in-RPCClient.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-291.2-Get-CA-certs-for-etc-pki-nssdb-from-certificate-stor.patch Type: text/x-patch Size: 10851 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-292.2-Add-functions-for-DER-encoding-certificate-extension.patch Type: text/x-patch Size: 1790 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-293.2-Get-CA-certs-for-system-wide-store-from-cert-store-i.patch Type: text/x-patch Size: 10220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-294.2-Get-up-to-date-CA-certificates-from-certificate-stor.patch Type: text/x-patch Size: 3326 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-295.2-Add-new-NSSDatabase-method-get_cert-for-getting-cert.patch Type: text/x-patch Size: 1465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-296.2-Allow-changing-chaining-of-the-IPA-CA-certificate-in.patch Type: text/x-patch Size: 5791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-297.2-Update-CS.cfg-on-IPA-CA-certificate-chaining-change-.patch Type: text/x-patch Size: 3067 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-298.2-Allow-adding-CA-certificates-to-certificate-store-in.patch Type: text/x-patch Size: 5613 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-299.2-Allow-upgrading-CA-less-to-CA-full-using-ipa-ca-inst.patch Type: text/x-patch Size: 14029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-303-Add-client-certificate-update-tool-ipa-certupdate.patch Type: text/x-patch Size: 8001 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 27 11:23:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 13:23:14 +0200 Subject: [Freeipa-devel] 4.0 schema in 60basev3.ldif? Message-ID: <53AD5422.3070606@redhat.com> It seems to me that we are being inconsistent with regards to our FreeIPA version and the schema files. We now have 60basev2.ldif containing FreeIPA 2.x schema, 60basev3.ldif containing FreeIPA 3.x schema. However, we now also added FreeIPA 4.x schema to 60basev3.ldif which seems as an inconsistency to me. Should we simply create 60basev4.ldif and move the new schema (mostly permissionsv2 related) there? I am wondering that in that case we may also think about making a new OID space for v4 schema as current one is defined as ## Attributes: 2.16.840.1.113730.3.8.11 - V3 base attributres ## ObjectClasses: 2.16.840.1.113730.3.8.12 - V3 base objectclasses If we ever want to fix the OID space, now is the right time, it won't be possible after release. Alternatively, we could also define 2.16.840.1.113730.3.8.11 and 2.16.840.1.113730.3.8.12 as "V3+" space. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Fri Jun 27 11:39:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 13:39:54 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <1403708844.2323.8.camel@unused-4-145.brq.redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> <53A98D08.1090005@redhat.com> <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> <53AAC23E.2050406@redhat.com> <1403708844.2323.8.camel@unused-4-145.brq.redhat.com> Message-ID: <53AD580A.9040007@redhat.com> On 06/25/2014 05:07 PM, Martin Basti wrote: > On Wed, 2014-06-25 at 14:36 +0200, Martin Kosek wrote: >> On 06/24/2014 04:52 PM, Martin Basti wrote: >>> On Tue, 2014-06-24 at 16:36 +0200, Martin Kosek wrote: >>>> On 06/18/2014 01:46 PM, Martin Basti wrote: >>>>> On Wed, 2014-06-18 at 13:44 +0200, Martin Basti wrote: >>>>>> On Fri, 2014-06-13 at 10:28 +0200, Martin Basti wrote: >>>>>>> Patches attached, require patches mbasti 0052-0055. >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> Rebased patches attached. >>>>>> PEP8 fixes. >>>>>> >>>>> Sorry, patches are here >>>> >>>> 66.2: >>>> >>>> 1) Is it OK to just change constants in the update plugins? >>>> >>>> -PRE_UPDATE = 1 >>>> -POST_UPDATE = 2 >>>> +PRE_SCHEMA_UPDATE = 1 >>>> +PRE_UPDATE = 2 >>>> +POST_UPDATE = 3 >>>> >>>> When people refer to the types via names, it should be OK. It just seemed >>>> unnecessary to me. >>>> >>> I checked where the constants are used, and it shouldn't broke anything. >>> It looks weird to me to have something which happens first with last >>> number. >>> Should I set PRE_SCHEMA_UPDATE = 3 and leave other unchanged then? >> >> Ok, either update it or set it to 0. Up to you. >> >>> >>>> 67.2: >>>> >>>> 1) update_check_forwardzones: >>>> >>>> I think we should set update_to_forward_zones to False when the objectclass is >>>> there and add a check at the beginning of the execute to simply bail out, if >>>> update_to_forward_zones is present in the sysupgrade file. >>>> >>>> This will prevent the objectclass check (which takes some time) to run again >>>> and again. >>> Good point thanks. >>> >>>> 2) I would use different backup name: >>>> >>>> + backup_filename = u'master-zones-transform-backup.ldif' >>>> >>>> Probably something based on time so that different installations' backup do not >>>> step on each other. You can inspire yourself in other backup files we create: >>>> >>>> # ll /var/lib/ipa/backup/ >>>> total 16 >>>> drwx------. 2 root root 4096 May 30 08:10 ipa-full-2014-05-30-08-10-13 >>>> drwx------. 2 root root 4096 May 30 08:11 ipa-full-2014-05-30-08-11-09 >>>> drwx------. 2 root root 4096 May 30 08:13 ipa-full-2014-05-30-08-13-21 >>>> -rw-r--r--. 1 root root 3441 Jun 24 16:25 master-zones-transform-backup.ldif >>> Is this better: forward-zones-transform-%datetime%.ldif ? >> >> It is. I would do something like "dns-forward-zones-backup-YYYY-MM-DD.ldif to >> match existing files. >> >> Martin > > Updated patches attached > 1) This is not how you compare bool singletons in Python: + if state == False: + # no upgrade is needed + return (False, False, []) Rather use "state is False" Besides that, the upgrade worked fine for me (after I applied my patch 471. So if you change that one issue, I am willing to ack. Martin From mkosek at redhat.com Fri Jun 27 11:41:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 13:41:14 +0200 Subject: [Freeipa-devel] [PATCH] 471 Fix objectClass casing in LDIF to prevent schema update error Message-ID: <53AD585A.9050502@redhat.com> When a new objectclass was defined as "objectclass" and not "objectClass", it made the schema updater skip some objectclasses. https://fedorahosted.org/freeipa/ticket/4405 --- This fixed the 3.3.5 -> 4.0 upgrade for me. The root cause is quite strange for me though and I am not sure if this is intended. I assume there may be other issue in updater or python-ldap. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-471-fix-objectclass-casing-in-ldif-to-prevent-schema-upd.patch Type: text/x-patch Size: 1839 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 27 12:11:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 14:11:47 +0200 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons Message-ID: <53AD5F83.5040003@redhat.com> Make the label of these buttons consistent with other buttons which have capital first letters. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0692-webui-capitalize-labels-of-undo-and-undo-all-buttons.patch Type: text/x-patch Size: 2000 bytes Desc: not available URL: From pvoborni at redhat.com Fri Jun 27 12:20:02 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 14:20:02 +0200 Subject: [Freeipa-devel] [PATCH] 670-675 webui: dns forward zones In-Reply-To: <53ACF444.60803@redhat.com> References: <53A95AD0.5060905@redhat.com> <53A98DAF.9000306@redhat.com> <53ACF444.60803@redhat.com> Message-ID: <53AD6172.8030700@redhat.com> On 27.6.2014 06:34, Endi Sukma Dewata wrote: > On 6/24/2014 9:39 AM, Petr Vobornik wrote: >> On 24.6.2014 13:02, Petr Vobornik wrote: >>> ticket: https://fedorahosted.org/freeipa/ticket/4357 >>> >>> - patch 673 is compressed >>> - CI patches functionally depends on #667, #668 >>> >>> == PATCH] 670 webui: add confirmation for dns zone permission actions == >>> All header actions should require confirmation. >>> >>> == [PATCH] 671 webui: dns forward zones == >>> Add DNS Forward Zones Web UI. >>> >>> - pages under: Identity/DNS/DNS Forward Zones >>> >>> == [PATCH] 672 webui-ci: dns forward zone tests == >>> Selenium CI sanity tests for DNS Forward Zones >>> >>> == [PATCH] 673 webui-test: static metadata update == >>> Regular update of static metadata for testing and presentation purposes. >>> It should also contain new DNS Forward Zones metadata. >>> >>> == [PATCH] 674 webui-test: dns forward zone json data == >>> Fake API results for testing and presentation purposes of DNS Forward >>> Zones. >>> >>> == [PATCH] 675 webui: fix detection of RPC command == >>> old detection did not work with the static version used for test and >>> demonstration purposes. >> >> Attaching an updated version of #675 with a fix for unit tests. > > ACK. Some comments below. Pushed to master: * 8ca5793160cf24268c405e51b0bb8ce267608b6b webui: add confirmation for dns zone permission actions * 7a25168a3ceb8677a01b3bce6d2c10ac52d4d584 webui: dns forward zones * c7c13965e3604ea3f51684875ba252cc2d8bfbf1 webui-ci: dns forward zone tests * db2666d276ae60f2c3f1f5f1eaec87e55e32bf81 webui-test: static metadata update * e6a373e930ae483bc2eb384da0bba5f2b4b8f6c2 webui-test: dns forward zone json data * 59f66a156be393dba92ab6ca999cdc39c6787c36 webui: fix detection of RPC command > >> Btw I'm >> not very satisfied with patch #675's approach. I'm open to suggestions >> for better approaches. > > How about adding another parameter to get_record() to indicate the type > of the data? > > Possible improvements: > > 1. In the Add DNS Forward Zone dialog, if the "Zone forwarders" is empty > and you click Add, there is no error message. new ticket: https://fedorahosted.org/freeipa/ticket/4406 > > 2. In the same dialog, by default there probably should be an empty > field to enter the "Zone forwarders" because it's required. The admin > can click Add to add additional forwarders. my patch #681 fixes it > > 3. The permission name is only displayed briefly after creation. It > would be nice to display the permission name or a link to it in the > details page. Interesting idea. The same applies for Master DNS Zones. > > 4. Unrelated. Should "undo" and "undo all" be capitalized? They seem to > be inconsistent with other buttons. > Fixed in new patch #692 -- Petr Vobornik From pvoborni at redhat.com Fri Jun 27 12:25:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 14:25:19 +0200 Subject: [Freeipa-devel] [PATCH] 678-679 webui: send API version in RPC requests and adapt to new response format In-Reply-To: <53ACF453.1080209@redhat.com> References: <53AAD3F6.3070101@redhat.com> <53ACF453.1080209@redhat.com> Message-ID: <53AD62AF.8010709@redhat.com> On 27.6.2014 06:34, Endi Sukma Dewata wrote: > On 6/25/2014 8:51 AM, Petr Vobornik wrote: >> ticket: https://fedorahosted.org/freeipa/ticket/4394 >> >> == [PATCH] 678 webui: send API version in RPC requests == >> Currently there is an incorrect behavior that server doesn't send >> datetime >> and dnsname data in new format. >> >> This patch adds the version to each RPC request making the UI look as >> the >> latest client. Server then sends data in correct format. It also removes >> the "unknown version" warning from each RPC response. >> >> >> == [PATCH] 679 webui: extract rpc value from object envelope == >> adapt Web UI to a newer style of encapsulation object data > > ACK. > pushed to master: * 9aac0524c9adb714aa63113fa6b8436e7636e8c2 webui: send API version in RPC requests * 5568e357d103bafaf9e2f7f1ba1fd507c89e0538 webui: extract rpc value from object envelope -- Petr Vobornik From pvoborni at redhat.com Fri Jun 27 12:30:45 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 14:30:45 +0200 Subject: [Freeipa-devel] [PATCH] 677 webui: support unlock user command In-Reply-To: <53A99CC9.1070905@redhat.com> References: <53A99CC9.1070905@redhat.com> Message-ID: <53AD63F5.40104@redhat.com> On 24.6.2014 17:44, Petr Vobornik wrote: > Call user-unlock command from Web UI. > > It will unlock displayed user on current master. > > related to: > https://fedorahosted.org/freeipa/ticket/2792 > This effort has a new ticket: https://fedorahosted.org/freeipa/ticket/4407 Updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0677-1-webui-support-unlock-user-command.patch Type: text/x-patch Size: 3903 bytes Desc: not available URL: From mbasti at redhat.com Fri Jun 27 12:45:15 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Jun 2014 14:45:15 +0200 Subject: [Freeipa-devel] [PATCHES 0066-0067] Upgrade procedure for forwardzones In-Reply-To: <53AD580A.9040007@redhat.com> References: <1402648099.2292.5.camel@unused-4-145.brq.redhat.com> <1403091882.20101.6.camel@unused-4-145.brq.redhat.com> <1403091970.20101.7.camel@unused-4-145.brq.redhat.com> <53A98D08.1090005@redhat.com> <1403621532.14995.7.camel@unused-4-145.brq.redhat.com> <53AAC23E.2050406@redhat.com> <1403708844.2323.8.camel@unused-4-145.brq.redhat.com> <53AD580A.9040007@redhat.com> Message-ID: <1403873115.2249.4.camel@unused-4-145.brq.redhat.com> > 1) This is not how you compare bool singletons in Python: > > + if state == False: > + # no upgrade is needed > + return (False, False, []) > > Rather use "state is False" > > Besides that, the upgrade worked fine for me (after I applied my patch 471. So > if you change that one issue, I am willing to ack. > > Martin Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0067-3-Upgrade-special-master-zones-to-forward-zones.patch Type: text/x-patch Size: 9237 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0066-2-Added-upgrade-step-executed-before-schmema-is-upgrad.patch Type: text/x-patch Size: 6622 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 27 12:51:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 14:51:10 +0200 Subject: [Freeipa-devel] DNSSEC postponed to FreeIPA 4.1 Message-ID: <53AD68BE.8050002@redhat.com> Given that FreeIPA 4.0 is about to be released in near days and there are still security concerns and related developers about secure key exchange, I decided to move the feature to FreeIPA 4.1 to give it more time to bake. See details in https://fedorahosted.org/freeipa/ticket/3801#comment:25. In FreeIPA 4.0 we would still like to do at least an experimental support with providing manual procedure how to generate the DNSSEC signing keys and how to distribute them between replicas. This is about to be automated in next version. New experimental DNSSEC support RFE with detailed scope: https://fedorahosted.org/freeipa/ticket/4408 Please tell me if there are any concerns or updates. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mbasti at redhat.com Fri Jun 27 12:55:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Jun 2014 14:55:46 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSSEC: Add TLSA record In-Reply-To: <53AC0AAA.1090403@redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> <53AC0AAA.1090403@redhat.com> Message-ID: <1403873746.2249.5.camel@unused-4-145.brq.redhat.com> On Thu, 2014-06-26 at 13:57 +0200, Petr Vobornik wrote: > On 25.6.2014 14:35, Martin Basti wrote: > > On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: > >> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 > >> Patches attached. > >> > >> Note: ACI will be updated in another patch which fix ACIs in DNS plugin > > > > Patches are here > > > What are patch 0078's dependencies? I'm missing necessary blobs.. > (current master). Also it requires rebase because of today's pushes to > master (VERSION conflict). Rebased patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0078-2-DNSSEC-add-TLSA-record-type.patch Type: text/x-patch Size: 22881 bytes Desc: not available URL: From ssorce at redhat.com Fri Jun 27 13:18:19 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 27 Jun 2014 09:18:19 -0400 Subject: [Freeipa-devel] 4.0 schema in 60basev3.ldif? In-Reply-To: <53AD5422.3070606@redhat.com> References: <53AD5422.3070606@redhat.com> Message-ID: <1403875099.3551.7.camel@willson.usersys.redhat.com> On Fri, 2014-06-27 at 13:23 +0200, Martin Kosek wrote: > It seems to me that we are being inconsistent with regards to our FreeIPA > version and the schema files. > > We now have 60basev2.ldif containing FreeIPA 2.x schema, 60basev3.ldif > containing FreeIPA 3.x schema. However, we now also added FreeIPA 4.x schema to > 60basev3.ldif which seems as an inconsistency to me. > > Should we simply create 60basev4.ldif and move the new schema (mostly > permissionsv2 related) there? If you think it make sense go ahead and do it. I think we kept everything in the same file because at some point we changed (by adding MAY attributes) older objectclasses and these modifications were made before we decided to change version numbers to 4.0, but I find this mostly cosmetic so I do not really care one way or the other. > I am wondering that in that case we may also > think about making a new OID space for v4 schema as current one is defined as > > ## Attributes: 2.16.840.1.113730.3.8.11 - V3 base attributres > ## ObjectClasses: 2.16.840.1.113730.3.8.12 - V3 base objectclasses > > If we ever want to fix the OID space, now is the right time, it won't be > possible after release. Alternatively, we could also define > 2.16.840.1.113730.3.8.11 and 2.16.840.1.113730.3.8.12 as "V3+" space. I do not think it makes any sense to change OID space now. Feel free to mark the space as V3+ Simo. From pspacek at redhat.com Fri Jun 27 13:24:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 15:24:10 +0200 Subject: [Freeipa-devel] 4.0 schema in 60basev3.ldif? In-Reply-To: <1403875099.3551.7.camel@willson.usersys.redhat.com> References: <53AD5422.3070606@redhat.com> <1403875099.3551.7.camel@willson.usersys.redhat.com> Message-ID: <53AD707A.30004@redhat.com> On 27.6.2014 15:18, Simo Sorce wrote: > On Fri, 2014-06-27 at 13:23 +0200, Martin Kosek wrote: >> It seems to me that we are being inconsistent with regards to our FreeIPA >> version and the schema files. >> >> We now have 60basev2.ldif containing FreeIPA 2.x schema, 60basev3.ldif >> containing FreeIPA 3.x schema. However, we now also added FreeIPA 4.x schema to >> 60basev3.ldif which seems as an inconsistency to me. >> >> Should we simply create 60basev4.ldif and move the new schema (mostly >> permissionsv2 related) there? > > If you think it make sense go ahead and do it. I think we kept > everything in the same file because at some point we changed (by adding > MAY attributes) older objectclasses and these modifications were made > before we decided to change version numbers to 4.0, but I find this > mostly cosmetic so I do not really care one way or the other. > >> I am wondering that in that case we may also >> think about making a new OID space for v4 schema as current one is defined as >> >> ## Attributes: 2.16.840.1.113730.3.8.11 - V3 base attributres >> ## ObjectClasses: 2.16.840.1.113730.3.8.12 - V3 base objectclasses >> >> If we ever want to fix the OID space, now is the right time, it won't be >> possible after release. Alternatively, we could also define >> 2.16.840.1.113730.3.8.11 and 2.16.840.1.113730.3.8.12 as "V3+" space. > > I do not think it makes any sense to change OID space now. > Feel free to mark the space as V3+ I agree with Simo as I personally don't see a reason to separate things by version. Separation by purpose seems more useful to me. (We already do that - DNS, OTP, PKCS#11 are in separate OID sub-trees.) -- Petr^2 Spacek From rmeggins at redhat.com Fri Jun 27 13:41:27 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 27 Jun 2014 07:41:27 -0600 Subject: [Freeipa-devel] [PATCH] 471 Fix objectClass casing in LDIF to prevent schema update error In-Reply-To: <53AD585A.9050502@redhat.com> References: <53AD585A.9050502@redhat.com> Message-ID: <53AD7487.7040609@redhat.com> On 06/27/2014 05:41 AM, Martin Kosek wrote: > When a new objectclass was defined as "objectclass" and not > "objectClass", it made the schema updater skip some objectclasses. > > https://fedorahosted.org/freeipa/ticket/4405 > > --- > > This fixed the 3.3.5 -> 4.0 upgrade for me. The root cause is quite strange for > me though and I am not sure if this is intended. I assume there may be other > issue in updater or python-ldap. ack, although the ldap updater code should be changed - attribute types should be case insensitive. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Jun 27 14:16:51 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 16:16:51 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command Message-ID: <53AD7CD3.5000704@redhat.com> Host Administrators could not write to service keytab attribute and thus they could not run the host-disable command. https://fedorahosted.org/freeipa/ticket/4284 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-472-let-host-administrators-use-host-disable-command.patch Type: text/x-patch Size: 1319 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 27 14:18:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 16:18:28 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53AD7CD3.5000704@redhat.com> References: <53AD7CD3.5000704@redhat.com> Message-ID: <53AD7D34.9030407@redhat.com> On 06/27/2014 04:16 PM, Martin Kosek wrote: > Host Administrators could not write to service keytab attribute and > thus they could not run the host-disable command. > > https://fedorahosted.org/freeipa/ticket/4284 I forgot to add that https://fedorahosted.org/freeipa/ticket/4284#comment:2 contains output related functional testing of this change. This should help better understand the change. Martin From pviktori at redhat.com Fri Jun 27 14:26:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 27 Jun 2014 16:26:09 +0200 Subject: [Freeipa-devel] [PATCH] 471 Fix objectClass casing in LDIF to prevent schema update error In-Reply-To: <53AD7487.7040609@redhat.com> References: <53AD585A.9050502@redhat.com> <53AD7487.7040609@redhat.com> Message-ID: <53AD7F01.3030404@redhat.com> On 06/27/2014 03:41 PM, Rich Megginson wrote: > On 06/27/2014 05:41 AM, Martin Kosek wrote: >> When a new objectclass was defined as "objectclass" and not >> "objectClass", it made the schema updater skip some objectclasses. >> >> https://fedorahosted.org/freeipa/ticket/4405 >> >> --- >> >> This fixed the 3.3.5 -> 4.0 upgrade for me. The root cause is quite strange for >> me though and I am not sure if this is intended. I assume there may be other >> issue in updater or python-ldap. > > ack, although the ldap updater code should be changed - attribute types > should be case insensitive. > Yup, python-ldap bug: https://bugzilla.redhat.com/show_bug.cgi?id=1007820 Already fixed in master, or whatever CVS has. -- Petr? From mkosek at redhat.com Fri Jun 27 14:31:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 16:31:26 +0200 Subject: [Freeipa-devel] [PATCH] 471 Fix objectClass casing in LDIF to prevent schema update error In-Reply-To: <53AD7F01.3030404@redhat.com> References: <53AD585A.9050502@redhat.com> <53AD7487.7040609@redhat.com> <53AD7F01.3030404@redhat.com> Message-ID: <53AD803E.2060400@redhat.com> On 06/27/2014 04:26 PM, Petr Viktorin wrote: > On 06/27/2014 03:41 PM, Rich Megginson wrote: >> On 06/27/2014 05:41 AM, Martin Kosek wrote: >>> When a new objectclass was defined as "objectclass" and not >>> "objectClass", it made the schema updater skip some objectclasses. >>> >>> https://fedorahosted.org/freeipa/ticket/4405 >>> >>> --- >>> >>> This fixed the 3.3.5 -> 4.0 upgrade for me. The root cause is quite strange for >>> me though and I am not sure if this is intended. I assume there may be other >>> issue in updater or python-ldap. >> >> ack, although the ldap updater code should be changed - attribute types >> should be case insensitive. >> > > Yup, python-ldap bug: https://bugzilla.redhat.com/show_bug.cgi?id=1007820 > > Already fixed in master, or whatever CVS has. Good, so it is tracked and will (hopefully) get to Fedora eventually. Pushed to master as per Rich's ack. Thanks, Martin From mbasti at redhat.com Fri Jun 27 14:35:37 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Jun 2014 16:35:37 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627100442.GV7233@redhat.com> References: <1403102945.20101.21.camel@unused-4-145.brq.redhat.com> <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> Message-ID: <1403879737.2249.18.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-27 at 13:04 +0300, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Jan Cholasta wrote: > >On 27.6.2014 10:58, Alexander Bokovoy wrote: > >>On Fri, 27 Jun 2014, Jan Cholasta wrote: > >>>On 27.6.2014 10:29, Alexander Bokovoy wrote: > >>>>On Fri, 27 Jun 2014, Jan Cholasta wrote: > >>>>>On 27.6.2014 10:15, Alexander Bokovoy wrote: > >>>>>>On Fri, 20 Jun 2014, Martin Basti wrote: > >>>>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: > >>>>>>>>On 18.6.2014 16:49, Martin Basti wrote: > >>>>>>>>>Due to compability with older versions, only IDNA domains should be > >>>>>>>>>checked > >>>>>>>>>Patch attached. > >>>>>>>> > >>>>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't > >>>>>>>>there a > >>>>>>>>better way to do this check? > >>>>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN > >>>>>>>string. > >>>>>>> > >>>>>>>Or just remove this validation. > >>>>>>> > >>>>>>>>(BTW I really think this should be a warning, not an error, but that > >>>>>>>>would require larger amount of work, so I guess it's OK for now.) > >>>>>>>(More pain than gain) > >>>>>>Main thing in this patch is that the check should not be done against > >>>>>>non-IDN strings. I want this version of the patch to go in for that > >>>>>>reason as currently you cannot even complete ipa-adtrust-install > >>>>>>run due > >>>>>>to IDN normalisation check being applied to non-IDN domains. > >>>>> > >>>>>On non-IDN domains, the only effect of IDN normalization is that it > >>>>>lower-cases the names (right?), so the check should compare > >>>>>lower-cased original name with the normalized name, instead of > >>>>>special-casing certain characters etc. > >>>>.. what's the reason to do such comparison then? lower-cased non-IDN > >>>>name will be equal to lower-cased normalized non-IDN name by definition, > >>>>so the check is not needed in this case, at all. > >>> > >>>The point is that it works for both IDN and non-IDN, without > >>>u'\xdf'-style hacks. > >>No, your proposal of comparing low-cased value and normalized value is > >>not going to work because low-cased value is in general not equal to > >>normalized value for IDN names, only for non-IDN ones, due to the fact > >>that lower case for non-ASCII Unicode character may map to a completely > >>different character than in normalization situation. Take, for example, > >>Turkish alphabet where there are six letters with different case rules > >>(uppercase dotted i, dottless lowercase i, upper- and lowercase G with > >>breve accent, and upper- and lowercase S with cedilla), which will break > >>your generalized check. > >>So you'll anyway will need to split these cases. > >> > > > >I see. > > > >I'm still not comfortable with carrying the bit of knowledge about > >u'\xdf' in this particular spot. Can we check that a name is IDN some > >other way than "domain_name.is_idn() or u'\xdf' in value"? > > Attached patch works for me. Note that nameprep() use should be > per-label, not the whole DNS name, and we can use > encodings.idna.ToASCII() per lable to check if the label is IDN. If any > of the label is IDN, we force strict check. > Hello, be careful with this: + labels = value.split('.') RFC3490 Section 3.1.1 Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). This is even not handled in python-dns, I have discussion with python-dns maintaner and I will probably make a patch. And in IDNA2008 [not supported in IPA/python-dns] - there is only U+002E (full stop) as label separator. I suggest to raise an error if domain name contains U+FF61, U+FF0E, U +3002. User should use only U+002E (full stop). This will fix issue with python-dns and works with IDNA2008 too -- Martin^2 Basti From pviktori at redhat.com Fri Jun 27 14:40:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 27 Jun 2014 16:40:48 +0200 Subject: [Freeipa-devel] [PATCH] 0609 Update translations Message-ID: <53AD8270.9000902@redhat.com> Hello, In preparation for the 4.0 release, I've pulled in updated translationsfrom Transifex. Thank you to all translators! As usual with translations, I pushed it without review. The patch is huge, please use your Git client to get it. It's commit 36d261e843dd6e8197e6f3ea16a97370215b50c2 install/po/bn_IN.po | 7 +- install/po/ca.po | 63 ++- install/po/cs.po | 6 +- install/po/de.po | 1924 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- install/po/es.po | 616 ++++++++++++++---------- install/po/eu.po | 24 +- install/po/fr.po | 1331 ++++++++++++++++++++++++++-------------------------- install/po/id.po | 10 +- install/po/ipa.pot | 6132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------------------------------------------- install/po/ja.po | 27 +- install/po/kn.po | 28 +- install/po/nl.po | 6 +- install/po/pl.po | 85 ++-- install/po/ru.po | 69 ++- install/po/tg.po | 26 +- install/po/uk.po | 2262 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------- install/po/zh_CN.po | 19 +- 17 files changed, 8566 insertions(+), 4069 deletions(-) -- Petr? From pspacek at redhat.com Fri Jun 27 14:43:37 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Jun 2014 16:43:37 +0200 Subject: [Freeipa-devel] DNSSEC key wrapping: cryptographer needed In-Reply-To: <53A9C3B4.3080004@redhat.com> References: <53A82440.30000@redhat.com> <1403617556.20513.36.camel@vespa.frost.loc> <53A9C3B4.3080004@redhat.com> Message-ID: <53AD8319.7020307@redhat.com> On 24.6.2014 20:30, Petr Spacek wrote: > On 24.6.2014 15:45, Tomas Mraz wrote: >>> >Technically SoftHSM's C_WrapKey call produces PKCS#8 structure encrypted with >>> >AES according to RFC 3394 (no padding) or RFC 5649 (with padding). >>> > >>> >RFC 3394 works only on blocks of 64 bits, which is not our case because >>> >EncryptedPrivateKeyInfo has no padding. So we should use RFC 5649 to get >>> >proper padding etc. >>> > >>> >And here is the problem: SoftHSM can use RFC 5649 using OpenSSL functions but >>> >OpenSSL doesn't support RFC 5649! The patch with this functionality was >>> >submitted back in 2010 to OpenSSL bug tracker [3] but the ticket is in state >>> >"new" and there was no reply to the e-mail in the original thread [4]. >> I am sorry, but this does not make much sense to me. Iff the SoftHSM's >> C_WrapKey is really safe wrapping method for backing up and/or >> replicating HSM's it must provide wrapped key in such format that the IV >> is pregenerated as part of the Wrap operation and stored in the final >> blob of wrapped key. Unfortunately I do not know much of SoftHSM. > SoftHSM is "just" PKCS#11 interface implementation so SoftHSM can't do > something against PKCS#11 standard. > > In this case the standard says that user has to provide IV explicitly and the > C_WrapKey should fall-back to standardized default if IV was not given by user. > > See section "6.13.3 AES Key Wrap" in "PKCS #11 Mechanisms v2.30: Cryptoki ? > Draft 7" on > ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf > >> >>> >What do we do? >>> >- Convince OpenSSL to review and accept the patch? >> I would say the patch is not too useful as is - there are multiple >> problems with it such as it is not using proper high level interfaces >> for the AES encryption, etc. > Ah, right, nowadays openssl/crypto/aes/aes_wrap.c file is very different from > the 2010-version. I didn't notice it. > > Would you review the patch if we re-write it against current OpenSSL git head? I'm attaching my patches for RFC 5649 support in OpenSSL. Patches are written on top of OpenSSL git master. In the worst case it should be relatively easy to transform patches to stand-alone piece of code and glue them together with SoftHSM. I have sent all patches to openssl-bugs at openssl.org but I can't find any public mailing list archive for it so I will update this list when I receive a reply. Patches are also on Github: https://github.com/spacekpe/openssl/commits/aes_wrap_pad Comments are more than welcome! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: [PATCH] Add support for key wrapping mode with padding - RFC 5649.eml Type: application/x-extension-eml Size: 54435 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 27 15:10:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 17:10:13 +0200 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA Message-ID: <53AD8955.1050304@redhat.com> Hello team, As we are about to very soon release the FreeIPA 4.0, I triaged all the pending tickets and divided them to following milestones: 1) FreeIPA 4.0 GA - last work that is required for the release. When this milestone is completed, we will release. All tickets in this milestone are thus the top priority for people working on 4.0 - this applies both for development and for reviews. 2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in any significant way and can be done after GA. RFEs and bugs that did not make it to these buckets were pushed out to next releases - 4.1, 4.2 or even farther, based on their scope and importance. If I missed anything or you think that some ticket I pushed out must make it to 4.0 (and you have a patch), please ping me. Thank you. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From ssorce at redhat.com Fri Jun 27 15:10:18 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 27 Jun 2014 11:10:18 -0400 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53AD7CD3.5000704@redhat.com> References: <53AD7CD3.5000704@redhat.com> Message-ID: <1403881818.3551.12.camel@willson.usersys.redhat.com> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: > Host Administrators could not write to service keytab attribute and > thus they could not run the host-disable command. > > https://fedorahosted.org/freeipa/ticket/4284 > Any reason why Host Administrators are not members of the service Administrators group/permission by default ? Simo. From mbasti at redhat.com Fri Jun 27 15:11:01 2014 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Jun 2014 17:11:01 +0200 Subject: [Freeipa-devel] [PATCHES 0080-0081] DNSSEC: Add experimental support for DNSSEC Message-ID: <1403881861.2249.20.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/4408 Patches attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0080-Allow-to-add-non-string-values-to-named-conf.patch Type: text/x-patch Size: 4054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0081-DNSSEC-Add-experimental-support-for-DNSSEC.patch Type: text/x-patch Size: 2535 bytes Desc: not available URL: From mkosek at redhat.com Fri Jun 27 15:12:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 17:12:52 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <1403881818.3551.12.camel@willson.usersys.redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> Message-ID: <53AD89F4.6000202@redhat.com> On 06/27/2014 05:10 PM, Simo Sorce wrote: > On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >> Host Administrators could not write to service keytab attribute and >> thus they could not run the host-disable command. >> >> https://fedorahosted.org/freeipa/ticket/4284 >> > > Any reason why Host Administrators are not members of the service > Administrators group/permission by default ? > > Simo. > I assume that the original intent was to allow admins to separate this privileges. I.e. allow service administrators manage services on hosts but do not allow them delete or disable the hosts. This patch fixes the reported request for Foreman integration, if you have a better one fixing it as well, we can go different way. Thanks, Martin From ssorce at redhat.com Fri Jun 27 15:16:52 2014 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 27 Jun 2014 11:16:52 -0400 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53AD89F4.6000202@redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> Message-ID: <1403882212.3551.14.camel@willson.usersys.redhat.com> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: > On 06/27/2014 05:10 PM, Simo Sorce wrote: > > On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: > >> Host Administrators could not write to service keytab attribute and > >> thus they could not run the host-disable command. > >> > >> https://fedorahosted.org/freeipa/ticket/4284 > >> > > > > Any reason why Host Administrators are not members of the service > > Administrators group/permission by default ? > > > > Simo. > > > > I assume that the original intent was to allow admins to separate this > privileges. I.e. allow service administrators manage services on hosts but do > not allow them delete or disable the hosts. Sure, but I asked the opposite question. I understand you may want to have Service Administrators that cannot manage the host object. But is there ever a case where Host Administrator is not also Service Administrator ? > This patch fixes the reported request for Foreman integration, if you have a > better one fixing it as well, we can go different way. I was wondering if a group membership change wouldn't solve a class of problems, instead of fixing this on per permission basis, that's all. Simo. From mkosek at redhat.com Fri Jun 27 15:18:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Jun 2014 17:18:53 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <1403882212.3551.14.camel@willson.usersys.redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> Message-ID: <53AD8B5D.2000608@redhat.com> On 06/27/2014 05:16 PM, Simo Sorce wrote: > On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: >> On 06/27/2014 05:10 PM, Simo Sorce wrote: >>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >>>> Host Administrators could not write to service keytab attribute and >>>> thus they could not run the host-disable command. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4284 >>>> >>> >>> Any reason why Host Administrators are not members of the service >>> Administrators group/permission by default ? >>> >>> Simo. >>> >> >> I assume that the original intent was to allow admins to separate this >> privileges. I.e. allow service administrators manage services on hosts but do >> not allow them delete or disable the hosts. > > Sure, but I asked the opposite question. I understand you may want to > have Service Administrators that cannot manage the host object. > But is there ever a case where Host Administrator is not also Service > Administrator ? > >> This patch fixes the reported request for Foreman integration, if you have a >> better one fixing it as well, we can go different way. > > I was wondering if a group membership change wouldn't solve a class of > problems, instead of fixing this on per permission basis, that's all. > > Simo. > Sure, good thinking. I do not think that current framework can make one privilege a member of another one, so this would need to be hacked in. CCing Petr3 to get his view on this. Martin From edewata at redhat.com Fri Jun 27 16:09:27 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 27 Jun 2014 11:09:27 -0500 Subject: [Freeipa-devel] [PATCH] 677 webui: support unlock user command In-Reply-To: <53A99CC9.1070905@redhat.com> References: <53A99CC9.1070905@redhat.com> Message-ID: <53AD9737.3030907@redhat.com> On 6/24/2014 10:44 AM, Petr Vobornik wrote: > Call user-unlock command from Web UI. > > It will unlock displayed user on current master. > > related to: > https://fedorahosted.org/freeipa/ticket/2792 Looks like there's a server problem (ticket #4409), but the UI is fine, so ACK. -- Endi S. Dewata From abokovoy at redhat.com Fri Jun 27 16:52:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 19:52:40 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <1403879737.2249.18.camel@unused-4-145.brq.redhat.com> References: <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> <1403879737.2249.18.camel@unused-4-145.brq.redhat.com> Message-ID: <20140627165240.GZ7233@redhat.com> On Fri, 27 Jun 2014, Martin Basti wrote: >On Fri, 2014-06-27 at 13:04 +0300, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Jan Cholasta wrote: >> >On 27.6.2014 10:58, Alexander Bokovoy wrote: >> >>On Fri, 27 Jun 2014, Jan Cholasta wrote: >> >>>On 27.6.2014 10:29, Alexander Bokovoy wrote: >> >>>>On Fri, 27 Jun 2014, Jan Cholasta wrote: >> >>>>>On 27.6.2014 10:15, Alexander Bokovoy wrote: >> >>>>>>On Fri, 20 Jun 2014, Martin Basti wrote: >> >>>>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >> >>>>>>>>On 18.6.2014 16:49, Martin Basti wrote: >> >>>>>>>>>Due to compability with older versions, only IDNA domains should be >> >>>>>>>>>checked >> >>>>>>>>>Patch attached. >> >>>>>>>> >> >>>>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't >> >>>>>>>>there a >> >>>>>>>>better way to do this check? >> >>>>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >> >>>>>>>string. >> >>>>>>> >> >>>>>>>Or just remove this validation. >> >>>>>>> >> >>>>>>>>(BTW I really think this should be a warning, not an error, but that >> >>>>>>>>would require larger amount of work, so I guess it's OK for now.) >> >>>>>>>(More pain than gain) >> >>>>>>Main thing in this patch is that the check should not be done against >> >>>>>>non-IDN strings. I want this version of the patch to go in for that >> >>>>>>reason as currently you cannot even complete ipa-adtrust-install >> >>>>>>run due >> >>>>>>to IDN normalisation check being applied to non-IDN domains. >> >>>>> >> >>>>>On non-IDN domains, the only effect of IDN normalization is that it >> >>>>>lower-cases the names (right?), so the check should compare >> >>>>>lower-cased original name with the normalized name, instead of >> >>>>>special-casing certain characters etc. >> >>>>.. what's the reason to do such comparison then? lower-cased non-IDN >> >>>>name will be equal to lower-cased normalized non-IDN name by definition, >> >>>>so the check is not needed in this case, at all. >> >>> >> >>>The point is that it works for both IDN and non-IDN, without >> >>>u'\xdf'-style hacks. >> >>No, your proposal of comparing low-cased value and normalized value is >> >>not going to work because low-cased value is in general not equal to >> >>normalized value for IDN names, only for non-IDN ones, due to the fact >> >>that lower case for non-ASCII Unicode character may map to a completely >> >>different character than in normalization situation. Take, for example, >> >>Turkish alphabet where there are six letters with different case rules >> >>(uppercase dotted i, dottless lowercase i, upper- and lowercase G with >> >>breve accent, and upper- and lowercase S with cedilla), which will break >> >>your generalized check. >> >>So you'll anyway will need to split these cases. >> >> >> > >> >I see. >> > >> >I'm still not comfortable with carrying the bit of knowledge about >> >u'\xdf' in this particular spot. Can we check that a name is IDN some >> >other way than "domain_name.is_idn() or u'\xdf' in value"? >> >> Attached patch works for me. Note that nameprep() use should be >> per-label, not the whole DNS name, and we can use >> encodings.idna.ToASCII() per lable to check if the label is IDN. If any >> of the label is IDN, we force strict check. >> > >Hello, > >be careful with this: > >+ labels = value.split('.') > >RFC3490 Section 3.1.1 >Whenever dots are used as label separators, the following > characters MUST be recognized as dots: U+002E (full stop), U+3002 > (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 > (halfwidth ideographic full stop). > >This is even not handled in python-dns, I have discussion with >python-dns maintaner and I will probably make a patch. > >And in IDNA2008 [not supported in IPA/python-dns] - there is only U+002E >(full stop) as label separator. > >I suggest to raise an error if domain name contains U+FF61, U+FF0E, U >+3002. User should use only U+002E (full stop). This will fix issue with >python-dns and works with IDNA2008 too See my another mail which has more recent patch that handles all four types of label separators. I think at this place we can and should allow all four of them since we don't really have anything to deal with them, anywhere in IPA code. Our aim to support IDNA 2003 means we shouldn't prevent creating DNS names following this version of the spec. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jun 27 16:55:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 19:55:34 +0300 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <53AD8955.1050304@redhat.com> References: <53AD8955.1050304@redhat.com> Message-ID: <20140627165534.GA7233@redhat.com> On Fri, 27 Jun 2014, Martin Kosek wrote: >Hello team, > >As we are about to very soon release the FreeIPA 4.0, I triaged all the pending >tickets and divided them to following milestones: > >1) FreeIPA 4.0 GA - last work that is required for the release. When this >milestone is completed, we will release. All tickets in this milestone are thus >the top priority for people working on 4.0 - this applies both for development >and for reviews. Endi found that with TOTP we don't yet enforce a requirement to prevent reuse of OTP code multiple times within the same time step (you are able to login with TOTP and reuse it for password change within 30 seconds, for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT allow this behavior. I'll look into this case on Monday but so far this is a release blocker. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Jun 27 16:57:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 19:57:06 +0300 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <20140627165534.GA7233@redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> Message-ID: <20140627165706.GB7233@redhat.com> On Fri, 27 Jun 2014, Alexander Bokovoy wrote: >On Fri, 27 Jun 2014, Martin Kosek wrote: >>Hello team, >> >>As we are about to very soon release the FreeIPA 4.0, I triaged all the pending >>tickets and divided them to following milestones: >> >>1) FreeIPA 4.0 GA - last work that is required for the release. When this >>milestone is completed, we will release. All tickets in this milestone are thus >>the top priority for people working on 4.0 - this applies both for development >>and for reviews. >Endi found that with TOTP we don't yet enforce a requirement to prevent >reuse of OTP code multiple times within the same time step (you are able >to login with TOTP and reuse it for password change within 30 seconds, >for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT >allow this behavior. Err, RFC 6238, of course. http://tools.ietf.org/html/rfc6238#section-5.2 I'm off for weekend. :) -- / Alexander Bokovoy From simo at redhat.com Fri Jun 27 17:00:00 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Jun 2014 13:00:00 -0400 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <20140627165534.GA7233@redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> Message-ID: <1403888400.3172.1.camel@willson.usersys.redhat.com> On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Martin Kosek wrote: > >Hello team, > > > >As we are about to very soon release the FreeIPA 4.0, I triaged all the pending > >tickets and divided them to following milestones: > > > >1) FreeIPA 4.0 GA - last work that is required for the release. When this > >milestone is completed, we will release. All tickets in this milestone are thus > >the top priority for people working on 4.0 - this applies both for development > >and for reviews. > Endi found that with TOTP we don't yet enforce a requirement to prevent > reuse of OTP code multiple times within the same time step (you are able > to login with TOTP and reuse it for password change within 30 seconds, > for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT > allow this behavior. > > I'll look into this case on Monday but so far this is a release blocker. This is a well known limitation. The reason we allow for it is due to performance issues with replication if we did so, we do not have a good way to mark used values in a distributed fashion. It's for the same reason that we have not implemented HOTP yet. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Jun 27 17:18:55 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jun 2014 20:18:55 +0300 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <1403888400.3172.1.camel@willson.usersys.redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> <1403888400.3172.1.camel@willson.usersys.redhat.com> Message-ID: <20140627171855.GC7233@redhat.com> On Fri, 27 Jun 2014, Simo Sorce wrote: >On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Martin Kosek wrote: >> >Hello team, >> > >> >As we are about to very soon release the FreeIPA 4.0, I triaged all the pending >> >tickets and divided them to following milestones: >> > >> >1) FreeIPA 4.0 GA - last work that is required for the release. When this >> >milestone is completed, we will release. All tickets in this milestone are thus >> >the top priority for people working on 4.0 - this applies both for development >> >and for reviews. >> Endi found that with TOTP we don't yet enforce a requirement to prevent >> reuse of OTP code multiple times within the same time step (you are able >> to login with TOTP and reuse it for password change within 30 seconds, >> for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT >> allow this behavior. >> >> I'll look into this case on Monday but so far this is a release blocker. > >This is a well known limitation. > >The reason we allow for it is due to performance issues with replication >if we did so, we do not have a good way to mark used values in a >distributed fashion. Are we willing to release with this limitation? If so, it should be stated quite clearly in the docs. -- / Alexander Bokovoy From pvoborni at redhat.com Fri Jun 27 17:19:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 19:19:41 +0200 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <1403888400.3172.1.camel@willson.usersys.redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> <1403888400.3172.1.camel@willson.usersys.redhat.com> Message-ID: <53ADA7AD.8060002@redhat.com> On 27.6.2014 19:00, Simo Sorce wrote: > On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Martin Kosek wrote: >>> Hello team, >>> >>> As we are about to very soon release the FreeIPA 4.0, I triaged all the pending >>> tickets and divided them to following milestones: >>> >>> 1) FreeIPA 4.0 GA - last work that is required for the release. When this >>> milestone is completed, we will release. All tickets in this milestone are thus >>> the top priority for people working on 4.0 - this applies both for development >>> and for reviews. >> Endi found that with TOTP we don't yet enforce a requirement to prevent >> reuse of OTP code multiple times within the same time step (you are able >> to login with TOTP and reuse it for password change within 30 seconds, >> for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT >> allow this behavior. >> >> I'll look into this case on Monday but so far this is a release blocker. > > This is a well known limitation. > > The reason we allow for it is due to performance issues with replication > if we did so, we do not have a good way to mark used values in a > distributed fashion. > > It's for the same reason that we have not implemented HOTP yet. Not entirely true: http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html > > Simo. > -- Petr Vobornik From pvoborni at redhat.com Fri Jun 27 17:27:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jun 2014 19:27:35 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <538C8338.1040502@redhat.com> References: <538C8338.1040502@redhat.com> Message-ID: <53ADA987.4050808@redhat.com> On 2.6.2014 15:59, Petr Vobornik wrote: > Hi List, > > the purpose if this mail is to start a discussion about reorganization > of navigation items. Users are not fond of such change so we should come > up with a solution which would last for some time. > > Problem: > UX recommendation is that one menu level should contain maximum of 7 > items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. > Basically we reached max. capacity of all 1st-level items. > > Solution: > Introduce new 1st-level items and redistribute 2nd-level items. > It would be great to get this into 4.0, resuming the discussion. My proposal which takes into account various other proposals: Identity (7) - Users - User Groups - Hosts - Host Groups - Netgroups - Services - Automember - User group rules - Host group rules Policy (5) - Host Based Access Control - HBAC Rules - HBAC Services - HBAC Service Groups - HBAC Test - Sudo - Sudo Rules - Sudo Commands - Sudo Command Groups - SELinux User Maps - Password Policies - Kerberos Ticket Policy Authentication (3-4) - Certificates - (future) User Certificates - OTP Tokens - RADIUS Servers Network services (2-3) - Automount - DNS - DNS Zones - DNS Forward Zones - DNS Global Configuration - (future) Vault IPA Server (5-7) - Role Based Access Control - Roles - Privileges - Permissions - Self Service Permissions - Delegations - ID Ranges - Realm Domain - (future) Replication Topology - Trusts - Trusts - Global Trust Configuration - (future) Views - Configuration (future) Help - Docs - API - ... Mostly it's a response to the last proposal: http://www.redhat.com/archives/freeipa-devel/2014-June/msg00107.html You can check live version at: http://pvoborni.fedorapeople.org/ui/ From the earlier discussion I would say, that there was an agreement on Identity and Policy tabs which are very similar to current implementation. Simo had a proposal to introduce "Authentication" tab in a future. I guess we can do it now. We already have radius server proxies and certificates are also related. It will solve the "OTP doesn't fit anywhere problem" I've kept the "Network Services" tab because IDK where to put DNS and Automount :) Simo's 'Directory' and 'Configuration' were merged into existing 'IPA server' with the difference that all RBAC related stuff is under one item (this option was mentioned by Petr3). Btw RBAC === "Existing items in 'Directory'". The label is 'IPA Server' because almost everything is related to configuration of the server itself maybe with exception of Trust and Views. Label 'Configuration' is too general. Label Directory was quite low-level as pointed out by Dmitry. This merge allows us to add 'Help' in a future. It would be good to move something into "Network services" (and maybe rename it) since it has only two(three in future) items. -- Petr Vobornik From simo at redhat.com Fri Jun 27 17:49:30 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Jun 2014 13:49:30 -0400 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <53ADA7AD.8060002@redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> <1403888400.3172.1.camel@willson.usersys.redhat.com> <53ADA7AD.8060002@redhat.com> Message-ID: <1403891370.6436.1.camel@willson.usersys.redhat.com> On Fri, 2014-06-27 at 19:19 +0200, Petr Vobornik wrote: > On 27.6.2014 19:00, Simo Sorce wrote: > > On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote: > >> On Fri, 27 Jun 2014, Martin Kosek wrote: > >>> Hello team, > >>> > >>> As we are about to very soon release the FreeIPA 4.0, I triaged all the pending > >>> tickets and divided them to following milestones: > >>> > >>> 1) FreeIPA 4.0 GA - last work that is required for the release. When this > >>> milestone is completed, we will release. All tickets in this milestone are thus > >>> the top priority for people working on 4.0 - this applies both for development > >>> and for reviews. > >> Endi found that with TOTP we don't yet enforce a requirement to prevent > >> reuse of OTP code multiple times within the same time step (you are able > >> to login with TOTP and reuse it for password change within 30 seconds, > >> for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT > >> allow this behavior. > >> > >> I'll look into this case on Monday but so far this is a release blocker. > > > > This is a well known limitation. > > > > The reason we allow for it is due to performance issues with replication > > if we did so, we do not have a good way to mark used values in a > > distributed fashion. > > > > > It's for the same reason that we have not implemented HOTP yet. > > Not entirely true: > http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html I should probably have said we have not implemented it *for* HOTP. That said using HOTP is not really something I would recommend at this point as each authentication will cause a replication event to be fired. That is probably ok if you have very few users/authentications, but in large domains it would quickly be problematic. Responding to Alexander, yes we need to document that we have this limitation. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Jun 27 22:19:25 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jun 2014 18:19:25 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53AD5102.1000302@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> Message-ID: <53ADEDED.7090603@redhat.com> Jan Cholasta wrote: > On 26.6.2014 20:05, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 16.6.2014 15:35, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches implement >>>> . >>>> >>>> My patches 241-253 and 262-294 are required for this >>>> (, >>>> >>>> ). >>>> >>>> >>>> The installation/testing guidelines from >>>> >>>> apply here as well. >>>> >>>> Honza >>> >>> Rebased on top of current master. >> >> 295 ACK >> >> 296, 297 & 299 >> >> TBD, need to test but no problems seen so far. >> >> 298 >> >> The man page, if not usage, should include what the valid trust flags >> are or point to NSS documentation. > > OK. > >> >> rob >> > > Updated rebased patches attached. Also attaching all the required patches. > I'm going to consolidate all reviews for 241 - 303 here. I'm not doing this in any particular order. -------- Missing man page for ipa-certupdate -------- Not a very nice error from ipa-cacert-manage install when loading a bad cert: # ipa-cacert-manage install /etc/group Installing CA certificate, please wait (SEC_ERROR_INVALID_ARGS) security library: invalid arguments. The ipa-cacert-manage makes no mention of changing the cert chaining. It just adds the options, not what they do. Here is what happened when I tried it: # ipa-cacert-manage renew --external-ca Exporting CA certificate signing request, please wait The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as: ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-ca-file=/path/to/external_ca_certificate The ipa-cacert-manage command was successful [ go off and sign it ] # ipa-cacert-manage renew --external-cert-file=/home/rcrit/ca_db/ipa.crt --external-ca-file=/home/rcrit/ca_db/ca.crt Importing the renewed CA certificate, please wait Resubmitting certmonger request '20140627134654' timed out, please check the request manually The request was actually in MONITORING, so ok. But the CA is now not working # ipa cert-request --principal test/`hostname` csr ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error) # ipa cert-show 1 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error) The CA database doesn't have my external CA # certutil -Ld /etc/pki/pki-tomcat/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu caSigningCert cert-pki-ca CTu,Cu,Cu ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u Not sure if this is related: # pki cert-find PKIException: Internal Server Error -------- Note that I tried again with a fresh external install, this time without the --external-ca flag and it basically went through the same steps but this time it was successful. -------- I did a re-install and tried a renewal (with just ipa-server-install). I moved time forward and saw this: Request ID '20140627150913': status: MONITORING ca-error: Server at "https://sif.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1: Invalid Credential. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='323234924210' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=GREYOAK.COM subject: CN=CA Audit,O=GREYOAK.COM expires: 2016-06-16 15:08:34 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes How it is monitoring with a ca-error I don't know. I forced a resubmit and it renewed ok. Chances are certmonger would have taken care of this automatically. I leaped forward 2 more times and had to restart certmonger a few times to kick things but again, it did eventually renew as expected. So that looks ok and covers much of the first patch set. --------------- ipa-client-install still fails for me in RHEL-5 with an external CA: 2014-06-27 14:04:31,202 DEBUG trying to retrieve CA cert via LDAP from ldap://sif.greyoak.com 2014-06-27 14:04:32,312 INFO Successfully retrieved CA cert Subject: /O=GREYOAK.COM/CN=Certificate Authority Issuer: /CN=External Authority 2014-06-27 14:04:32,467 DEBUG args=/usr/sbin/ipa-join -s sif.greyoak.com -b dc=greyoak,dc=com 2014-06-27 14:04:32,467 DEBUG stdout= 2014-06-27 14:04:32,467 DEBUG stderr=libcurl failed to execute the HTTP POST transaction. SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed This is the query that is being done: [27/Jun/2014:14:04:31 -0400] conn=18 op=3 SRCH base="CN=CAcert,CN=ipa,CN=etc,dc=greyoak,dc=com" scope=0 filter="(objectClass=pkiCA)" attrs="cacertificate;binary" It returns a single object, the dogtag-issued CA certificate, not the entire chain, hence the failure. Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while /usr/share/ipa/html/ca.crt contains the full chain. This works: # wget -O /tmp/ca.crt http://sif.greyoak.com/ipa/config/ca.crt # ipa-client-install --server=sif.greyoak.com --domain=greyoak.com -p admin -w password -U --ca-cert-file=/tmp/ca.crt -------- Enrollment on RHEL-6 also puts a single CA in /etc/ipa/ca.crt but enrollment succeeds. Enrollment on F-20 puts all certs into /etc/ipa/ca.crt. My last test was re-freshing the CA cert from an external and I confirmed that both the IPA CA certs are in /etc/ipa/ca.crt and in LDAP. -------- Ok, so I took my working, renewed Externally-issued CA install and generated a PKCS#12 for another host. Using that I did a CA-less install. I tried ipa-ca-install on that and it failed. The log is attached, though it shouldn't be called ipareplica-ca-install.log in this case. -------- Installing a replica and adding a CA to it using ipa-replica-ca-install worked fine. -------- I renewed the CA once again using ipa-cacert-manage then used ipa-certupdate to apply the result successfully on the replica except for the CA itself. It is still has the serial number it was installed with and not the updated value in caSigningCert cert-pki-ca. -------- Patch 293 Just curious, but what is the advantage of writing out the certificates in pk11-kit format when you can drop the cert(s) and call update-ca-trust? Is it a control thing, particularly for the trusted/untrusted? Patch 294 I think the git commit should include the bit about using the CA file from the replica config as well. Patch 303. Is the context as cli_installer a cut-n-paste or a conscious choice? Should there be some logging in here? What happens if the kinit fails, or something else goes bump? There is no debug/verbose output option to see what is going on. In update_client() should it be paranoid enough to have a try/except around the reads and writes? I'm assuming that the certutil call in update_db() is because the other cert management we have is in ipaserver, right? Perhaps certs.py needs to be moved to ipapython (and maybe renamed)? A patch for another day if you agree and please file a ticket. I still need to do more chain-updating and upgrade testing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-ca-install.log Type: text/x-log Size: 104613 bytes Desc: not available URL: From npmccallum at redhat.com Fri Jun 27 22:55:35 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 27 Jun 2014 18:55:35 -0400 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <1403891370.6436.1.camel@willson.usersys.redhat.com> References: <53AD8955.1050304@redhat.com> <20140627165534.GA7233@redhat.com> <1403888400.3172.1.camel@willson.usersys.redhat.com> <53ADA7AD.8060002@redhat.com> <1403891370.6436.1.camel@willson.usersys.redhat.com> Message-ID: <2B2C60B0-6E60-4586-8F42-57E2D4502F2C@redhat.com> On Jun 27, 2014, at 1:49 PM, Simo Sorce wrote: > On Fri, 2014-06-27 at 19:19 +0200, Petr Vobornik wrote: >> On 27.6.2014 19:00, Simo Sorce wrote: >>> On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote: >>>> On Fri, 27 Jun 2014, Martin Kosek wrote: >>>>> Hello team, >>>>> >>>>> As we are about to very soon release the FreeIPA 4.0, I triaged all the pending >>>>> tickets and divided them to following milestones: >>>>> >>>>> 1) FreeIPA 4.0 GA - last work that is required for the release. When this >>>>> milestone is completed, we will release. All tickets in this milestone are thus >>>>> the top priority for people working on 4.0 - this applies both for development >>>>> and for reviews. >>>> Endi found that with TOTP we don't yet enforce a requirement to prevent >>>> reuse of OTP code multiple times within the same time step (you are able >>>> to login with TOTP and reuse it for password change within 30 seconds, >>>> for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT >>>> allow this behavior. >>>> >>>> I'll look into this case on Monday but so far this is a release blocker. >>> >>> This is a well known limitation. >>> >>> The reason we allow for it is due to performance issues with replication >>> if we did so, we do not have a good way to mark used values in a >>> distributed fashion. >>> >> >>> It's for the same reason that we have not implemented HOTP yet. >> >> Not entirely true: >> http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html > > I should probably have said we have not implemented it *for* HOTP. > > That said using HOTP is not really something I would recommend at this > point as each authentication will cause a replication event to be fired. > That is probably ok if you have very few users/authentications, but in > large domains it would quickly be problematic. > > Responding to Alexander, yes we need to document that we have this > limitation. +1, we need to clearly document it. I plan to work on this next week. Just to outline the situation: We currently implement two features: TOTP and HOTP. We currently only recommend deploying TOTP due to the aforementioned replication issues. HOTP will not permit key reuse, but TOTP will. We call this feature for TOTP ?high watermark.? The reasons for this are twofold. First, we have a general concern about replication storms when recording the high watermark. We hope to solve this problem in the next release by defining a mechanism for high priority replication and, hopefully, custom replication conflict resolvers to prevent a possible scenario where the counter would move backwards. Second, when using HOTP, a bug is triggered in SSSD password changing where a token is implicitly used twice in a row. Enabling high watermark support for TOTP also triggers this bug. Fixing this in SSSD is also high on the priority list for the next release. So, in short, it is a known defect that is not a blocker for this release and that needs to be appropriately documented. Nathaniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Fri Jun 27 23:59:44 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 27 Jun 2014 18:59:44 -0500 Subject: [Freeipa-devel] [PATCH] 683-690 webui: OTP token sync In-Reply-To: <53AC2A19.5000805@redhat.com> References: <53AC2A19.5000805@redhat.com> Message-ID: <53AE0570.4050300@redhat.com> On 6/26/2014 9:11 AM, Petr Vobornik wrote: > This set of patches creates page(s) for OTP Token Sync. > > there are two options: > 1. from login page by "Sync OTP Token" link. > - user can navigate between those two pages > 2. standalone page on `ipa/ui/sync_otp.html` which is not linked to UI > and can be used separately. > > Both share the same code. > > All dependencies should be in master. > > This implements only ticket: https://fedorahosted.org/freeipa/ticket/4218 > > Sync by authenticated user will be implemented later in tickets: > https://fedorahosted.org/freeipa/ticket/4365 > https://fedorahosted.org/freeipa/ticket/4366 > > > Patch descriptions: > > == [PATCH] 683 webui: base class for LoginScreen-like facets == > LoginScreen has layout which can be reused for other facets/widgets, > e.g. for Sync OTP facet > > == [PATCH] 684 webui: add OTP token synchronization == > New SyncOTPScreen widget and related facet > > == [PATCH] 685 webui: add link pointing to OTP sync page to login == > > == [PATCH] 686 webui: support global notifications in all containers == > Global notifications were limited to "main" container. Now they have > their own container which is displayed over other ones. It makes them > usable everywhere. > > == [PATCH] 687 webui: bind Login facet and OTP sync facet == > Simple plugin which handles transition from login facet to OTP sync > facet and vice versa. > > == [PATCH] 688 webui: fix confirmation mixin origin check == > Current check is not enough. > > == [PATCH] 689 webui: layer for standalone pages which use WebUI > framework == > Current compiled Web UI layer (app.js) contains every FreeIPA plugin and > not just the UI framework. It's not possible to start just a simple facet. > > This commit creates a basis for a layer (core.js) which contains only > framework code and not entity related code. > > == [PATCH] 690 webui: add sync_otp.html == > standalone page for OTP token synchronization. It reuses SyncOTPScreen > widget instead of reimplementing the logic as in other standalone pages. ACK. Some functionalities are not working, but they seem to be server issues. The UI itself seems to be fine with possible improvements below. 1. The link to Sync OTP Token is not very visible and probably rarely used, so probably it can be moved together with the other messages ("To login with...") and be given a longer description. 2. The Sync OTP page should explain that for the second OTP the user should generate or wait for a new one. 3. In the standalone Sync OTP page, after a successful sync should it just display a confirmation message without displaying the form again? Or maybe it should go to the Login page, or provide a link to it, because most people probably wants to login after sync. 4. Unrelated. In the password reset page the "Reset Password and Login" button is not quite accurate for OTP case since the user will not be logged in automatically. 5. Server issue. TOTP can be used multiple times: https://fedorahosted.org/freeipa/ticket/4410 6. Server issue. Kinit doesn't seem to be working with OTP. https://fedorahosted.org/freeipa/ticket/4411 7. Seems to be server issue too. HOTP doesn't seem to be working for login or sync. https://fedorahosted.org/freeipa/ticket/4412 -- Endi S. Dewata From edewata at redhat.com Sat Jun 28 00:04:29 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 27 Jun 2014 19:04:29 -0500 Subject: [Freeipa-devel] [PATCH] 691 webui-ci: fix action list action visibility and enablement assertion In-Reply-To: <53AC2AF3.6020701@redhat.com> References: <53AC2AF3.6020701@redhat.com> Message-ID: <53AE068D.5070005@redhat.com> On 6/26/2014 9:15 AM, Petr Vobornik wrote: > Fixes CA-less CI test fail > > The new html structure was not addressed properly. The new code is checking for the 'disabled' class in the list element, not the link element, is this correct? is_enabled = not self.has_class(li, 'disabled') If test works, ACK. -- Endi S. Dewata From pcix133 at hotmail.com Sat Jun 28 07:45:28 2014 From: pcix133 at hotmail.com (daiEric) Date: Sat, 28 Jun 2014 15:45:28 +0800 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: <53AD8955.1050304@redhat.com> References: <53AD8955.1050304@redhat.com> Message-ID: Dearall ? if freeipa canbe installed on centos 6.5 or 7.0 ? ???? iPhone > ? 2014?6?27??23:10?"Martin Kosek" ??? > > Hello team, > > As we are about to very soon release the FreeIPA 4.0, I triaged all the pending > tickets and divided them to following milestones: > > 1) FreeIPA 4.0 GA - last work that is required for the release. When this > milestone is completed, we will release. All tickets in this milestone are thus > the top priority for people working on 4.0 - this applies both for development > and for reviews. > > 2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in any > significant way and can be done after GA. > > RFEs and bugs that did not make it to these buckets were pushed out to next > releases - 4.1, 4.2 or even farther, based on their scope and importance. If I > missed anything or you think that some ticket I pushed out must make it to 4.0 > (and you have a patch), please ping me. > > Thank you. > > -- > Martin Kosek > Supervisor, Software Engineering - Identity Management Team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From simo at redhat.com Sat Jun 28 14:18:00 2014 From: simo at redhat.com (Simo Sorce) Date: Sat, 28 Jun 2014 10:18:00 -0400 Subject: [Freeipa-devel] Planning FreeIPA 4.0 GA In-Reply-To: References: <53AD8955.1050304@redhat.com> Message-ID: <1403965080.6436.18.camel@willson.usersys.redhat.com> On Sat, 2014-06-28 at 15:45 +0800, daiEric wrote: > Dearall ? > if freeipa canbe installed on centos 6.5 or 7.0 > ? Yes, it is called "Identity Management" on RHEL and derivatives: yum install ipa-server Simo. > ???? iPhone > > > ? 2014?6?27??23:10?"Martin Kosek" ??? > > > > Hello team, > > > > As we are about to very soon release the FreeIPA 4.0, I triaged all the pending > > tickets and divided them to following milestones: > > > > 1) FreeIPA 4.0 GA - last work that is required for the release. When this > > milestone is completed, we will release. All tickets in this milestone are thus > > the top priority for people working on 4.0 - this applies both for development > > and for reviews. > > > > 2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in any > > significant way and can be done after GA. > > > > RFEs and bugs that did not make it to these buckets were pushed out to next > > releases - 4.1, 4.2 or even farther, based on their scope and importance. If I > > missed anything or you think that some ticket I pushed out must make it to 4.0 > > (and you have a patch), please ping me. > > > > Thank you. > > > > -- > > Martin Kosek > > Supervisor, Software Engineering - Identity Management Team > > Red Hat Inc. > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From ftweedal at redhat.com Mon Jun 30 04:41:49 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 30 Jun 2014 14:41:49 +1000 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <53AD314F.50906@redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> <53AD314F.50906@redhat.com> Message-ID: <20140630044149.GM2417@dhcp-40-8.bne.redhat.com> On Fri, Jun 27, 2014 at 10:54:39AM +0200, Petr Vobornik wrote: > On 27.6.2014 09:48, Fraser Tweedale wrote: > >On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: > >>Patch 618 fixes a bug. > >> > >>Patches 680 and 681 were implemented along with it. They address pspacek's > >>usability rant :). > >> > >>[PATCH] 680 webui: show notification instead of modal dialog on validation > >>error > >>[PATCH] 681 webui: fix required error notification in multivalued widget > >>[PATCH] 682 webui: focus invalid widget on validation error > >>-- > >>Petr Vobornik > > > >ACK on 680 and 682. > > > >On 681: diff makes sense; I'm not 100% sure my testing has covered > >cases that were previously failing. ACK if you're confident, > >otherwise could you provide steps to verify? > > You need to find a required multivalued field. One is in "Identity/Realm > Domains". Delete all values and hit update. It's little bit related to > ticket: https://fedorahosted.org/freeipa/ticket/4057 > > Also when verifying validators in multivalued field, it's good to check if > errors are provided only for "invalid" values, etc.. good test field is in > "DNS/DNS Zones/some zone/Settings/ there is "Allow query" field which > accepts network address, "any" or "none". > I can't discern any difference in behaviour of the multi-value fields from before and after your patch. I tried with the "Identity/Realm Domains" as suggested. Maybe I missed something. Has someone else been able to verify? Fraser > > > >Cheers, > > > >Fraser > > > -- > Petr Vobornik From tbordaz at redhat.com Mon Jun 30 06:54:55 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 30 Jun 2014 08:54:55 +0200 Subject: [Freeipa-devel] [PATCH] 0002 - User Life Cycle (create containers and scoping DS plugins) Message-ID: <53B109BF.6070602@redhat.com> Hello This patch (RF3813) setup DS plugins and containers required for User life cycle * creation of the Stage/Delete containers (Active container already exists) * attribute uniqueness (uid, ipaUniqueID, krbCanonicalName, krbPrincipalName) will be enforced across all backends with https://fedorahosted.org/389/ticket/47823 * ipa UUID will exclude Stage/Delete container with a change in ipa-uuid (patch 0003) Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Ticket-3813-User-Life-Cycle-create-containers-and-sc.patch Type: text/x-patch Size: 6059 bytes Desc: not available URL: From ftweedal at redhat.com Mon Jun 30 07:13:00 2014 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 30 Jun 2014 17:13:00 +1000 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <53AD5F83.5040003@redhat.com> References: <53AD5F83.5040003@redhat.com> Message-ID: <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> On Fri, Jun 27, 2014 at 02:11:47PM +0200, Petr Vobornik wrote: > Make the label of these buttons consistent with other buttons which have > capital first letters. > -- > Petr Vobornik > From 7214242fb0c5accc45b6af476a8ff7e7b1a7883f Mon Sep 17 00:00:00 2001 > From: Petr Vobornik > Date: Fri, 27 Jun 2014 13:59:11 +0200 > Subject: [PATCH] webui: capitalize labels of undo and undo all buttons > > Make the label of these buttons consistent with other buttons which have > capital first letters. > --- > install/ui/test/data/ipa_init.json | 4 ++-- > ipalib/plugins/internal.py | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json > index 0c32395ee7d68440aea0271359b0ac88fed86c42..20a462fff3b664d2320946765d1dac21ac2b1929 100644 > --- a/install/ui/test/data/ipa_init.json > +++ b/install/ui/test/data/ipa_init.json > @@ -563,8 +563,8 @@ > "next": "Next", > "page": "Page", > "prev": "Prev", > - "undo": "undo", > - "undo_all": "undo all", > + "undo": "Undo", > + "undo_all": "Undo All", > "validation": { > "error": "Text does not match field pattern", > "datetime": "Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")", > diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py > index f9ae831dc665b1282ded798023856dacec480e3b..cda9fdc7ba5237bc5bcfddbce20f47abbc210a40 100644 > --- a/ipalib/plugins/internal.py > +++ b/ipalib/plugins/internal.py > @@ -708,8 +708,8 @@ class i18n_messages(Command): > "next": _("Next"), > "page": _("Page"), > "prev": _("Prev"), > - "undo": _("undo"), > - "undo_all": _("undo all"), > + "undo": _("Undo"), > + "undo_all": _("Undo All"), Does this affect translations? The msgid "undo all" is present in the PO files. Fraser > "validation": { > "error": _("Text does not match field pattern"), > "datetime": _("Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")"), > -- > 1.9.0 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mbasti at redhat.com Mon Jun 30 07:17:13 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 09:17:13 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <53AD45BF.4090206@redhat.com> References: <53A3F18C.60903@redhat.com> <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <20140627100442.GV7233@redhat.com> <53AD42DC.8030303@redhat.com> <20140627102013.GX7233@redhat.com> <53AD45BF.4090206@redhat.com> Message-ID: <1404112633.2332.3.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-27 at 12:21 +0200, Petr Spacek wrote: > On 27.6.2014 12:20, Alexander Bokovoy wrote: > > On Fri, 27 Jun 2014, Petr Spacek wrote: > >> On 27.6.2014 12:04, Alexander Bokovoy wrote: > >>> diff --git a/ipalib/parameters.py b/ipalib/parameters.py > >>> index 1dff13c..09fed28 100644 > >>> --- a/ipalib/parameters.py > >>> +++ b/ipalib/parameters.py > >>> @@ -1965,12 +1965,15 @@ class DNSNameParam(Param): > >>> #compare if IDN normalized and original domain match > >>> #there is N:1 mapping between unicode and IDNA names > >>> #user should use normalized names to avoid mistakes > >>> - normalized_domain_name = encodings.idna.nameprep(value) > >>> - if value != normalized_domain_name: > >>> - error = _("domain name '%(domain)s' and normalized domain > >>> name" > >>> - " '%(normalized)s' do not match. Please use only" > >>> - " normalized domains") % {'domain': value, > >>> - 'normalized': normalized_domain_name} > >>> + labels = value.split('.') > >> > >> NACK. This is going to break with IDNA2003 as there are four different dots. > >> The whole DNS refactoring was about eliminating all places where DNS names > >> are threaded as strings separated by ASCII dots. > > IDNA implementation in FreeIPA git master right now is wrong with > > regards to nameprep use -- encodings.idna.nameprep(), as well as other > > functions in encodings.idna should be applied to labels, not to the > > whole DNS name. > > > > Give me a way to split a name to labels properly and we can work on. > > > >> > >> I would like to hear reasons against fixing ipa-adtrust-install (in the > >> other part of thread). > > As I said, 'fixing' ipa-adtrust-install is considered a hack. Current > > IDNA support is broken anyway, *it* needs to be fixed, not a long > > standing convention to name DNS records in Active Directory > > implementations (which Samba AD DC setup shares as well). > > Let me add that DNS protocol is case insensitive so it doesn't matter. Let's > wait for mbasti's opinion. > Yes DNS is, but IDNA is case sensitive, we need to allow use upper case for non-IDNA domains, because they can be already stored in LDAP and after upgrade these domains will raise an error. -- Martin^2 Basti From tbordaz at redhat.com Mon Jun 30 07:21:05 2014 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 30 Jun 2014 09:21:05 +0200 Subject: [Freeipa-devel] [PATCH] 0003 - User Life Cycle (prevent ipaUniqueID generation in provisioning) Message-ID: <53B10FE1.60409@redhat.com> This fix is to prevent IPA UUID DS plugin to generate a ipaUniqueID for users in provisioning container (Stage/Delete). thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Ticket-3813-User-Life-Cycle-Exclude-subtree-for-ipaU.patch Type: text/x-patch Size: 2615 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 30 07:21:56 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 09:21:56 +0200 Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <53ADA987.4050808@redhat.com> References: <538C8338.1040502@redhat.com> <53ADA987.4050808@redhat.com> Message-ID: <53B11014.9020502@redhat.com> On 06/27/2014 07:27 PM, Petr Vobornik wrote: > On 2.6.2014 15:59, Petr Vobornik wrote: >> Hi List, >> >> the purpose if this mail is to start a discussion about reorganization >> of navigation items. Users are not fond of such change so we should come >> up with a solution which would last for some time. >> >> Problem: >> UX recommendation is that one menu level should contain maximum of 7 >> items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. >> Basically we reached max. capacity of all 1st-level items. >> >> Solution: >> Introduce new 1st-level items and redistribute 2nd-level items. >> > > It would be great to get this into 4.0, resuming the discussion. My proposal > which takes into account various other proposals: > > Identity (7) > - Users > - User Groups > - Hosts > - Host Groups > - Netgroups > - Services > - Automember > - User group rules > - Host group rules > Policy (5) > - Host Based Access Control > - HBAC Rules > - HBAC Services > - HBAC Service Groups > - HBAC Test > - Sudo > - Sudo Rules > - Sudo Commands > - Sudo Command Groups > - SELinux User Maps > - Password Policies > - Kerberos Ticket Policy > Authentication (3-4) > - Certificates > - (future) User Certificates > - OTP Tokens > - RADIUS Servers > Network services (2-3) > - Automount > - DNS > - DNS Zones > - DNS Forward Zones > - DNS Global Configuration > - (future) Vault > IPA Server (5-7) > - Role Based Access Control > - Roles > - Privileges > - Permissions > - Self Service Permissions > - Delegations > - ID Ranges > - Realm Domain > - (future) Replication Topology > - Trusts > - Trusts > - Global Trust Configuration > - (future) Views > - Configuration > (future) Help > - Docs > - API > - ... > > Mostly it's a response to the last proposal: > http://www.redhat.com/archives/freeipa-devel/2014-June/msg00107.html > > You can check live version at: http://pvoborni.fedorapeople.org/ui/ > > From the earlier discussion I would say, that there was an agreement on > Identity and Policy tabs which are very similar to current implementation. > > Simo had a proposal to introduce "Authentication" tab in a future. I guess we > can do it now. We already have radius server proxies and certificates are also > related. It will solve the "OTP doesn't fit anywhere problem" > > I've kept the "Network Services" tab because IDK where to put DNS and Automount :) > > Simo's 'Directory' and 'Configuration' were merged into existing 'IPA server' > with the difference that all RBAC related stuff is under one item (this option > was mentioned by Petr3). Btw RBAC === "Existing items in 'Directory'". The > label is 'IPA Server' because almost everything is related to configuration of > the server itself maybe with exception of Trust and Views. Label > 'Configuration' is too general. Label Directory was quite low-level as pointed > out by Dmitry. > > This merge allows us to add 'Help' in a future. > > It would be good to move something into "Network services" (and maybe rename > it) since it has only two(three in future) items. Thanks for returning to this effort. 4.0 is indeed the right place to do this change. Note that with this proposal, Identity tab is already full. I would still prefer my original proposal to split Users and Hosts operations + have Infrastructure/Trusts tab (some variation of http://www.redhat.com/archives/freeipa-devel/2014-June/msg00060.html), but apparently this crowded Identity tab is what people want :) I would still recommend running it by UX. Few comments: - s/Network services/Network Services/ - Radius Proxy page returns an error, instead of 0 configured proxies Martin From mbasti at redhat.com Mon Jun 30 07:43:07 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 09:43:07 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140627110329.GY7233@redhat.com> References: <1403254103.2336.6.camel@unused-4-145.brq.redhat.com> <20140627081516.GS7233@redhat.com> <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> <20140627110329.GY7233@redhat.com> Message-ID: <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> On Fri, 2014-06-27 at 14:03 +0300, Alexander Bokovoy wrote: > On Fri, 27 Jun 2014, Martin Kosek wrote: > >On 06/27/2014 12:10 PM, Alexander Bokovoy wrote: > >> On Fri, 27 Jun 2014, Petr Spacek wrote: > >>> On 27.6.2014 11:21, Jan Cholasta wrote: > >>>> On 27.6.2014 10:58, Alexander Bokovoy wrote: > >>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: > >>>>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: > >>>>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: > >>>>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: > >>>>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: > >>>>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: > >>>>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: > >>>>>>>>>>>> Due to compability with older versions, only IDNA domains should be > >>>>>>>>>>>> checked > >>>>>>>>>>>> Patch attached. > >>>>>>>>>>> > >>>>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't > >>>>>>>>>>> there a > >>>>>>>>>>> better way to do this check? > >>>>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN > >>>>>>>>>> string. > >>>>>>>>>> > >>>>>>>>>> Or just remove this validation. > >>>>>>>>>> > >>>>>>>>>>> (BTW I really think this should be a warning, not an error, but that > >>>>>>>>>>> would require larger amount of work, so I guess it's OK for now.) > >>>>>>>>>> (More pain than gain) > >>>>>>>>> Main thing in this patch is that the check should not be done against > >>>>>>>>> non-IDN strings. I want this version of the patch to go in for that > >>>>>>>>> reason as currently you cannot even complete ipa-adtrust-install > >>>>>>>>> run due > >>>>>>>>> to IDN normalisation check being applied to non-IDN domains. > >>>>>>>> > >>>>>>>> On non-IDN domains, the only effect of IDN normalization is that it > >>>>>>>> lower-cases the names (right?), so the check should compare > >>>>>>>> lower-cased original name with the normalized name, instead of > >>>>>>>> special-casing certain characters etc. > >>>>>>> .. what's the reason to do such comparison then? lower-cased non-IDN > >>>>>>> name will be equal to lower-cased normalized non-IDN name by definition, > >>>>>>> so the check is not needed in this case, at all. > >>>>>> > >>>>>> The point is that it works for both IDN and non-IDN, without > >>>>>> u'\xdf'-style hacks. > >>>>> No, your proposal of comparing low-cased value and normalized value is > >>>>> not going to work because low-cased value is in general not equal to > >>>>> normalized value for IDN names, only for non-IDN ones, due to the fact > >>>>> that lower case for non-ASCII Unicode character may map to a completely > >>>>> different character than in normalization situation. Take, for example, > >>>>> Turkish alphabet where there are six letters with different case rules > >>>>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with > >>>>> breve accent, and upper- and lowercase S with cedilla), which will break > >>>>> your generalized check. > >>>>> So you'll anyway will need to split these cases. > >>>>> > >>>> > >>>> I see. > >>>> > >>>> I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in > >>>> this particular spot. Can we check that a name is IDN some other way than > >>>> "domain_name.is_idn() or u'\xdf' in value"? > >>> > >>> Why can't we simply fix string constants in ipa-adtrust-install and avoid > >>> adding hacks for it? > >> Because they are correct, in the sense that they follow what is defined > >> for Active Directory. Yes, AD puts them in that case into DNS. There is > >> simply no reason to force lower case for non-IDN names. > >> > >> That said, a newer fix is attached, where error message is formatted > >> properly. > > > >I would personally be OK with the change if the is_* are fixed as Honza > >proposed, current way is not so Python-ic/readable. I.e.: > > > >Instead of > >+ is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] > >Use > >+ is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) > > > >Instead of > >+ is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in > >labels] > >use > >+ is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) > > > >However, we can wait till Monday for Martin2's feedback. > I've fixed this and also made a proper split on all dots that could > separate labels according to RFC3490: > > U+002E ( . ) FULL STOP > U+FF0E ( ? ) FULLWIDTH FULL STOP > U+3002 ( ? ) IDEOGRAPHIC FULL STOP > U+FF61 ( ? ) HALFWIDTH IDEOGRAPHIC FULL STOP > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, I analyzed how python detects IDNA labels. Python tests if domain is IDNA in this way: def ToASCII(label): try: # Step 1: try ASCII label = label.encode("ascii") except UnicodeError: pass else: # Skip to step 3: UseSTD3ASCIIRules is false, so # Skip to step 8. if 0 < len(label) < 64: return label raise UnicodeError("label empty or too long") # Step 2: nameprep label = nameprep(label) ... We can use 'label = label.encode("ascii")' to detect if IDNA is needed, without idna.ToASCII() conversion, and then use: is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) -- Martin^2 Basti From abokovoy at redhat.com Mon Jun 30 08:43:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jun 2014 11:43:32 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> References: <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> <20140627110329.GY7233@redhat.com> <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> Message-ID: <20140630084332.GA13108@redhat.com> On Mon, 30 Jun 2014, Martin Basti wrote: >On Fri, 2014-06-27 at 14:03 +0300, Alexander Bokovoy wrote: >> On Fri, 27 Jun 2014, Martin Kosek wrote: >> >On 06/27/2014 12:10 PM, Alexander Bokovoy wrote: >> >> On Fri, 27 Jun 2014, Petr Spacek wrote: >> >>> On 27.6.2014 11:21, Jan Cholasta wrote: >> >>>> On 27.6.2014 10:58, Alexander Bokovoy wrote: >> >>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >> >>>>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: >> >>>>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: >> >>>>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: >> >>>>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: >> >>>>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: >> >>>>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: >> >>>>>>>>>>>> Due to compability with older versions, only IDNA domains should be >> >>>>>>>>>>>> checked >> >>>>>>>>>>>> Patch attached. >> >>>>>>>>>>> >> >>>>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't >> >>>>>>>>>>> there a >> >>>>>>>>>>> better way to do this check? >> >>>>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN >> >>>>>>>>>> string. >> >>>>>>>>>> >> >>>>>>>>>> Or just remove this validation. >> >>>>>>>>>> >> >>>>>>>>>>> (BTW I really think this should be a warning, not an error, but that >> >>>>>>>>>>> would require larger amount of work, so I guess it's OK for now.) >> >>>>>>>>>> (More pain than gain) >> >>>>>>>>> Main thing in this patch is that the check should not be done against >> >>>>>>>>> non-IDN strings. I want this version of the patch to go in for that >> >>>>>>>>> reason as currently you cannot even complete ipa-adtrust-install >> >>>>>>>>> run due >> >>>>>>>>> to IDN normalisation check being applied to non-IDN domains. >> >>>>>>>> >> >>>>>>>> On non-IDN domains, the only effect of IDN normalization is that it >> >>>>>>>> lower-cases the names (right?), so the check should compare >> >>>>>>>> lower-cased original name with the normalized name, instead of >> >>>>>>>> special-casing certain characters etc. >> >>>>>>> .. what's the reason to do such comparison then? lower-cased non-IDN >> >>>>>>> name will be equal to lower-cased normalized non-IDN name by definition, >> >>>>>>> so the check is not needed in this case, at all. >> >>>>>> >> >>>>>> The point is that it works for both IDN and non-IDN, without >> >>>>>> u'\xdf'-style hacks. >> >>>>> No, your proposal of comparing low-cased value and normalized value is >> >>>>> not going to work because low-cased value is in general not equal to >> >>>>> normalized value for IDN names, only for non-IDN ones, due to the fact >> >>>>> that lower case for non-ASCII Unicode character may map to a completely >> >>>>> different character than in normalization situation. Take, for example, >> >>>>> Turkish alphabet where there are six letters with different case rules >> >>>>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with >> >>>>> breve accent, and upper- and lowercase S with cedilla), which will break >> >>>>> your generalized check. >> >>>>> So you'll anyway will need to split these cases. >> >>>>> >> >>>> >> >>>> I see. >> >>>> >> >>>> I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in >> >>>> this particular spot. Can we check that a name is IDN some other way than >> >>>> "domain_name.is_idn() or u'\xdf' in value"? >> >>> >> >>> Why can't we simply fix string constants in ipa-adtrust-install and avoid >> >>> adding hacks for it? >> >> Because they are correct, in the sense that they follow what is defined >> >> for Active Directory. Yes, AD puts them in that case into DNS. There is >> >> simply no reason to force lower case for non-IDN names. >> >> >> >> That said, a newer fix is attached, where error message is formatted >> >> properly. >> > >> >I would personally be OK with the change if the is_* are fixed as Honza >> >proposed, current way is not so Python-ic/readable. I.e.: >> > >> >Instead of >> >+ is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] >> >Use >> >+ is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) >> > >> >Instead of >> >+ is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in >> >labels] >> >use >> >+ is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) >> > >> >However, we can wait till Monday for Martin2's feedback. >> I've fixed this and also made a proper split on all dots that could >> separate labels according to RFC3490: >> >> U+002E ( . ) FULL STOP >> U+FF0E ( ? ) FULLWIDTH FULL STOP >> U+3002 ( ? ) IDEOGRAPHIC FULL STOP >> U+FF61 ( ? ) HALFWIDTH IDEOGRAPHIC FULL STOP >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > >Hi, >I analyzed how python detects IDNA labels. > >Python tests if domain is IDNA in this way: > >def ToASCII(label): > try: > # Step 1: try ASCII > label = label.encode("ascii") > except UnicodeError: > pass > else: > # Skip to step 3: UseSTD3ASCIIRules is false, so > # Skip to step 8. > if 0 < len(label) < 64: > return label > raise UnicodeError("label empty or too long") > > # Step 2: nameprep > label = nameprep(label) >... > >We can use 'label = label.encode("ascii")' to detect if IDNA is needed, >without idna.ToASCII() conversion, and then use: > >is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) Sounds good but don't forget exceptions' handling. :) -- / Alexander Bokovoy From pvoborni at redhat.com Mon Jun 30 08:54:28 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 10:54:28 +0200 Subject: [Freeipa-devel] [PATCH] 692 webui: capitalize labels of undo and undo all buttons In-Reply-To: <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> References: <53AD5F83.5040003@redhat.com> <20140630071300.GN2417@dhcp-40-8.bne.redhat.com> Message-ID: <53B125C4.9000708@redhat.com> On 30.6.2014 09:13, Fraser Tweedale wrote: > On Fri, Jun 27, 2014 at 02:11:47PM +0200, Petr Vobornik wrote: >> Make the label of these buttons consistent with other buttons which have >> capital first letters. >> -- >> Petr Vobornik > >> From 7214242fb0c5accc45b6af476a8ff7e7b1a7883f Mon Sep 17 00:00:00 2001 >> From: Petr Vobornik >> Date: Fri, 27 Jun 2014 13:59:11 +0200 >> Subject: [PATCH] webui: capitalize labels of undo and undo all buttons >> >> Make the label of these buttons consistent with other buttons which have >> capital first letters. >> --- >> install/ui/test/data/ipa_init.json | 4 ++-- >> ipalib/plugins/internal.py | 4 ++-- >> 2 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json >> index 0c32395ee7d68440aea0271359b0ac88fed86c42..20a462fff3b664d2320946765d1dac21ac2b1929 100644 >> --- a/install/ui/test/data/ipa_init.json >> +++ b/install/ui/test/data/ipa_init.json >> @@ -563,8 +563,8 @@ >> "next": "Next", >> "page": "Page", >> "prev": "Prev", >> - "undo": "undo", >> - "undo_all": "undo all", >> + "undo": "Undo", >> + "undo_all": "Undo All", >> "validation": { >> "error": "Text does not match field pattern", >> "datetime": "Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")", >> diff --git a/ipalib/plugins/internal.py b/ipalib/plugins/internal.py >> index f9ae831dc665b1282ded798023856dacec480e3b..cda9fdc7ba5237bc5bcfddbce20f47abbc210a40 100644 >> --- a/ipalib/plugins/internal.py >> +++ b/ipalib/plugins/internal.py >> @@ -708,8 +708,8 @@ class i18n_messages(Command): >> "next": _("Next"), >> "page": _("Page"), >> "prev": _("Prev"), >> - "undo": _("undo"), >> - "undo_all": _("undo all"), >> + "undo": _("Undo"), >> + "undo_all": _("Undo All"), > > Does this affect translations? The msgid "undo all" is present in > the PO files. Yes > > Fraser > >> "validation": { >> "error": _("Text does not match field pattern"), >> "datetime": _("Must be an UTC date/time value (e.g., \"2014-01-20 17:58:01Z\")"), >> -- >> 1.9.0 >> -- Petr Vobornik From pviktori at redhat.com Mon Jun 30 08:55:53 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 10:55:53 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53AD8B5D.2000608@redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> <53AD8B5D.2000608@redhat.com> Message-ID: <53B12619.5070904@redhat.com> On 06/27/2014 05:18 PM, Martin Kosek wrote: > On 06/27/2014 05:16 PM, Simo Sorce wrote: >> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: >>> On 06/27/2014 05:10 PM, Simo Sorce wrote: >>>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >>>>> Host Administrators could not write to service keytab attribute and >>>>> thus they could not run the host-disable command. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4284 >>>>> >>>> >>>> Any reason why Host Administrators are not members of the service >>>> Administrators group/permission by default ? >>>> >>>> Simo. >>>> >>> >>> I assume that the original intent was to allow admins to separate this >>> privileges. I.e. allow service administrators manage services on hosts but do >>> not allow them delete or disable the hosts. >> >> Sure, but I asked the opposite question. I understand you may want to >> have Service Administrators that cannot manage the host object. >> But is there ever a case where Host Administrator is not also Service >> Administrator ? >> >>> This patch fixes the reported request for Foreman integration, if you have a >>> better one fixing it as well, we can go different way. >> >> I was wondering if a group membership change wouldn't solve a class of >> problems, instead of fixing this on per permission basis, that's all. >> >> Simo. >> > > Sure, good thinking. I do not think that current framework can make one > privilege a member of another one, so this would need to be hacked in. CCing > Petr3 to get his view on this. Right, it would need to be hacked in. At the directory level there's normal membership, so any permission/privilege/role/group can be nested in any other, but IPA will probably give incomplete/confusing output for such memberships, and it won't let you edit them. -- Petr? From mkosek at redhat.com Mon Jun 30 08:58:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 10:58:05 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53B12619.5070904@redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> <53AD8B5D.2000608@redhat.com> <53B12619.5070904@redhat.com> Message-ID: <53B1269D.6030106@redhat.com> On 06/30/2014 10:55 AM, Petr Viktorin wrote: > On 06/27/2014 05:18 PM, Martin Kosek wrote: >> On 06/27/2014 05:16 PM, Simo Sorce wrote: >>> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: >>>> On 06/27/2014 05:10 PM, Simo Sorce wrote: >>>>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >>>>>> Host Administrators could not write to service keytab attribute and >>>>>> thus they could not run the host-disable command. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4284 >>>>>> >>>>> >>>>> Any reason why Host Administrators are not members of the service >>>>> Administrators group/permission by default ? >>>>> >>>>> Simo. >>>>> >>>> >>>> I assume that the original intent was to allow admins to separate this >>>> privileges. I.e. allow service administrators manage services on hosts but do >>>> not allow them delete or disable the hosts. >>> >>> Sure, but I asked the opposite question. I understand you may want to >>> have Service Administrators that cannot manage the host object. >>> But is there ever a case where Host Administrator is not also Service >>> Administrator ? >>> >>>> This patch fixes the reported request for Foreman integration, if you have a >>>> better one fixing it as well, we can go different way. >>> >>> I was wondering if a group membership change wouldn't solve a class of >>> problems, instead of fixing this on per permission basis, that's all. >>> >>> Simo. >>> >> >> Sure, good thinking. I do not think that current framework can make one >> privilege a member of another one, so this would need to be hacked in. CCing >> Petr3 to get his view on this. > > Right, it would need to be hacked in. > At the directory level there's normal membership, so any > permission/privilege/role/group can be nested in any other, but IPA will > probably give incomplete/confusing output for such memberships, and it won't > let you edit them. Ok. In that case, it seems to me that the lesser evil would be to just add this missing permission (or defer the ticket if nacked). Martin From tbabej at redhat.com Mon Jun 30 10:17:06 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Jun 2014 12:17:06 +0200 Subject: [Freeipa-devel] [PATCH] 470 Add python-yubico to BuildRequires In-Reply-To: <53AD28E2.6080507@redhat.com> References: <53AD28E2.6080507@redhat.com> Message-ID: <53B13922.3040904@redhat.com> Please note that python-yubico package is currently available in F20 updates-testing repository only. On 06/27/2014 10:18 AM, Martin Kosek wrote: > python-yubico needs to be on a machine to be able to build FreeIPA. > Without it, even ./makeapi and ./makeaci fails. > > -- > > Pushed to master under one-liner rule. > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Jun 30 10:19:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 12:19:41 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53B1269D.6030106@redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> <53AD8B5D.2000608@redhat.com> <53B12619.5070904@redhat.com> <53B1269D.6030106@redhat.com> Message-ID: <53B139BD.3020803@redhat.com> On 06/30/2014 10:58 AM, Martin Kosek wrote: > On 06/30/2014 10:55 AM, Petr Viktorin wrote: >> On 06/27/2014 05:18 PM, Martin Kosek wrote: >>> On 06/27/2014 05:16 PM, Simo Sorce wrote: >>>> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: >>>>> On 06/27/2014 05:10 PM, Simo Sorce wrote: >>>>>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >>>>>>> Host Administrators could not write to service keytab attribute and >>>>>>> thus they could not run the host-disable command. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4284 >>>>>>> >>>>>> >>>>>> Any reason why Host Administrators are not members of the service >>>>>> Administrators group/permission by default ? >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> I assume that the original intent was to allow admins to separate this >>>>> privileges. I.e. allow service administrators manage services on hosts but do >>>>> not allow them delete or disable the hosts. >>>> >>>> Sure, but I asked the opposite question. I understand you may want to >>>> have Service Administrators that cannot manage the host object. >>>> But is there ever a case where Host Administrator is not also Service >>>> Administrator ? >>>> >>>>> This patch fixes the reported request for Foreman integration, if you have a >>>>> better one fixing it as well, we can go different way. >>>> >>>> I was wondering if a group membership change wouldn't solve a class of >>>> problems, instead of fixing this on per permission basis, that's all. >>>> >>>> Simo. >>>> >>> >>> Sure, good thinking. I do not think that current framework can make one >>> privilege a member of another one, so this would need to be hacked in. CCing >>> Petr3 to get his view on this. >> >> Right, it would need to be hacked in. >> At the directory level there's normal membership, so any >> permission/privilege/role/group can be nested in any other, but IPA will >> probably give incomplete/confusing output for such memberships, and it won't >> let you edit them. > > Ok. In that case, it seems to me that the lesser evil would be to just add this > missing permission (or defer the ticket if nacked). > > Martin I agree. ACK if Simo is OK with it as well. -- Petr? From pviktori at redhat.com Mon Jun 30 10:32:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 12:32:34 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount Message-ID: <53B13CC2.6010301@redhat.com> Fix for https://fedorahosted.org/freeipa/ticket/4409 -- Petr? From pvoborni at redhat.com Mon Jun 30 10:38:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 12:38:14 +0200 Subject: [Freeipa-devel] [PATCH] 683-690 webui: OTP token sync In-Reply-To: <53AE0570.4050300@redhat.com> References: <53AC2A19.5000805@redhat.com> <53AE0570.4050300@redhat.com> Message-ID: <53B13E16.2000704@redhat.com> On 28.6.2014 01:59, Endi Sukma Dewata wrote: > On 6/26/2014 9:11 AM, Petr Vobornik wrote: >> This set of patches creates page(s) for OTP Token Sync. >> >> there are two options: >> 1. from login page by "Sync OTP Token" link. >> - user can navigate between those two pages >> 2. standalone page on `ipa/ui/sync_otp.html` which is not linked to UI >> and can be used separately. >> >> Both share the same code. >> >> All dependencies should be in master. >> >> This implements only ticket: https://fedorahosted.org/freeipa/ticket/4218 >> >> Sync by authenticated user will be implemented later in tickets: >> https://fedorahosted.org/freeipa/ticket/4365 >> https://fedorahosted.org/freeipa/ticket/4366 >> >> >> Patch descriptions: >> >> == [PATCH] 683 webui: base class for LoginScreen-like facets == >> LoginScreen has layout which can be reused for other facets/widgets, >> e.g. for Sync OTP facet >> >> == [PATCH] 684 webui: add OTP token synchronization == >> New SyncOTPScreen widget and related facet >> >> == [PATCH] 685 webui: add link pointing to OTP sync page to login == >> >> == [PATCH] 686 webui: support global notifications in all containers == >> Global notifications were limited to "main" container. Now they have >> their own container which is displayed over other ones. It makes them >> usable everywhere. >> >> == [PATCH] 687 webui: bind Login facet and OTP sync facet == >> Simple plugin which handles transition from login facet to OTP sync >> facet and vice versa. >> >> == [PATCH] 688 webui: fix confirmation mixin origin check == >> Current check is not enough. >> >> == [PATCH] 689 webui: layer for standalone pages which use WebUI >> framework == >> Current compiled Web UI layer (app.js) contains every FreeIPA plugin and >> not just the UI framework. It's not possible to start just a simple >> facet. >> >> This commit creates a basis for a layer (core.js) which contains only >> framework code and not entity related code. >> >> == [PATCH] 690 webui: add sync_otp.html == >> standalone page for OTP token synchronization. It reuses SyncOTPScreen >> widget instead of reimplementing the logic as in other standalone pages. > > ACK. Some functionalities are not working, but they seem to be server > issues. The UI itself seems to be fine with possible improvements below. pushed to master: * d159662aded445418516c3ccb492bca33fbb11e5 webui: base class for LoginScreen-like facets * 30b1256b6231610812b394e3363394690a297201 webui: add OTP token synchronization * 72a107c9d73d1576f3adf7928deef4b5e5f35a83 webui: add link pointing to OTP sync page to login * d9a7fcb5e1c1f18cff1287353b9316fe69e07a78 webui: support global notifications in all containers * 9dbeeb7556929e76d652579533d0972479c0dc98 webui: bind Login facet and OTP sync facet * c2c1131a7a3745a3bdcf9cea8a5c8203e3ae555b webui: fix confirmation mixin origin check * 46a42de5324390496fa70984c2d8cef7a6251b7a webui: layer for standalone pages which use WebUI framework * b36a3c693b7eeb36b25eac11da89c0dd5446eb71 webui: add sync_otp.html > > 1. The link to Sync OTP Token is not very visible and probably rarely > used, so probably it can be moved together with the other messages ("To > login with...") and be given a longer description. > > 2. The Sync OTP page should explain that for the second OTP the user > should generate or wait for a new one. #1, #2, #4 added to https://fedorahosted.org/freeipa/ticket/4402#comment:1 I would like to focus UI work in 4.1 release on usability issues. > > 3. In the standalone Sync OTP page, after a successful sync should it > just display a confirmation message without displaying the form again? > Or maybe it should go to the Login page, or provide a link to it, > because most people probably wants to login after sync. Yes, it's intentional. It's for single purpose use cases where you don't want to do anything with the UI. But, maybe we should make possible to bookmark UI's sync facet. Atm, there is an obstacle that routing is enabled after login. > > 4. Unrelated. In the password reset page the "Reset Password and Login" > button is not quite accurate for OTP case since the user will not be > logged in automatically. > > 5. Server issue. TOTP can be used multiple times: > https://fedorahosted.org/freeipa/ticket/4410 > > 6. Server issue. Kinit doesn't seem to be working with OTP. > https://fedorahosted.org/freeipa/ticket/4411 > > 7. Seems to be server issue too. HOTP doesn't seem to be working for > login or sync. > https://fedorahosted.org/freeipa/ticket/4412 > -- Petr Vobornik From mbasti at redhat.com Mon Jun 30 10:48:30 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 12:48:30 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod Message-ID: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0082-Add-warning-about-semantic-change-for-zones.patch Type: text/x-patch Size: 3002 bytes Desc: not available URL: From mbasti at redhat.com Mon Jun 30 10:49:40 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 12:49:40 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message Message-ID: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0083-DNSSEC-experimental-support-warning-message.patch Type: text/x-patch Size: 3083 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 30 11:01:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 13:01:22 +0200 Subject: [Freeipa-devel] [PATCH] 691 webui-ci: fix action list action visibility and enablement assertion In-Reply-To: <53AE068D.5070005@redhat.com> References: <53AC2AF3.6020701@redhat.com> <53AE068D.5070005@redhat.com> Message-ID: <53B14382.2070802@redhat.com> On 28.6.2014 02:04, Endi Sukma Dewata wrote: > On 6/26/2014 9:15 AM, Petr Vobornik wrote: >> Fixes CA-less CI test fail >> >> The new html structure was not addressed properly. > > The new code is checking for the 'disabled' class in the list element, > not the link element, is this correct? > > is_enabled = not self.has_class(li, 'disabled') Yes, the html structure of a disabled item is: > > If test works, ACK. > Pushed to master: 029649c05cbf9edfc80d4552dec479ab24d4872c -- Petr Vobornik From tbabej at redhat.com Mon Jun 30 11:09:15 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 30 Jun 2014 13:09:15 +0200 Subject: [Freeipa-devel] [PATCH 0237] ipa-client-install: Restart nisdomain service instead of Message-ID: <53B1455B.3070009@redhat.com> Hi, To ensure new NIS domain name is loaded after ipa-client-install even in case when nisdomainname service is already running, we need to restart the service rather than starting it. https://fedorahosted.org/freeipa/ticket/4393 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0237-ipa-client-install-Restart-nisdomain-service-instead.patch Type: text/x-patch Size: 1270 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 30 11:13:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 13:13:20 +0200 Subject: [Freeipa-devel] [PATCH] 677 webui: support unlock user command In-Reply-To: <53AD9737.3030907@redhat.com> References: <53A99CC9.1070905@redhat.com> <53AD9737.3030907@redhat.com> Message-ID: <53B14650.2080105@redhat.com> On 27.6.2014 18:09, Endi Sukma Dewata wrote: > On 6/24/2014 10:44 AM, Petr Vobornik wrote: >> Call user-unlock command from Web UI. >> >> It will unlock displayed user on current master. >> >> related to: >> https://fedorahosted.org/freeipa/ticket/2792 > > Looks like there's a server problem (ticket #4409), but the UI is fine, > so ACK. > Pushed to master: 35d3f03843536613b6fdb4e0cf07c44f5d8b5140 -- Petr Vobornik From pvoborni at redhat.com Mon Jun 30 11:39:01 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 13:39:01 +0200 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <20140630044149.GM2417@dhcp-40-8.bne.redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> <53AD314F.50906@redhat.com> <20140630044149.GM2417@dhcp-40-8.bne.redhat.com> Message-ID: <53B14C55.50005@redhat.com> On 30.6.2014 06:41, Fraser Tweedale wrote: > On Fri, Jun 27, 2014 at 10:54:39AM +0200, Petr Vobornik wrote: >> On 27.6.2014 09:48, Fraser Tweedale wrote: >>> On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: >>>> Patch 618 fixes a bug. >>>> >>>> Patches 680 and 681 were implemented along with it. They address pspacek's >>>> usability rant :). >>>> >>>> [PATCH] 680 webui: show notification instead of modal dialog on validation >>>> error >>>> [PATCH] 681 webui: fix required error notification in multivalued widget >>>> [PATCH] 682 webui: focus invalid widget on validation error >>>> -- >>>> Petr Vobornik >>> >>> ACK on 680 and 682. >>> >>> On 681: diff makes sense; I'm not 100% sure my testing has covered >>> cases that were previously failing. ACK if you're confident, >>> otherwise could you provide steps to verify? >> >> You need to find a required multivalued field. One is in "Identity/Realm >> Domains". Delete all values and hit update. It's little bit related to >> ticket: https://fedorahosted.org/freeipa/ticket/4057 >> >> Also when verifying validators in multivalued field, it's good to check if >> errors are provided only for "invalid" values, etc.. good test field is in >> "DNS/DNS Zones/some zone/Settings/ there is "Allow query" field which >> accepts network address, "any" or "none". >> > > I can't discern any difference in behaviour of the multi-value > fields from before and after your patch. I tried with the > "Identity/Realm Domains" as suggested. > > Maybe I missed something. Has someone else been able to verify? Expected result is: http://pvoborni.fedorapeople.org/images/multivalued-w-required-msg.png Without the patch, there is no red highlight and no error message. > > Fraser > >>> >>> Cheers, >>> >>> Fraser >>> >> -- >> Petr Vobornik -- Petr Vobornik From mkosek at redhat.com Mon Jun 30 11:40:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 13:40:41 +0200 Subject: [Freeipa-devel] [PATCH] 470 Add python-yubico to BuildRequires In-Reply-To: <53B13922.3040904@redhat.com> References: <53AD28E2.6080507@redhat.com> <53B13922.3040904@redhat.com> Message-ID: <53B14CB9.1030007@redhat.com> Right. I assume that Nathaniel would soon move that to stable updates repository if no blocking issue emerges. Martin On 06/30/2014 12:17 PM, Tomas Babej wrote: > Please note that python-yubico package is currently available in F20 > updates-testing repository only. > > On 06/27/2014 10:18 AM, Martin Kosek wrote: >> python-yubico needs to be on a machine to be able to build FreeIPA. >> Without it, even ./makeapi and ./makeaci fails. >> >> -- >> >> Pushed to master under one-liner rule. >> >> Martin >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > From abokovoy at redhat.com Mon Jun 30 11:46:14 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jun 2014 14:46:14 +0300 Subject: [Freeipa-devel] [PATCH 0237] ipa-client-install: Restart nisdomain service instead of In-Reply-To: <53B1455B.3070009@redhat.com> References: <53B1455B.3070009@redhat.com> Message-ID: <20140630114614.GC13108@redhat.com> On Mon, 30 Jun 2014, Tomas Babej wrote: >Hi, > >To ensure new NIS domain name is loaded after ipa-client-install >even in case when nisdomainname service is already running, we >need to restart the service rather than starting it. > >https://fedorahosted.org/freeipa/ticket/4393 ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Jun 30 11:47:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jun 2014 14:47:17 +0300 Subject: [Freeipa-devel] [PATCH] 470 Add python-yubico to BuildRequires In-Reply-To: <53B14CB9.1030007@redhat.com> References: <53AD28E2.6080507@redhat.com> <53B13922.3040904@redhat.com> <53B14CB9.1030007@redhat.com> Message-ID: <20140630114717.GD13108@redhat.com> On Mon, 30 Jun 2014, Martin Kosek wrote: >Right. I assume that Nathaniel would soon move that to stable updates >repository if no blocking issue emerges. Also for those using automatic git master builds, python-yubico is in ipa-devel repo too. -- / Alexander Bokovoy From mbasti at redhat.com Mon Jun 30 11:49:14 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 13:49:14 +0200 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <20140630084332.GA13108@redhat.com> References: <53AD2B04.40405@redhat.com> <20140627082915.GT7233@redhat.com> <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> <20140627110329.GY7233@redhat.com> <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> <20140630084332.GA13108@redhat.com> Message-ID: <1404128954.2332.17.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-30 at 11:43 +0300, Alexander Bokovoy wrote: > On Mon, 30 Jun 2014, Martin Basti wrote: > >On Fri, 2014-06-27 at 14:03 +0300, Alexander Bokovoy wrote: > >> On Fri, 27 Jun 2014, Martin Kosek wrote: > >> >On 06/27/2014 12:10 PM, Alexander Bokovoy wrote: > >> >> On Fri, 27 Jun 2014, Petr Spacek wrote: > >> >>> On 27.6.2014 11:21, Jan Cholasta wrote: > >> >>>> On 27.6.2014 10:58, Alexander Bokovoy wrote: > >> >>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: > >> >>>>>> On 27.6.2014 10:29, Alexander Bokovoy wrote: > >> >>>>>>> On Fri, 27 Jun 2014, Jan Cholasta wrote: > >> >>>>>>>> On 27.6.2014 10:15, Alexander Bokovoy wrote: > >> >>>>>>>>> On Fri, 20 Jun 2014, Martin Basti wrote: > >> >>>>>>>>>> On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote: > >> >>>>>>>>>>> On 18.6.2014 16:49, Martin Basti wrote: > >> >>>>>>>>>>>> Due to compability with older versions, only IDNA domains should be > >> >>>>>>>>>>>> checked > >> >>>>>>>>>>>> Patch attached. > >> >>>>>>>>>>> > >> >>>>>>>>>>> I'm not particularly happy about the u'\xdf' special case. Isn't > >> >>>>>>>>>>> there a > >> >>>>>>>>>>> better way to do this check? > >> >>>>>>>>>> I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN > >> >>>>>>>>>> string. > >> >>>>>>>>>> > >> >>>>>>>>>> Or just remove this validation. > >> >>>>>>>>>> > >> >>>>>>>>>>> (BTW I really think this should be a warning, not an error, but that > >> >>>>>>>>>>> would require larger amount of work, so I guess it's OK for now.) > >> >>>>>>>>>> (More pain than gain) > >> >>>>>>>>> Main thing in this patch is that the check should not be done against > >> >>>>>>>>> non-IDN strings. I want this version of the patch to go in for that > >> >>>>>>>>> reason as currently you cannot even complete ipa-adtrust-install > >> >>>>>>>>> run due > >> >>>>>>>>> to IDN normalisation check being applied to non-IDN domains. > >> >>>>>>>> > >> >>>>>>>> On non-IDN domains, the only effect of IDN normalization is that it > >> >>>>>>>> lower-cases the names (right?), so the check should compare > >> >>>>>>>> lower-cased original name with the normalized name, instead of > >> >>>>>>>> special-casing certain characters etc. > >> >>>>>>> .. what's the reason to do such comparison then? lower-cased non-IDN > >> >>>>>>> name will be equal to lower-cased normalized non-IDN name by definition, > >> >>>>>>> so the check is not needed in this case, at all. > >> >>>>>> > >> >>>>>> The point is that it works for both IDN and non-IDN, without > >> >>>>>> u'\xdf'-style hacks. > >> >>>>> No, your proposal of comparing low-cased value and normalized value is > >> >>>>> not going to work because low-cased value is in general not equal to > >> >>>>> normalized value for IDN names, only for non-IDN ones, due to the fact > >> >>>>> that lower case for non-ASCII Unicode character may map to a completely > >> >>>>> different character than in normalization situation. Take, for example, > >> >>>>> Turkish alphabet where there are six letters with different case rules > >> >>>>> (uppercase dotted i, dottless lowercase i, upper- and lowercase G with > >> >>>>> breve accent, and upper- and lowercase S with cedilla), which will break > >> >>>>> your generalized check. > >> >>>>> So you'll anyway will need to split these cases. > >> >>>>> > >> >>>> > >> >>>> I see. > >> >>>> > >> >>>> I'm still not comfortable with carrying the bit of knowledge about u'\xdf' in > >> >>>> this particular spot. Can we check that a name is IDN some other way than > >> >>>> "domain_name.is_idn() or u'\xdf' in value"? > >> >>> > >> >>> Why can't we simply fix string constants in ipa-adtrust-install and avoid > >> >>> adding hacks for it? > >> >> Because they are correct, in the sense that they follow what is defined > >> >> for Active Directory. Yes, AD puts them in that case into DNS. There is > >> >> simply no reason to force lower case for non-IDN names. > >> >> > >> >> That said, a newer fix is attached, where error message is formatted > >> >> properly. > >> > > >> >I would personally be OK with the change if the is_* are fixed as Honza > >> >proposed, current way is not so Python-ic/readable. I.e.: > >> > > >> >Instead of > >> >+ is_idna = True in [encodings.idna.ToASCII(x) != x for x in labels] > >> >Use > >> >+ is_idna = any(encodings.idna.ToASCII(x) != x for x in labels) > >> > > >> >Instead of > >> >+ is_nonnorm = True in [encodings.idna.nameprep(x) != x for x in > >> >labels] > >> >use > >> >+ is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) > >> > > >> >However, we can wait till Monday for Martin2's feedback. > >> I've fixed this and also made a proper split on all dots that could > >> separate labels according to RFC3490: > >> > >> U+002E ( . ) FULL STOP > >> U+FF0E ( ? ) FULLWIDTH FULL STOP > >> U+3002 ( ? ) IDEOGRAPHIC FULL STOP > >> U+FF61 ( ? ) HALFWIDTH IDEOGRAPHIC FULL STOP > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > >Hi, > >I analyzed how python detects IDNA labels. > > > >Python tests if domain is IDNA in this way: > > > >def ToASCII(label): > > try: > > # Step 1: try ASCII > > label = label.encode("ascii") > > except UnicodeError: > > pass > > else: > > # Skip to step 3: UseSTD3ASCIIRules is false, so > > # Skip to step 8. > > if 0 < len(label) < 64: > > return label > > raise UnicodeError("label empty or too long") > > > > # Step 2: nameprep > > label = nameprep(label) > >... > > > >We can use 'label = label.encode("ascii")' to detect if IDNA is needed, > >without idna.ToASCII() conversion, and then use: > > > >is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) > Sounds good but don't forget exceptions' handling. :) > Updated patch attached. I modified error messages, IDNA mapping is not only mapping to lowercase -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0070-2-Check-normalization-only-for-IDNA-domains.patch Type: text/x-patch Size: 3504 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 30 11:51:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 13:51:12 +0200 Subject: [Freeipa-devel] [RFC] Release notes for FreeIPA 4.0 Message-ID: <53B14F30.6040903@redhat.com> Hello all, We should start working on FreeIPA 4.0 release notes. Lot of work has been done, there is a lot if relase information we need to address. I created the first draft partially generated and updated from Trac enhancement tickets, including the ticket+design links: http://www.freeipa.org/page/Releases/4.0.0 I think that especially the links to respective designs will be helpful for people googling for this release. I would like to ask for your help to clean and enhance the releases notes and add more information for features doing big changes or changes in behavior. I currently have these special sections defined, other proposals welcome: * 2FA Kerberos Authenication (Nathaniel) * Reworked Control Access (Petr3) * DNS Master Forward Zones (Martin) * Experimental DNSSEC Support (Petr2, Martin) Thank you! -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From mkosek at redhat.com Mon Jun 30 11:53:32 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 13:53:32 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount In-Reply-To: <53B13CC2.6010301@redhat.com> References: <53B13CC2.6010301@redhat.com> Message-ID: <53B14FBC.8070406@redhat.com> On 06/30/2014 12:32 PM, Petr Viktorin wrote: > Fix for https://fedorahosted.org/freeipa/ticket/4409 I think something is missing here :-) From pviktori at redhat.com Mon Jun 30 11:57:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 13:57:48 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> Message-ID: <53B150BC.1080505@redhat.com> On 06/30/2014 12:48 PM, Martin Basti wrote: > Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 > Patch attached. > When you add a new message, you should also define a new class for it in messages.py with a new errno, not just reuse PublicMessage with a custom string. -- Petr? From pviktori at redhat.com Mon Jun 30 11:58:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 13:58:25 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount In-Reply-To: <53B14FBC.8070406@redhat.com> References: <53B13CC2.6010301@redhat.com> <53B14FBC.8070406@redhat.com> Message-ID: <53B150E1.9000700@redhat.com> On 06/30/2014 01:53 PM, Martin Kosek wrote: > On 06/30/2014 12:32 PM, Petr Viktorin wrote: >> Fix for https://fedorahosted.org/freeipa/ticket/4409 > > I think something is missing here :-) > Sorry for that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0610-Allow-admins-to-write-krbLoginFailedCount.patch Type: text/x-patch Size: 6158 bytes Desc: not available URL: From mkosek at redhat.com Mon Jun 30 11:59:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 13:59:19 +0200 Subject: [Freeipa-devel] [PATCH 0237] ipa-client-install: Restart nisdomain service instead of In-Reply-To: <20140630114614.GC13108@redhat.com> References: <53B1455B.3070009@redhat.com> <20140630114614.GC13108@redhat.com> Message-ID: <53B15117.3040602@redhat.com> On 06/30/2014 01:46 PM, Alexander Bokovoy wrote: > On Mon, 30 Jun 2014, Tomas Babej wrote: >> Hi, >> >> To ensure new NIS domain name is loaded after ipa-client-install >> even in case when nisdomainname service is already running, we >> need to restart the service rather than starting it. >> >> https://fedorahosted.org/freeipa/ticket/4393 > ACK. > Pushed to master: ffab09a7ef7a16b220e657e24813c90ba1a13523 Martin From mbasti at redhat.com Mon Jun 30 12:33:46 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 14:33:46 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> Message-ID: <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: > Patch attached. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0083-2-DNSSEC-experimental-support-warning-message.patch Type: text/x-patch Size: 3160 bytes Desc: not available URL: From ssorce at redhat.com Mon Jun 30 12:37:40 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2014 08:37:40 -0400 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <53B139BD.3020803@redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> <53AD8B5D.2000608@redhat.com> <53B12619.5070904@redhat.com> <53B1269D.6030106@redhat.com> <53B139BD.3020803@redhat.com> Message-ID: <1404131860.6436.36.camel@willson.usersys.redhat.com> On Mon, 2014-06-30 at 12:19 +0200, Petr Viktorin wrote: > On 06/30/2014 10:58 AM, Martin Kosek wrote: > > On 06/30/2014 10:55 AM, Petr Viktorin wrote: > >> On 06/27/2014 05:18 PM, Martin Kosek wrote: > >>> On 06/27/2014 05:16 PM, Simo Sorce wrote: > >>>> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: > >>>>> On 06/27/2014 05:10 PM, Simo Sorce wrote: > >>>>>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: > >>>>>>> Host Administrators could not write to service keytab attribute and > >>>>>>> thus they could not run the host-disable command. > >>>>>>> > >>>>>>> https://fedorahosted.org/freeipa/ticket/4284 > >>>>>>> > >>>>>> > >>>>>> Any reason why Host Administrators are not members of the service > >>>>>> Administrators group/permission by default ? > >>>>>> > >>>>>> Simo. > >>>>>> > >>>>> > >>>>> I assume that the original intent was to allow admins to separate this > >>>>> privileges. I.e. allow service administrators manage services on hosts but do > >>>>> not allow them delete or disable the hosts. > >>>> > >>>> Sure, but I asked the opposite question. I understand you may want to > >>>> have Service Administrators that cannot manage the host object. > >>>> But is there ever a case where Host Administrator is not also Service > >>>> Administrator ? > >>>> > >>>>> This patch fixes the reported request for Foreman integration, if you have a > >>>>> better one fixing it as well, we can go different way. > >>>> > >>>> I was wondering if a group membership change wouldn't solve a class of > >>>> problems, instead of fixing this on per permission basis, that's all. > >>>> > >>>> Simo. > >>>> > >>> > >>> Sure, good thinking. I do not think that current framework can make one > >>> privilege a member of another one, so this would need to be hacked in. CCing > >>> Petr3 to get his view on this. > >> > >> Right, it would need to be hacked in. > >> At the directory level there's normal membership, so any > >> permission/privilege/role/group can be nested in any other, but IPA will > >> probably give incomplete/confusing output for such memberships, and it won't > >> let you edit them. > > > > Ok. In that case, it seems to me that the lesser evil would be to just add this > > missing permission (or defer the ticket if nacked). > > > > Martin > > I agree. ACK if Simo is OK with it as well. Sure, no issues here. Simo. From pviktori at redhat.com Mon Jun 30 13:00:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 15:00:02 +0200 Subject: [Freeipa-devel] [PATCH] 472 Let Host Administrators use host-disable command In-Reply-To: <1404131860.6436.36.camel@willson.usersys.redhat.com> References: <53AD7CD3.5000704@redhat.com> <1403881818.3551.12.camel@willson.usersys.redhat.com> <53AD89F4.6000202@redhat.com> <1403882212.3551.14.camel@willson.usersys.redhat.com> <53AD8B5D.2000608@redhat.com> <53B12619.5070904@redhat.com> <53B1269D.6030106@redhat.com> <53B139BD.3020803@redhat.com> <1404131860.6436.36.camel@willson.usersys.redhat.com> Message-ID: <53B15F52.2090700@redhat.com> On 06/30/2014 02:37 PM, Simo Sorce wrote: > On Mon, 2014-06-30 at 12:19 +0200, Petr Viktorin wrote: >> On 06/30/2014 10:58 AM, Martin Kosek wrote: >>> On 06/30/2014 10:55 AM, Petr Viktorin wrote: >>>> On 06/27/2014 05:18 PM, Martin Kosek wrote: >>>>> On 06/27/2014 05:16 PM, Simo Sorce wrote: >>>>>> On Fri, 2014-06-27 at 17:12 +0200, Martin Kosek wrote: >>>>>>> On 06/27/2014 05:10 PM, Simo Sorce wrote: >>>>>>>> On Fri, 2014-06-27 at 16:16 +0200, Martin Kosek wrote: >>>>>>>>> Host Administrators could not write to service keytab attribute and >>>>>>>>> thus they could not run the host-disable command. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4284 >>>>>>>>> >>>>>>>> >>>>>>>> Any reason why Host Administrators are not members of the service >>>>>>>> Administrators group/permission by default ? >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> >>>>>>> I assume that the original intent was to allow admins to separate this >>>>>>> privileges. I.e. allow service administrators manage services on hosts but do >>>>>>> not allow them delete or disable the hosts. >>>>>> >>>>>> Sure, but I asked the opposite question. I understand you may want to >>>>>> have Service Administrators that cannot manage the host object. >>>>>> But is there ever a case where Host Administrator is not also Service >>>>>> Administrator ? >>>>>> >>>>>>> This patch fixes the reported request for Foreman integration, if you have a >>>>>>> better one fixing it as well, we can go different way. >>>>>> >>>>>> I was wondering if a group membership change wouldn't solve a class of >>>>>> problems, instead of fixing this on per permission basis, that's all. >>>>>> >>>>>> Simo. >>>>>> >>>>> >>>>> Sure, good thinking. I do not think that current framework can make one >>>>> privilege a member of another one, so this would need to be hacked in. CCing >>>>> Petr3 to get his view on this. >>>> >>>> Right, it would need to be hacked in. >>>> At the directory level there's normal membership, so any >>>> permission/privilege/role/group can be nested in any other, but IPA will >>>> probably give incomplete/confusing output for such memberships, and it won't >>>> let you edit them. >>> >>> Ok. In that case, it seems to me that the lesser evil would be to just add this >>> missing permission (or defer the ticket if nacked). >>> >>> Martin >> >> I agree. ACK if Simo is OK with it as well. > > Sure, no issues here. > > Simo. > > > Pushed to master: 50c30c8401c21d43414404bd5caa157196449e4c -- Petr? From abokovoy at redhat.com Mon Jun 30 13:16:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Jun 2014 16:16:23 +0300 Subject: [Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains In-Reply-To: <1404128954.2332.17.camel@unused-4-145.brq.redhat.com> References: <53AD2DCD.1070401@redhat.com> <20140627085821.GU7233@redhat.com> <53AD379A.7080605@redhat.com> <53AD41DB.6080901@redhat.com> <20140627101059.GW7233@redhat.com> <53AD482B.4030107@redhat.com> <20140627110329.GY7233@redhat.com> <1404114187.2332.12.camel@unused-4-145.brq.redhat.com> <20140630084332.GA13108@redhat.com> <1404128954.2332.17.camel@unused-4-145.brq.redhat.com> Message-ID: <20140630131623.GE13108@redhat.com> On Mon, 30 Jun 2014, Martin Basti wrote: >> >We can use 'label = label.encode("ascii")' to detect if IDNA is needed, >> >without idna.ToASCII() conversion, and then use: >> > >> >is_nonnorm = any(encodings.idna.nameprep(x) != x for x in labels) >> Sounds good but don't forget exceptions' handling. :) >> > >Updated patch attached. > >I modified error messages, IDNA mapping is not only mapping to lowercase Looks good to me. -- / Alexander Bokovoy From kybaker at redhat.com Mon Jun 30 13:58:31 2014 From: kybaker at redhat.com (Kyle Baker) Date: Mon, 30 Jun 2014 09:58:31 -0400 (EDT) Subject: [Freeipa-devel] Reorganization of Web UI navigation items In-Reply-To: <53B11014.9020502@redhat.com> References: <538C8338.1040502@redhat.com> <53ADA987.4050808@redhat.com> <53B11014.9020502@redhat.com> Message-ID: <815350251.994368.1404136711269.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 06/27/2014 07:27 PM, Petr Vobornik wrote: > > On 2.6.2014 15:59, Petr Vobornik wrote: > >> Hi List, > >> > >> the purpose if this mail is to start a discussion about reorganization > >> of navigation items. Users are not fond of such change so we should come > >> up with a solution which would last for some time. > >> > >> Problem: > >> UX recommendation is that one menu level should contain maximum of 7 > >> items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. > >> Basically we reached max. capacity of all 1st-level items. > >> > >> Solution: > >> Introduce new 1st-level items and redistribute 2nd-level items. > >> > > > > It would be great to get this into 4.0, resuming the discussion. My > > proposal > > which takes into account various other proposals: > > > > Identity (7) > > - Users > > - User Groups > > - Hosts > > - Host Groups > > - Netgroups > > - Services > > - Automember > > - User group rules > > - Host group rules > > Policy (5) > > - Host Based Access Control > > - HBAC Rules > > - HBAC Services > > - HBAC Service Groups > > - HBAC Test > > - Sudo > > - Sudo Rules > > - Sudo Commands > > - Sudo Command Groups > > - SELinux User Maps > > - Password Policies > > - Kerberos Ticket Policy > > Authentication (3-4) > > - Certificates > > - (future) User Certificates > > - OTP Tokens > > - RADIUS Servers > > Network services (2-3) > > - Automount > > - DNS > > - DNS Zones > > - DNS Forward Zones > > - DNS Global Configuration > > - (future) Vault > > IPA Server (5-7) > > - Role Based Access Control > > - Roles > > - Privileges > > - Permissions > > - Self Service Permissions > > - Delegations > > - ID Ranges > > - Realm Domain > > - (future) Replication Topology > > - Trusts > > - Trusts > > - Global Trust Configuration > > - (future) Views > > - Configuration > > (future) Help > > - Docs > > - API > > - ... > > > > Mostly it's a response to the last proposal: > > http://www.redhat.com/archives/freeipa-devel/2014-June/msg00107.html > > > > You can check live version at: http://pvoborni.fedorapeople.org/ui/ > > > > From the earlier discussion I would say, that there was an agreement on > > Identity and Policy tabs which are very similar to current implementation. > > > > Simo had a proposal to introduce "Authentication" tab in a future. I guess > > we > > can do it now. We already have radius server proxies and certificates are > > also > > related. It will solve the "OTP doesn't fit anywhere problem" > > > > I've kept the "Network Services" tab because IDK where to put DNS and > > Automount :) > > > > Simo's 'Directory' and 'Configuration' were merged into existing 'IPA > > server' > > with the difference that all RBAC related stuff is under one item (this > > option > > was mentioned by Petr3). Btw RBAC === "Existing items in 'Directory'". The > > label is 'IPA Server' because almost everything is related to configuration > > of > > the server itself maybe with exception of Trust and Views. Label > > 'Configuration' is too general. Label Directory was quite low-level as > > pointed > > out by Dmitry. > > > > This merge allows us to add 'Help' in a future. > > > > It would be good to move something into "Network services" (and maybe > > rename > > it) since it has only two(three in future) items. > > Thanks for returning to this effort. 4.0 is indeed the right place to do this > change. > > Note that with this proposal, Identity tab is already full. I would still > prefer my original proposal to split Users and Hosts operations + have > Infrastructure/Trusts tab (some variation of > http://www.redhat.com/archives/freeipa-devel/2014-June/msg00060.html), but > apparently this crowded Identity tab is what people want :) I would still > recommend running it by UX. Been following the thread and the map Petr has put together here does a great job of categorizing these items. The ratio of level one to level two options is secondary to logical, intuitive groupings. I think the way Identity is here is fine. 7 options is just an average guide not the max number. I don't see the types of currency we manage increasing dramatically in the future. Even if we add four more options under Identity it should have little effect due to the logical groupings. The goal here is to not require users memorize tons of options because the top level bucket is too big or the label is to generic/specific. I think Petr has struck a great balance here. One comment - Is 'IPA Server' going to make sense in the downstream? May make sense to call it Identity Server which will make sense in both cases. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From edewata at redhat.com Mon Jun 30 14:23:09 2014 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 30 Jun 2014 09:23:09 -0500 Subject: [Freeipa-devel] [PATCH] 680-682 webui: validation reporting improvements In-Reply-To: <53AD314F.50906@redhat.com> References: <53AAFFCC.3050308@redhat.com> <20140627074849.GI2417@dhcp-40-8.bne.redhat.com> <53AD314F.50906@redhat.com> Message-ID: <53B172CD.4040002@redhat.com> On 6/27/2014 3:54 AM, Petr Vobornik wrote: > On 27.6.2014 09:48, Fraser Tweedale wrote: >> On Wed, Jun 25, 2014 at 06:58:52PM +0200, Petr Vobornik wrote: >>> Patch 618 fixes a bug. >>> >>> Patches 680 and 681 were implemented along with it. They address >>> pspacek's >>> usability rant :). >>> >>> [PATCH] 680 webui: show notification instead of modal dialog on >>> validation >>> error >>> [PATCH] 681 webui: fix required error notification in multivalued widget >>> [PATCH] 682 webui: focus invalid widget on validation error >>> -- >>> Petr Vobornik >> >> ACK on 680 and 682. >> >> On 681: diff makes sense; I'm not 100% sure my testing has covered >> cases that were previously failing. ACK if you're confident, >> otherwise could you provide steps to verify? > > You need to find a required multivalued field. One is in "Identity/Realm > Domains". Delete all values and hit update. It's little bit related to > ticket: https://fedorahosted.org/freeipa/ticket/4057 > > Also when verifying validators in multivalued field, it's good to check > if errors are provided only for "invalid" values, etc.. good test field > is in "DNS/DNS Zones/some zone/Settings/ there is "Allow query" field > which accepts network address, "any" or "none". ACK. This should be sufficient to close #4057. But just wondering, the Realm Domains page right now is implemented as a details page with a multi-valued widget. Would it make more sense to be a list page instead? The realmdomains-mod CLI is kind of unusual too with the --add/del-domain parameters. Why not use realmdomain-add/del commands? Are there other commands implemented in this fashion? -- Endi S. Dewata From mkosek at redhat.com Mon Jun 30 14:29:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Jun 2014 16:29:35 +0200 Subject: [Freeipa-devel] [PATCH] 0610 Allow admins to write krbLoginFailedCount In-Reply-To: <53B150E1.9000700@redhat.com> References: <53B13CC2.6010301@redhat.com> <53B14FBC.8070406@redhat.com> <53B150E1.9000700@redhat.com> Message-ID: <53B1744F.8060509@redhat.com> On 06/30/2014 01:58 PM, Petr Viktorin wrote: > On 06/30/2014 01:53 PM, Martin Kosek wrote: >> On 06/30/2014 12:32 PM, Petr Viktorin wrote: >>> Fix for https://fedorahosted.org/freeipa/ticket/4409 >> >> I think something is missing here :-) >> > > Sorry for that. Looks ok. Do we need to add the new "remove" definitions given that the respective ACIs were never released? I am just aiming for update file sanity. Martin From pspacek at redhat.com Mon Jun 30 14:52:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 30 Jun 2014 16:52:39 +0200 Subject: [Freeipa-devel] [PATCH 0082] Forward zones: add warning about forwarders semantic change in dnszone-add/mod In-Reply-To: <53B150BC.1080505@redhat.com> References: <1404125310.2332.14.camel@unused-4-145.brq.redhat.com> <53B150BC.1080505@redhat.com> Message-ID: <53B179B7.4090206@redhat.com> On 30.6.2014 13:57, Petr Viktorin wrote: > On 06/30/2014 12:48 PM, Martin Basti wrote: >> Ticket: https://fedorahosted.org/freeipa/ticket/3210#comment:16 >> Patch attached. >> > > When you add a new message, you should also define a new class for it in > messages.py with a new errno, not just reuse PublicMessage with a custom string. Otherwise the patch works for me. -- Petr^2 Spacek From pspacek at redhat.com Mon Jun 30 14:57:13 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 30 Jun 2014 16:57:13 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> Message-ID: <53B17AC9.1040809@redhat.com> On 30.6.2014 14:33, Martin Basti wrote: > On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: >> Patch attached. It works for me. Please change the string little bit, I have realized that we should ensure that file permissions are correct: chown named: * chmod u= * (the chmod part new) Thanks! -- Petr^2 Spacek From mbasti at redhat.com Mon Jun 30 15:10:14 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 17:10:14 +0200 Subject: [Freeipa-devel] [PATCH 0083] Add DNSSEC experimental support warning message In-Reply-To: <53B17AC9.1040809@redhat.com> References: <1404125380.2332.15.camel@unused-4-145.brq.redhat.com> <1404131626.2332.18.camel@unused-4-145.brq.redhat.com> <53B17AC9.1040809@redhat.com> Message-ID: <1404141014.2332.22.camel@unused-4-145.brq.redhat.com> On Mon, 2014-06-30 at 16:57 +0200, Petr Spacek wrote: > On 30.6.2014 14:33, Martin Basti wrote: > > On Mon, 2014-06-30 at 12:49 +0200, Martin Basti wrote: > >> Patch attached. > > It works for me. > > Please change the string little bit, I have realized that we should ensure > that file permissions are correct: > > chown named: * > chmod u= * > > (the chmod part new) > > Thanks! > Updated patch attached -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0083-3-DNSSEC-experimental-support-warning-message.patch Type: text/x-patch Size: 3173 bytes Desc: not available URL: From mbasti at redhat.com Mon Jun 30 15:13:11 2014 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jun 2014 17:13:11 +0200 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <53A94997.1050103@redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> <53A94997.1050103@redhat.com> Message-ID: <1404141191.2332.24.camel@unused-4-145.brq.redhat.com> On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: > On 23.6.2014 17:49, Martin Basti wrote: > > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: > >> Hello, > >> I have following issues: > >> > >> #1 Upgrading existing replicas to support DNSSEC won't work for current > >> design (replica-file as storage for temporal replica key). > >> Temporal private key needs to be copied to replica, and no encrypted > >> master-key for replica is prepared in LDAP, because user doesn't need to > >> run ipa-replica-prepare. > >> > >> After discussion with Petr2, the solution is: > >> a) Each replica (except first - which generates master-key) generates > >> replica public and private keys. > >> b) Replica uploads public key to LDAP > >> c) Replica with generated master key, use the public key (b) to encrypt > >> master-key and store it to LDAP. Replica with master-key must detect, if > >> there is any new public replica key. > >> d) Replica (b) is now able to get master-key using own private replica > >> key > >> > >> > >> #2 We need to choose only one replica which will generate, (rotate, ...) > >> DNSSEC keys. > > and generate master key too > > > >> My proposal is to test during installation/upgrade if any dnssec/master > >> keys are in LDAP. If no key was found, the first server is > >> installed/upgraded and DNSSEC key generator is required. > >> > >> But there is issue with parallel upgrade multiple replicas (or if > >> replication temporarily doesn't work). There is no guarantee if replicas > >> will be able to detect if any replica became DNSSEC key generator. > > Let me add that we are going to use syncrepl anyway so the overall latency > should be minimal (if replication works). > Simo what do you think about it, could you tell us your opinion? -- Martin^2 Basti From ssorce at redhat.com Mon Jun 30 15:38:29 2014 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 30 Jun 2014 11:38:29 -0400 Subject: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade In-Reply-To: <1404141191.2332.24.camel@unused-4-145.brq.redhat.com> References: <1403538245.8669.44.camel@unused-4-145.brq.redhat.com> <1403538579.8669.45.camel@unused-4-145.brq.redhat.com> <53A94997.1050103@redhat.com> <1404141191.2332.24.camel@unused-4-145.brq.redhat.com> Message-ID: <1404142709.6436.50.camel@willson.usersys.redhat.com> On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote: > On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote: > > On 23.6.2014 17:49, Martin Basti wrote: > > > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote: > > >> Hello, > > >> I have following issues: > > >> > > >> #1 Upgrading existing replicas to support DNSSEC won't work for current > > >> design (replica-file as storage for temporal replica key). > > >> Temporal private key needs to be copied to replica, and no encrypted > > >> master-key for replica is prepared in LDAP, because user doesn't need to > > >> run ipa-replica-prepare. > > >> > > >> After discussion with Petr2, the solution is: > > >> a) Each replica (except first - which generates master-key) generates > > >> replica public and private keys. > > >> b) Replica uploads public key to LDAP > > >> c) Replica with generated master key, use the public key (b) to encrypt > > >> master-key and store it to LDAP. Replica with master-key must detect, if > > >> there is any new public replica key. > > >> d) Replica (b) is now able to get master-key using own private replica > > >> key > > >> > > >> > > >> #2 We need to choose only one replica which will generate, (rotate, ...) > > >> DNSSEC keys. > > > and generate master key too > > > > > >> My proposal is to test during installation/upgrade if any dnssec/master > > >> keys are in LDAP. If no key was found, the first server is > > >> installed/upgraded and DNSSEC key generator is required. > > >> > > >> But there is issue with parallel upgrade multiple replicas (or if > > >> replication temporarily doesn't work). There is no guarantee if replicas > > >> will be able to detect if any replica became DNSSEC key generator. > > > > Let me add that we are going to use syncrepl anyway so the overall latency > > should be minimal (if replication works). > > > > Simo what do you think about it, could you tell us your opinion? I think DNSSEC should not be enabled by default, so on upgrade no action should be taken. Activation/upgrade of DNSSEC feature should be manual so that no conflict can arise. Simo. From pviktori at redhat.com Mon Jun 30 15:43:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 17:43:27 +0200 Subject: [Freeipa-devel] [PATCH] 0611 install/ui/build: Build core.js Message-ID: <53B1859F.8040205@redhat.com> IPA wouldn't build for me because of a Makefile problem. This should solve the issue. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0611-install-ui-build-Build-core.js.patch Type: text/x-patch Size: 844 bytes Desc: not available URL: From pvoborni at redhat.com Mon Jun 30 16:07:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 18:07:21 +0200 Subject: [Freeipa-devel] [PATCH 0078-0079] DNSSEC: Add TLSA record In-Reply-To: <1403873746.2249.5.camel@unused-4-145.brq.redhat.com> References: <1403699482.2323.4.camel@unused-4-145.brq.redhat.com> <1403699757.2323.5.camel@unused-4-145.brq.redhat.com> <53AC0AAA.1090403@redhat.com> <1403873746.2249.5.camel@unused-4-145.brq.redhat.com> Message-ID: <53B18B39.6040605@redhat.com> On 27.6.2014 14:55, Martin Basti wrote: > On Thu, 2014-06-26 at 13:57 +0200, Petr Vobornik wrote: >> On 25.6.2014 14:35, Martin Basti wrote: >>> On Wed, 2014-06-25 at 14:31 +0200, Martin Basti wrote: >>>> Ticket https://fedorahosted.org/freeipa/ticket/4328#comment:12 >>>> Patches attached. >>>> >>>> Note: ACI will be updated in another patch which fix ACIs in DNS plugin >>> >>> Patches are here >>> >> What are patch 0078's dependencies? I'm missing necessary blobs.. >> (current master). Also it requires rebase because of today's pushes to >> master (VERSION conflict). > > Rebased patch attached > Patch 0078-2: Just nitpicks. 1. The LDAP attribute type description should be changed to something more meaningful. the "DNS-Based Authentication of Named Entities - Transport Layer Security Protocol, RFC 6698" is the complete effort. It does not say anything about the TLSA record itself. I suggest: "TLSA certificate association, RFC 6698" which is used in chapter 2 of RFC 6698. 2. Nitpick: Not a proper alphabetic order ;) - u'TSIG', u'TXT', + u'TSIG', u'TLSA', u'TXT', Patch 0079: 3. A js-lint warning: /dns.js(1140): lint warning: extra comma is not recommended in array initializers ] ............^ Just remove the comma on line 1139. To check it, run: `jsl -nofilelisting -nologo -nosummary -conf jsl.conf` in install/ui directory -- Petr Vobornik From npmccallum at redhat.com Mon Jun 30 16:08:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 30 Jun 2014 12:08:29 -0400 Subject: [Freeipa-devel] [PATCH] 470 Add python-yubico to BuildRequires In-Reply-To: <53B14CB9.1030007@redhat.com> References: <53AD28E2.6080507@redhat.com> <53B13922.3040904@redhat.com> <53B14CB9.1030007@redhat.com> Message-ID: <1404144509.3251.0.camel@ipa.example.com> Please feel free to provide karma: https://admin.fedoraproject.org/updates/FEDORA-2014-7700/python-yubico-1.2.1-3.fc20 On Mon, 2014-06-30 at 13:40 +0200, Martin Kosek wrote: > Right. I assume that Nathaniel would soon move that to stable updates > repository if no blocking issue emerges. > > Martin > > On 06/30/2014 12:17 PM, Tomas Babej wrote: > > Please note that python-yubico package is currently available in F20 > > updates-testing repository only. > > > > On 06/27/2014 10:18 AM, Martin Kosek wrote: > >> python-yubico needs to be on a machine to be able to build FreeIPA. > >> Without it, even ./makeapi and ./makeaci fails. > >> > >> -- > >> > >> Pushed to master under one-liner rule. > >> > >> Martin > >> > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > From pvoborni at redhat.com Mon Jun 30 16:21:46 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 30 Jun 2014 18:21:46 +0200 Subject: [Freeipa-devel] [PATCH] 0611 install/ui/build: Build core.js In-Reply-To: <53B1859F.8040205@redhat.com> References: <53B1859F.8040205@redhat.com> Message-ID: <53B18E9A.1010702@redhat.com> On 30.6.2014 17:43, Petr Viktorin wrote: > IPA wouldn't build for me because of a Makefile problem. This should > solve the issue. > ACK Pushed to master: dfbd7170e901bc597462191c219c0e2b45c09afa Sorry about that. -- Petr Vobornik From pviktori at redhat.com Mon Jun 30 16:44:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 18:44:30 +0200 Subject: [Freeipa-devel] [PATCH 0077] Fix ACI in DNS (was Add dnssecinlinesigning attribute to ACI) In-Reply-To: <1403714941.2323.13.camel@unused-4-145.brq.redhat.com> References: <1403271137.2336.22.camel@unused-4-145.brq.redhat.com> <53AAA0C7.80501@redhat.com> <1403714829.2323.12.camel@unused-4-145.brq.redhat.com> <1403714941.2323.13.camel@unused-4-145.brq.redhat.com> Message-ID: <53B193EE.3060409@redhat.com> On 06/25/2014 06:49 PM, Martin Basti wrote: > On Wed, 2014-06-25 at 18:47 +0200, Martin Basti wrote: >> On Wed, 2014-06-25 at 12:13 +0200, Petr Viktorin wrote: >>> On 06/20/2014 03:32 PM, Martin Basti wrote: >>>> Required patches: mbasti-0060, mbasti-0073 >>>> >>>> Patch attached. >>>> >>> >>> Hi, >>> >>> For the raw ACI in dns.ldif, there are some more hoops to jump through. >>> >>> Remove the ACI from /install/share/dns.ldif entirely (except for schema, >>> we're slowly replacing the .ldif content by .update files). >>> >>> In install/updates/40-dns.update, you'll notice the "Update DNS entries >>> in a zone" ACI is already being added. You'll need to replace it, using >>> a line like: >>> replace:aci:'::' >>> This will remove the old value that IPA 3.x users still have. >>> >>> I see you already changed the ACI in 7cdc417, in dns.ldif only. Be >>> sureto use the original value for . >>> >>> >> As we discuss personally, ACI requires more changes than add >> idnssecinlinesingning only. >> >> Updated patch attached. >> > Patch freeipa-mbasti-0078-DNSSEC-add-TLSA-record-type.patch is required. If 0078 doesn't change substantially, ACK. -- Petr? From rcritten at redhat.com Mon Jun 30 17:36:23 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jun 2014 13:36:23 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53ADEDED.7090603@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> Message-ID: <53B1A017.4080802@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> On 26.6.2014 20:05, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 16.6.2014 15:35, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches implement >>>>> . >>>>> >>>>> My patches 241-253 and 262-294 are required for this >>>>> (, >>>>> >>>>> ). >>>>> >>>>> >>>>> The installation/testing guidelines from >>>>> >>>>> apply here as well. >>>>> >>>>> Honza >>>> >>>> Rebased on top of current master. >>> >>> 295 ACK >>> >>> 296, 297 & 299 >>> >>> TBD, need to test but no problems seen so far. >>> >>> 298 >>> >>> The man page, if not usage, should include what the valid trust flags >>> are or point to NSS documentation. >> >> OK. >> >>> >>> rob >>> >> >> Updated rebased patches attached. Also attaching all the required patches. >> A few more things after more testing. If one renews an externally-issued CA then you can end up with multiple certs for the IPA CA in /etc/pki/nssdb (for each issued cert). These do not seem to be cleaned up on uninstall. On upgrade from 3.3.5 seeing: Unexpected error - see /var/log/ipaupgrade.log for details: InvalidSyntax: object class ipaCertificate: Unknown required attribute type "ipaPublicKey": Invalid syntax. /var/log/ipaupgrade ends with: 2014-06-30T15:03:11Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2014-06-30T15:08:12Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 640, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 1171, in main ds.start(ds_serverid) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 297, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 262, in start self.wait_for_open_ports(self.service_instance(instance_name)) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 228, in wait_for_open_ports self.api.env.startup_timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1153, in wait_for_open_ports raise socket.timeout() 2014-06-30T15:08:12Z DEBUG The ipa-upgradeconfig command failed, exception: timeout: Turns out it blew up so badly that it didn't restore dse.ldif when the upgrade finished, something I thought was impossible. This is a pretty serious problem in itself (and likely unrelated to these patches). rob From nalin at redhat.com Mon Jun 30 19:16:53 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 30 Jun 2014 15:16:53 -0400 Subject: [Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate In-Reply-To: <53ADEDED.7090603@redhat.com> References: <539EF2A1.6060706@redhat.com> <53AC24CB.607@redhat.com> <53AC60F9.9030900@redhat.com> <53AD5102.1000302@redhat.com> <53ADEDED.7090603@redhat.com> Message-ID: <20140630191653.GC8119@redhat.com> On Fri, Jun 27, 2014 at 06:19:25PM -0400, Rob Crittenden wrote: > How it is monitoring with a ca-error I don't know. If there's a previously-issued certificate present, the state machine goes back to "monitoring" rather than the dead-end "rejected" state, so that it'll try again later when certificate crosses the next enroll_ttl threshold. It's mainly a guess at the right thing to do in that situation (in case the CA rejected the request for a transient reason that gets remedied at the server at some point), so I'm not firmly wedded to it, and remain open to changing it. Now that I'm writing this, I'm thinking rejected requests should probably be re-attempted, eventually, though it risks annoying the CA. Cheers, Nalin From pviktori at redhat.com Mon Jun 30 20:38:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 30 Jun 2014 22:38:01 +0200 Subject: [Freeipa-devel] [PATCH] 0612 permission plugin: Ignore unparseable ACIs Message-ID: <53B1CAA9.1020608@redhat.com> Hello, The new ipaAllowedOperation ACIs cannot be parsed by the ACI parser. This made operations on ACIs on the same entry fail (because the plugin needs to go through all ACIs on the entry, parsing out the name, until it finds one with the correct name). This fixes the issue, and adds a test that fails without the patch. Workaround for: https://fedorahosted.org/freeipa/ticket/4376 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0612-permission-plugin-Ignore-unparseable-ACIs.patch Type: text/x-patch Size: 3809 bytes Desc: not available URL: From rcritten at redhat.com Mon Jun 30 22:36:16 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jun 2014 18:36:16 -0400 Subject: [Freeipa-devel] [PATCH] 1108 Remove smartproxy Message-ID: <53B1E660.9040702@redhat.com> The Foreman Smart Proxy server has its own upstream now at https://fedorahosted.org/freeipa-foreman-smartproxy/ so this source is no longer needed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1108-remove-smartproxy.patch Type: text/x-patch Size: 48273 bytes Desc: not available URL: