date:20160901

Re: [Freeipa-devel] [PATCH] 0014

2016-09-01 Thread Fraser Tweedale

On Thu, Sep 01, 2016 at 07:37:53PM +0200, Tomas Krizek wrote:
> On 09/01/2016 03:58 PM, Florence Blanc-Renaud wrote:
> > Hi,
> > 
> > please find attached a patch for ipa-certupdate in CA-less deployment.
> > https://fedorahosted.org/freeipa/ticket/6288
> > 
> > Flo.
> > 
> > 
> > 
> The patch is malformed, but you can simply delete the very first character
> to fix it.
> 
> Other than that, patch works as expected -> ACK.
> 
The patch malformation is caused by Thunderbird.  See [1] for how to
configure Thunderbird (and Mutt) to not add the '>'.

[1] 
http://www.freeipa.org/page/Contribute/Patch_Format#Ensuring_correct_transmission_of_patches

Thanks,
Fraser

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

Re: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

2016-09-01 Thread Ben Lipton

On 07/27/2016 02:42 PM, Ben Lipton wrote:

On 07/21/2016 11:43 AM, Petr Spacek wrote:

Besides this nit,
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation
sounds reasonable. I like how it prevents bad data from template-injection.

That's what I like about it, too. It does turn out to make things a
little tricky when it comes to writing rules that won't render if the
data they depend on is unavailable. (Because instead of rendering
individual rules which we can drop if they're missing data, we build
one big template that has to handle missing data correctly on its
own.) I think it's probably still worth it, though. I added this to
the "Alternatives considered" section of the above document.

By the way, I just wrote a followup blog post on this subject:
describing the challenges I've had with suppressing rules when the data
isn't available, and wondering if it's worth it. The post is here:
http://blog.benjaminlipton.com/2016/09/01/rule-suppression.html. It
might be a bit of a dense read, but I wanted to have the considerations
documented at least. As always, please let me know if there's anything I
can clarify. And if you do happen to read it and it makes you prefer one
solution over the others, I'd love to hear your opinion.

Ben

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

Re: [Freeipa-devel] [PATCH] 0014

2016-09-01 Thread Tomas Krizek


On 09/01/2016 03:58 PM, Florence Blanc-Renaud wrote:

Hi,

please find attached a patch for ipa-certupdate in CA-less deployment.
https://fedorahosted.org/freeipa/ticket/6288

Flo.



The patch is malformed, but you can simply delete the very first 
character to fix it.


Other than that, patch works as expected -> ACK.

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

[Freeipa-devel] Announcing FreeIPA 4.4.1

2016-09-01 Thread Martin Basti


The FreeIPA team would like to announce FreeIPA v4.4.1 release!

It can be downloaded from http://www.freeipa.org/page/Downloads.

Builds for Fedora 24 will be available in the official COPR repository 
.


== Highlights in 4.4.1 ==
=== Enhancements ===
* Kerberos KDC now takes Authentication Indicators into account when 
issuing service tickets. This allows, for example, to require two-factor 
authenticated Kerberos credentials prior to obtaining tickets to a VPN 
service.
* FreeIPA Certificate Authority now is able to create subordinate CAs to 
issue certificates with a specific scope
* Web UI and API end-points now can be configured to log-in with client 
certificates and smart cards. Additional configuration details are 
described in the External Authentication design page 
.

* Web UI now suggests to have redundancy in Certificate Authority topology
* Custom FreeIPA plugins can now be built without modifying core FreeIPA 
code
* When establishing trust to an Active Directory forest, FreeIPA now is 
capable on automatically resolving DNS namespace conflicts with another 
Active Directory forest.


=== Known Issues ===
* Interactive CLI input for dnsrecord-* commands does not work properly 
for multipart records 
* ipa-ca-install fails on replica when master is CA-less 

* Lightweight sub-CA certs are not tracked by certmonger after 
`ipa-replica-install` 
* Certificate revocation in service-del and host-del isn't aware of Sub 
CAs and causes command to fail when Sub CA cert is used 



=== Bug fixes ===
FreeIPA 4.4.1 is a stabilization release for the features delivered as a 
part of 4.4.0. There are more than 140 bug-fixes which details can be 
seen in the list of resolved tickets below.


== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or 
#freeipa channel on Freenode.


== Detailed changelog since 4.4.0 ==
=== Abhijeet Kasurde (4) ===
* Minor fix in ipa-replica-manage MAN page
* Corrected minor spell check in AD Trust information doc messages
* Removed unwanted line break from RefererError Dialog message
* Handled empty hostname in server-del command

=== Alexander Bokovoy (9) ===
* service: add flag to allow S4U2Self
* support schema files from third-party plugins
* ipaserver/dcerpc: reformat to make the code closer to pep8
* trust: automatically resolve DNS trust conflicts for triangle trusts
* trust: make sure external trust topology is correctly rendered
* trust: make sure ID range is created for the child domain even if it 
exists

* ipa-kdb: simplify trusted domain parent search
* support multiple uid values in schema compatibility tree
* freeipa.spec.in: move ipa CLI utility to freeipa-client

=== Ben Lipton (3) ===
* Fix several small typos
* Use existing HostKey config to test sshd
* Silence sshd messages during install

=== Christian Heimes (5) ===
* Correct path to HTTPD's systemd service directory
* RedHatCAService should wait for local Dogtag instance
* Remove Custodia server keys from LDAP
* Secure permissions of Custodia server.keys
* Require httpd 2.4.6-31 with mod_proxy Unix socket support

=== David Kupka (21) ===
* schema: Fix subtopic -> topic mapping
* help: Add dnsserver commands to help topic 'dns'
* vault: Catch correct exception in decrypt
* schema: Speed up schema cache
* frontend: Change doc, summary, topic and NO_CLI to class properties
* schema: Introduce schema cache format
* schema: Generate bits for help load them on request
* help: Do not create instances to get information about commands and topics
* compat: Save server's API version in for pre-schema servers
* schema cache: Do not reset ServerInfo dirty flag
* schema cache: Do not read fingerprint and format from cache
* Access data for help separately
* frontent: Add summary class property to CommandOverride
* schema cache: Read server info only once
* schema cache: Store API schema cache in memory
* client: Do not create instance just to check isinstance
* schema cache: Read schema instead of rewriting it when SchemaUpToDate
* schema check: Check current client language against cached one
* compat: Fix ping command call
* schema cache: Fallback to 'en_us' when locale is not available
* otptoken, permission: Convert custom type parameters on server

=== Florence Blanc-Renaud (4) ===
* Show full error message for selinuxusermap-add-hostgroup
* server uninstall fails to remove krb principals
* Fix session cookies
* Fix ipa hbactest output

=== Fraser Tweedale (11) ===
* uninstall: untrack lightweight CA certs
* caacl: expand plugin

[Freeipa-devel] [freeipa PR#46] Always fetch forest info from root DCs when establishing two-way trust (synchronize)

2016-09-01 Thread martbab

martbab's pull request #46: "Always fetch forest info from root DCs when 
establishing two-way trust" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/46
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/46/head:pr46
git checkout pr46
From 5a70f5dc53067f7a21a4fc60f95d7b11b2220611 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 1 Sep 2016 09:30:23 +0200
Subject: [PATCH 1/3] Always fetch forest info from root DCs when establishing
 two-way trust

Prior To Windows Server 2012R2, the `netr_DsRGetForestTrustInformation` calls
performed against non-root forest domain DCs were automatically routed to the
root domain DCs to resolve trust topology information.

This is no longer the case, so the `dcerpc.fetch_domains` function must
explicitly contact root domain DCs even in the case when an external two-way
trust to non-root domain is requested.

https://fedorahosted.org/freeipa/ticket/6057
---
 ipaserver/plugins/trust.py | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index 65dc1f4..8f8f987 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -770,7 +770,7 @@ def execute(self, *keys, **options):
 # Bidirectional trust allows us to use cross-realm TGT, so we can
 # run the call under original user's credentials
 res = fetch_domains_from_trust(self.api, self.trustinstance,
-   result['result'], **options)
+   **options)
 domains = add_new_domains_from_trust(self.api, self.trustinstance,
  result['result'], res, **options)
 else:
@@ -1631,8 +1631,21 @@ def execute(self, *keys, **options):
 return result
 
 
-def fetch_domains_from_trust(myapi, trustinstance, trust_entry, **options):
-trust_name = trust_entry['cn'][0]
+def fetch_domains_from_trust(myapi, trustinstance, **options):
+"""
+Contact trust forest root DC and fetch trusted forest topology information.
+
+:param myapi: API instance
+:param trustinstance: Initialized instance of `dcerpc.TrustDomainJoins`
+class
+:param options: options passed from API command's `execute()` method
+
+:returns: dict containing forest domain information and forest-wide UPN
+suffixes (if any)
+"""
+
+forest_root_name = trustinstance.remote_domain.info['dns_forest']
+
 # We want to use Kerberos if we have admin credentials even with SMB calls
 # as eventually use of NTLMSSP will be deprecated for trusted domain operations
 # If admin credentials are missing, 'creds' will be None and fetch_domains
@@ -1640,10 +1653,10 @@ def fetch_domains_from_trust(myapi, trustinstance, trust_entry, **options):
 # as well.
 creds = generate_creds(trustinstance, style=CRED_STYLE_KERBEROS, **options)
 server = options.get('realm_server', None)
-domains = ipaserver.dcerpc.fetch_domains(myapi,
- trustinstance.local_flatname,
- trust_name, creds=creds,
- server=server)
+domains = ipaserver.dcerpc.fetch_domains(
+myapi, trustinstance.local_flatname, forest_root_name, creds=creds,
+server=server)
+
 return domains
 
 
@@ -1749,7 +1762,7 @@ def execute(self, *keys, **options):
 'on the IPA server first'
 )
 )
-res = fetch_domains_from_trust(self.api, trustinstance, trust, **options)
+res = fetch_domains_from_trust(self.api, trustinstance, **options)
 domains = add_new_domains_from_trust(self.api, trustinstance, trust, res, **options)
 
 if len(domains) > 0:

From 11e3bca0af0ff8969b2eddb9e0b19fcf6a4a9fd0 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 1 Sep 2016 18:09:05 +0200
Subject: [PATCH 2/3] factor out `populate_remote_domain` method into
 module-level function

This allows for re-use of this method in cases where the caller can not or
wishes not to instantiate local Samba domain to retrieve information about
remote ones.

https://fedorahosted.org/freeipa/ticket/6057
---
 ipaserver/dcerpc.py | 94 ++---
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 4d98485..71b8ba6 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -1534,6 +1534,52 @@ def communicate(td):
 return result
 
 
+def retrieve_remote_domain(hostname, local_flatname,
+   realm, realm_server=None,
+   realm_admin=None, realm_passwd=None):
+

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Simo Sorce

On Thu, 2016-09-01 at 17:48 +0200, Standa Laznicka wrote:
> If an admin wants the capabilities of time rules then they should just
> upgrade the clients. If that is a problem, it's their choice. They can
> either create a special host group for those clients that just won't 
> upgrade or just revoke access to them if it's a problem of a stubborn 
> user who does not want their system upgraded.

This is a very naive view of the problem. first of all what admins want
and what admins can have *and when* are 2 completely different things.

Admins may *prefer* to enforce time rules but it may not be a deal
breaker if some clients do not follow them. They may be ok to have a
period of time i which this is not a hard rule.

Say they are in the process of migrating 3000 clients from RHEL5.11 to
RHEL7.4, they know the roll out will take 6 months, they want a time
rule established so that in 6 months all clients will allow access only
from 8AM CET to 6PM CET, but they are ok to allow access at all times
until a client is migrated.

Of course they may simply wait and change rules after all clients are
migrated, but maybe their goal in setting rules immediately is that they
can test them to see if their users are negatively impacted immediately
so they deal with issues as they come slowly as one client after the
other is migrated instead of having it all at once on "judgment" day. 

This is just an example scenario but I find it totally reasonable.
Are there other ways to go about it ? Yes, definitely, as mentioned host
groups can be used to control which clients see what. I am just saying
this is not a black and white problem, there are various shades of gray.

> Having a single object would also be wrong - there's no way telling
> the older clients to ignore the objects you want them to ignore if you
> want them not to ignore some.

Yes there is, hostgroups again, you see, it works both ways :-)

> But all and all thank you for the explanation with the example, it
> made some of your previous points more clear.

Sure.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Standa Laznicka


On 09/01/2016 05:18 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote:

On 09/01/2016 03:06 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:

The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
upon
addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.


A child's question: why not?

Also, should it come to life like you propose, what would you expect the
user interface to be like?

LDAPv3 does not allow changing structural classes, 389ds allows it but
it is a non-standard feature.
I do not want to create issues to people that create solutions that do
things like synchronizing our LDAP tree to another LDAP server, for
caching, proxying or anything else.
It is one thing to allow to do something illegal in the LDAP protocol,
it is *entirely* different to rely on an illegal feature in day to day
operations.

Furthermore when you change a rule this way old clients will suddenly
see a rule disappear as it will not match their queries anymore. If you
silently do this change in the framework an admin may not realize this
is the case and break access to his legacy clients. If the admin has to
delete and recreate a rule instead it will be much clear to the admin
that this is the case.

So the above is for why I am pretty against switching objectclass.
Please do not do that, it is a NACK from me.
Thank you for the explanation, I was actually really curious about this 
as I still don't have that much experience and I just don't get some 
implications.

But below find additional things I have been thinking:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
After all the old rule grants access at "all times".

Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.
If an admin wants the capabilities of time rules then they should just 
upgrade the clients. If that is a problem, it's their choice. They can 
either create a special host group for those clients that just won't 
upgrade or just revoke access to them if it's a problem of a stubborn 
user who does not want their system upgraded.


Having a single object would also be wrong - there's no way telling the 
older clients to ignore the objects you want them to ignore if you want 
them not to ignore some.


But all and all thank you for the explanation with the example, it made 
some of your previous points more clear.


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

[Freeipa-devel] [freeipa PR#49] Don't show error messages in bash completion (opened)

2016-09-01 Thread tomaskrizek

tomaskrizek's pull request #49: "Don't show error messages in bash completion" 
was opened

PR body:
"""
Redirect bash error output to prevent displaying error
messages in bash completion for ipa command.

https://fedorahosted.org/freeipa/ticket/6273
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/49
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/49/head:pr49
git checkout pr49
From dce23245ebbeaa55b2ca87f8a94c4dd8e99d7d1b Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Thu, 1 Sep 2016 17:19:19 +0200
Subject: [PATCH] Don't show error messages in bash completion

Redirect bash error output to prevent displaying error
messages in bash completion for ipa command.

https://fedorahosted.org/freeipa/ticket/6273
---
 contrib/completion/ipa.bash_completion | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/completion/ipa.bash_completion b/contrib/completion/ipa.bash_completion
index 36b82bd..33ad170 100644
--- a/contrib/completion/ipa.bash_completion
+++ b/contrib/completion/ipa.bash_completion
@@ -11,7 +11,7 @@
 
 _ipa_commands()
 {
-ipa help commands | sed -r 's/^([-[:alnum:]]*).*/\1/' | grep '^[[:alnum:]]'
+ipa help commands 2>/dev/null | sed -r 's/^([-[:alnum:]]*).*/\1/' | grep '^[[:alnum:]]'
 }
 
 _ipa()
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Simo Sorce

On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote:
> On 09/01/2016 03:06 PM, Simo Sorce wrote:
> > On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:
> >> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
> >> upon
> >> addition of a time rule to a certain HBAC rule.
> > Honestly I am against this.
> >
> > If you really want the two objects to be incompatible then you tell the
> > admin he can't add time rules to old objects.
> > The new object type should clearly identified as a new rule type and the
> > admin will have to create a new rule of the correct type and
> > remove/disable or retain the old rule as he prefers.
> >
> > I do not think we should ever try to switch objectclasses dynamically.
> >
> > Simo.
> >
> A child's question: why not?
> 
> Also, should it come to life like you propose, what would you expect the 
> user interface to be like?

LDAPv3 does not allow changing structural classes, 389ds allows it but
it is a non-standard feature.
I do not want to create issues to people that create solutions that do
things like synchronizing our LDAP tree to another LDAP server, for
caching, proxying or anything else.
It is one thing to allow to do something illegal in the LDAP protocol,
it is *entirely* different to rely on an illegal feature in day to day
operations.

Furthermore when you change a rule this way old clients will suddenly
see a rule disappear as it will not match their queries anymore. If you
silently do this change in the framework an admin may not realize this
is the case and break access to his legacy clients. If the admin has to
delete and recreate a rule instead it will be much clear to the admin
that this is the case.

So the above is for why I am pretty against switching objectclass.
Please do not do that, it is a NACK from me.

But below find additional things I have been thinking:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
After all the old rule grants access at "all times".

Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Standa Laznicka


On 09/01/2016 03:06 PM, Simo Sorce wrote:

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:

The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
upon
addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.


A child's question: why not?

Also, should it come to life like you propose, what would you expect the 
user interface to be like?


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

[Freeipa-devel] [bind-dyndb-ldap PR#1] [WIP] Port bind-dyndb-ldap to BIND 9.11 (synchronize)

2016-09-01 Thread pspacek

pspacek's pull request #1: "[WIP] Port bind-dyndb-ldap to BIND 9.11" was 
synchronize

See the full pull-request at https://github.com/freeipa/bind-dyndb-ldap/pull/1
... or pull the PR as Git branch:
git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap
git fetch ghbind-dyndb-ldap pull/1/head:pr1
git checkout pr1
From 74b1f81c8bd4ebae62691dc321f7a0ab55daadc5 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 15 Aug 2016 18:01:06 +0200
Subject: [PATCH 1/9] BIND 9.11: Remove #if blocks for older BIND versions.

---
 src/Makefile.am   |   1 -
 src/compat.h  |  44 ---
 src/fwd.c |  60 ++-
 src/ldap_driver.c | 103 +++---
 4 files changed, 6 insertions(+), 202 deletions(-)
 delete mode 100644 src/compat.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 238d8ef..c5de9ce 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -4,7 +4,6 @@ bindplugindir=$(libdir)/bind
 HDRS =\
 	acl.h			\
 	bindcfg.h		\
-	compat.h		\
 	empty_zones.h		\
 	fs.h			\
 	fwd.h			\
diff --git a/src/compat.h b/src/compat.h
deleted file mode 100644
index 00e3da5..000
--- a/src/compat.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright (C) 2009  bind-dyndb-ldap authors; see COPYING for license
- */
-
-#ifdef HAVE_CONFIG_H
-#include 
-#else
-#error "Can't compile without config.h"
-#endif
-
-/*
- * dns_rdatalist_fromrdataset() did not exist in older versions of libdns.
- * Add a substitude function here.
- */
-#if LIBDNS_VERSION_MAJOR < 40
-static inline isc_result_t
-dns_rdatalist_fromrdataset(dns_rdataset_t *rdataset,
-			   dns_rdatalist_t **rdatalist)
-{
-	REQUIRE(rdatalist != NULL && rdataset != NULL);
-
-	*rdatalist = rdataset->private1;
-
-	return ISC_R_SUCCESS;
-}
-#endif /* LIBDNS_VERSION_MAJOR < 40 */
-
-/*
- * In older libdns versions, isc_refcount_init() was defined as a macro.
- * However, in newer versions, it is a function returning isc_result_t type.
- * This piece of code should take care of that problem.
- */
-#if LIBDNS_VERSION_MAJOR < 30
-#include 
-
-static inline isc_result_t
-isc_refcount_init_func(isc_refcount_t *ref, unsigned int n)
-{
-	isc_refcount_init(ref, n);
-	return ISC_R_SUCCESS;
-}
-#undef isc_refcount_init
-#define isc_refcount_init isc_refcount_init_func
-#endif /* LIBDNS_VERSION_MAJOR < 30 */
diff --git a/src/fwd.c b/src/fwd.c
index 1f6a9e5..840f0e8 100644
--- a/src/fwd.c
+++ b/src/fwd.c
@@ -69,11 +69,7 @@ fwd_list_len(dns_forwarders_t *fwdrs) {
 
 	REQUIRE(fwdrs != NULL);
 
-#if LIBDNS_VERSION_MAJOR < 140
-	for (isc_sockaddr_t *fwdr = ISC_LIST_HEAD(fwdrs->addrs);
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	for (dns_forwarder_t *fwdr = ISC_LIST_HEAD(fwdrs->fwdrs);
-#endif
 	 fwdr != NULL;
 	 fwdr = ISC_LIST_NEXT(fwdr, link)) {
 		len++;
@@ -169,11 +165,7 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 	const cfg_obj_t *faddresses;
 	const cfg_listelt_t *fwdr_cfg; /* config representation */
 	/* internal representation */
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddr_t *fwdr_int;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	dns_forwarder_t *fwdr_int;
-#endif
 
 	isc_buffer_initnull(_buf);
 	tmp_buf.mctx = mctx;
@@ -197,20 +189,12 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 	 * data from the internal one to cfg data structures.*/
 	faddresses = cfg_tuple_get(forwarders_cfg, "addresses");
 	for (fwdr_int = ISC_LIST_HEAD(
-#if LIBDNS_VERSION_MAJOR < 140
-			fwdrs->addrs
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 			fwdrs->fwdrs
-#endif
 			), fwdr_cfg = cfg_list_first(faddresses);
 	 INSIST((fwdr_int == NULL) == (fwdr_cfg == NULL)), fwdr_int != NULL;
 	 fwdr_int = ISC_LIST_NEXT(fwdr_int, link), fwdr_cfg = cfg_list_next(fwdr_cfg)) {
-#if LIBDNS_VERSION_MAJOR < 140
-		fwdr_cfg->obj->value.sockaddr = *fwdr_int;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 		fwdr_cfg->obj->value.sockaddrdscp.sockaddr = fwdr_int->addr;
 		fwdr_cfg->obj->value.sockaddrdscp.dscp = fwdr_int->dscp;
-#endif
 	}
 	cfg_print(faddresses, buffer_append_str, _buf);
 
@@ -259,12 +243,7 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 
 static isc_result_t
 fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddrlist_t *fwdrs
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
-	dns_forwarderlist_t *fwdrs
-#endif
-	)
+	  dns_forwarderlist_t *fwdrs)
 {
 	isc_result_t result = ISC_R_SUCCESS;
 	cfg_parser_t *parser = NULL;
@@ -274,11 +253,7 @@ fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
 	const cfg_listelt_t *listel;
 	const cfg_obj_t *fwdr_cfg;
 	isc_sockaddr_t addr;
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddr_t *fwdr;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	dns_forwarder_t *fwdr;
-#endif
 
 	in_port_t port = 53;
 
@@ -301,12 +276,8 @@ fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
 		if (isc_sockaddr_getport() == 0)
 			isc_sockaddr_setport(, port);

[Freeipa-devel] [PATCH] Bump master IPA devel version to 4.4.90

2016-09-01 Thread Martin Basti


Pushed under oneliner rule

Pushed to master: 371254fc4b36cb4d89351edb19c88a85e5a33a1b


From 17553b8e5d4a58fda8e9f8ad6427366e17aedb29 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 1 Sep 2016 16:20:41 +0200
Subject: [PATCH] Bump master IPA devel version to 4.4.90

---
 VERSION | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/VERSION b/VERSION
index bcc455663855bd03318fbe0ddfbcfee81c67dea8..bf8160a5deb1f7a5148ef6833cec318af144b5d7 100644
--- a/VERSION
+++ b/VERSION
@@ -21,7 +21,7 @@
 
 IPA_VERSION_MAJOR=4
 IPA_VERSION_MINOR=4
-IPA_VERSION_RELEASE=1
+IPA_VERSION_RELEASE=90
 
 
 # For 'alpha' releases the version will be #
-- 
2.7.4

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

[Freeipa-devel] [PATCH] 0014

2016-09-01 Thread Florence Blanc-Renaud


Hi,

please find attached a patch for ipa-certupdate in CA-less deployment.
https://fedorahosted.org/freeipa/ticket/6288

Flo.

>From c09f7b9282f82aba28d241be86e773e3b748cd09 Mon Sep 17 00:00:00 2001
From: Florence Blanc-Renaud 
Date: Thu, 1 Sep 2016 15:53:38 +0200
Subject: [PATCH] Fix ipa-certupdate for CA-less installation

In a CA-less installation, ipa-certupdate fails with the error message:
  $ ipa-certupdate
  trying https://vm-180.abc.idm.lab.eng.brq.redhat.com/ipa/session/json
  Forwarding 'ca_is_enabled' to json server 'https://vm-180.abc.idm.lab.eng.brq.redhat.com/ipa/session/json'
  Forwarding 'ca_find/1' to json server 'https://vm-180.abc.idm.lab.eng.brq.redhat.com/ipa/session/json'
  CA is not configured
  The ipa-certupdate command failed.

The issue happens because ipa-certupdate tries to call ca_find even on a
CA_less deployment. The fix skips the call to ca_find in this case.

https://fedorahosted.org/freeipa/ticket/6288
---
 ipaclient/ipa_certupdate.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/ipaclient/ipa_certupdate.py b/ipaclient/ipa_certupdate.py
index e59047a2705eb8ccb98b5213c4c8771f55a29bc5..4c3c63fe96414d65592b152bb93cc7a588530a7f 100644
--- a/ipaclient/ipa_certupdate.py
+++ b/ipaclient/ipa_certupdate.py
@@ -87,9 +87,10 @@ class CertUpdate(admintool.AdminTool):
 
 # find lightweight CAs (on renewal master only)
 lwcas = []
-for ca_obj in api.Command.ca_find()['result']:
-if IPA_CA_CN not in ca_obj['cn']:
-lwcas.append(ca_obj)
+if (ca_enabled):
+for ca_obj in api.Command.ca_find()['result']:
+if IPA_CA_CN not in ca_obj['cn']:
+lwcas.append(ca_obj)
 
 api.Backend.rpcclient.disconnect()
 finally:
-- 
2.7.4

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

[Freeipa-devel] [bind-dyndb-ldap PR#1] [WIP] Port bind-dyndb-ldap to BIND 9.11 (synchronize)

2016-09-01 Thread pspacek

pspacek's pull request #1: "[WIP] Port bind-dyndb-ldap to BIND 9.11" was 
synchronize

See the full pull-request at https://github.com/freeipa/bind-dyndb-ldap/pull/1
... or pull the PR as Git branch:
git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap
git fetch ghbind-dyndb-ldap pull/1/head:pr1
git checkout pr1
From 74b1f81c8bd4ebae62691dc321f7a0ab55daadc5 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 15 Aug 2016 18:01:06 +0200
Subject: [PATCH 1/8] BIND 9.11: Remove #if blocks for older BIND versions.

---
 src/Makefile.am   |   1 -
 src/compat.h  |  44 ---
 src/fwd.c |  60 ++-
 src/ldap_driver.c | 103 +++---
 4 files changed, 6 insertions(+), 202 deletions(-)
 delete mode 100644 src/compat.h

diff --git a/src/Makefile.am b/src/Makefile.am
index 238d8ef..c5de9ce 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -4,7 +4,6 @@ bindplugindir=$(libdir)/bind
 HDRS =\
 	acl.h			\
 	bindcfg.h		\
-	compat.h		\
 	empty_zones.h		\
 	fs.h			\
 	fwd.h			\
diff --git a/src/compat.h b/src/compat.h
deleted file mode 100644
index 00e3da5..000
--- a/src/compat.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright (C) 2009  bind-dyndb-ldap authors; see COPYING for license
- */
-
-#ifdef HAVE_CONFIG_H
-#include 
-#else
-#error "Can't compile without config.h"
-#endif
-
-/*
- * dns_rdatalist_fromrdataset() did not exist in older versions of libdns.
- * Add a substitude function here.
- */
-#if LIBDNS_VERSION_MAJOR < 40
-static inline isc_result_t
-dns_rdatalist_fromrdataset(dns_rdataset_t *rdataset,
-			   dns_rdatalist_t **rdatalist)
-{
-	REQUIRE(rdatalist != NULL && rdataset != NULL);
-
-	*rdatalist = rdataset->private1;
-
-	return ISC_R_SUCCESS;
-}
-#endif /* LIBDNS_VERSION_MAJOR < 40 */
-
-/*
- * In older libdns versions, isc_refcount_init() was defined as a macro.
- * However, in newer versions, it is a function returning isc_result_t type.
- * This piece of code should take care of that problem.
- */
-#if LIBDNS_VERSION_MAJOR < 30
-#include 
-
-static inline isc_result_t
-isc_refcount_init_func(isc_refcount_t *ref, unsigned int n)
-{
-	isc_refcount_init(ref, n);
-	return ISC_R_SUCCESS;
-}
-#undef isc_refcount_init
-#define isc_refcount_init isc_refcount_init_func
-#endif /* LIBDNS_VERSION_MAJOR < 30 */
diff --git a/src/fwd.c b/src/fwd.c
index 1f6a9e5..840f0e8 100644
--- a/src/fwd.c
+++ b/src/fwd.c
@@ -69,11 +69,7 @@ fwd_list_len(dns_forwarders_t *fwdrs) {
 
 	REQUIRE(fwdrs != NULL);
 
-#if LIBDNS_VERSION_MAJOR < 140
-	for (isc_sockaddr_t *fwdr = ISC_LIST_HEAD(fwdrs->addrs);
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	for (dns_forwarder_t *fwdr = ISC_LIST_HEAD(fwdrs->fwdrs);
-#endif
 	 fwdr != NULL;
 	 fwdr = ISC_LIST_NEXT(fwdr, link)) {
 		len++;
@@ -169,11 +165,7 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 	const cfg_obj_t *faddresses;
 	const cfg_listelt_t *fwdr_cfg; /* config representation */
 	/* internal representation */
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddr_t *fwdr_int;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	dns_forwarder_t *fwdr_int;
-#endif
 
 	isc_buffer_initnull(_buf);
 	tmp_buf.mctx = mctx;
@@ -197,20 +189,12 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 	 * data from the internal one to cfg data structures.*/
 	faddresses = cfg_tuple_get(forwarders_cfg, "addresses");
 	for (fwdr_int = ISC_LIST_HEAD(
-#if LIBDNS_VERSION_MAJOR < 140
-			fwdrs->addrs
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 			fwdrs->fwdrs
-#endif
 			), fwdr_cfg = cfg_list_first(faddresses);
 	 INSIST((fwdr_int == NULL) == (fwdr_cfg == NULL)), fwdr_int != NULL;
 	 fwdr_int = ISC_LIST_NEXT(fwdr_int, link), fwdr_cfg = cfg_list_next(fwdr_cfg)) {
-#if LIBDNS_VERSION_MAJOR < 140
-		fwdr_cfg->obj->value.sockaddr = *fwdr_int;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 		fwdr_cfg->obj->value.sockaddrdscp.sockaddr = fwdr_int->addr;
 		fwdr_cfg->obj->value.sockaddrdscp.dscp = fwdr_int->dscp;
-#endif
 	}
 	cfg_print(faddresses, buffer_append_str, _buf);
 
@@ -259,12 +243,7 @@ fwd_print_list_buff(isc_mem_t *mctx, dns_forwarders_t *fwdrs,
 
 static isc_result_t
 fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddrlist_t *fwdrs
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
-	dns_forwarderlist_t *fwdrs
-#endif
-	)
+	  dns_forwarderlist_t *fwdrs)
 {
 	isc_result_t result = ISC_R_SUCCESS;
 	cfg_parser_t *parser = NULL;
@@ -274,11 +253,7 @@ fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
 	const cfg_listelt_t *listel;
 	const cfg_obj_t *fwdr_cfg;
 	isc_sockaddr_t addr;
-#if LIBDNS_VERSION_MAJOR < 140
-	isc_sockaddr_t *fwdr;
-#else /* LIBDNS_VERSION_MAJOR >= 140 */
 	dns_forwarder_t *fwdr;
-#endif
 
 	in_port_t port = 53;
 
@@ -301,12 +276,8 @@ fwd_parse_str(const char *fwdrs_str, isc_mem_t *mctx,
 		if (isc_sockaddr_getport() == 0)
 			isc_sockaddr_setport(, port);

[Freeipa-devel] [freeipa PR#48] [4.4] Set zanata project-version fo 4.4 branch (opened)

2016-09-01 Thread mbasti-rh

mbasti-rh's pull request #48: "[4.4] Set zanata project-version fo 4.4 branch" 
was opened

PR body:
"""

"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/48
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/48/head:pr48
git checkout pr48
From 02f239a13b7b65331bff12bd9884cf41495cbe42 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 1 Sep 2016 15:47:08 +0200
Subject: [PATCH] Set zanata project-version fo 4.4 branch

---
 zanata.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zanata.xml b/zanata.xml
index d39a593..9b7aa5e 100644
--- a/zanata.xml
+++ b/zanata.xml
@@ -2,7 +2,7 @@
 http://zanata.org/namespace/config/;>
   https://fedora.zanata.org/
   freeipa
-  master
+  ipa-4-4
   gettext
   .
   .
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Standa Laznicka


On 09/01/2016 02:14 PM, Petr Spacek wrote:

On 1.9.2016 14:09, Standa Laznicka wrote:

On 09/01/2016 01:26 PM, Standa Laznicka wrote:

On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent
it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and
not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when
set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Simo Sorce

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:
> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
> upon 
> addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

[Freeipa-devel] [freeipa PR#47] schema cache: Store and check info for pre-schema servers (opened)

2016-09-01 Thread dkupka

dkupka's pull request #47: "schema cache: Store and check info for pre-schema 
servers" was opened

PR body:
"""
Cache CommandError answer to schema command to avoid sending the command
to pre-schema servers every time. This information expires after some
time (1 hour) in order to start using schema as soon as the server is
upgraded.

https://fedorahosted.org/freeipa/ticket/6095
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/47
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/47/head:pr47
git checkout pr47
From 815bb2a5bc837f88275e39b3854fc6ae408c2b44 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Mon, 22 Aug 2016 13:34:30 +0200
Subject: [PATCH] schema cache: Store and check info for pre-schema servers

Cache CommandError answer to schema command to avoid sending the command
to pre-schema servers every time. This information expires after some
time (1 hour) in order to start using schema as soon as the server is
upgraded.

https://fedorahosted.org/freeipa/ticket/6095
---
 ipaclient/remote_plugins/__init__.py |  77 +--
 ipaclient/remote_plugins/compat.py   |   9 ++-
 ipaclient/remote_plugins/schema.py   | 145 ++-
 3 files changed, 138 insertions(+), 93 deletions(-)

diff --git a/ipaclient/remote_plugins/__init__.py b/ipaclient/remote_plugins/__init__.py
index 2be9222..3d6ba8f 100644
--- a/ipaclient/remote_plugins/__init__.py
+++ b/ipaclient/remote_plugins/__init__.py
@@ -5,7 +5,9 @@
 import collections
 import errno
 import json
+import locale
 import os
+import time
 
 from . import compat
 from . import schema
@@ -23,8 +25,16 @@ class ServerInfo(collections.MutableMapping):
 def __init__(self, api):
 hostname = DNSName(api.env.server).ToASCII()
 self._path = os.path.join(self._DIR, hostname)
+self._force_check = api.env.force_schema_check
 self._dict = {}
-self._dirty = False
+
+# copy-paste from ipalib/rpc.py
+try:
+self._language = (
+ locale.setlocale(locale.LC_ALL, '').split('.')[0].lower()
+)
+except locale.Error:
+self._language = 'en_us'
 
 self._read()
 
@@ -32,11 +42,7 @@ def __enter__(self):
 return self
 
 def __exit__(self, *_exc_info):
-self.flush()
-
-def flush(self):
-if self._dirty:
-self._write()
+self._write()
 
 def _read(self):
 try:
@@ -62,13 +68,10 @@ def __getitem__(self, key):
 return self._dict[key]
 
 def __setitem__(self, key, value):
-if key not in self._dict or self._dict[key] != value:
-self._dirty = True
 self._dict[key] = value
 
 def __delitem__(self, key):
 del self._dict[key]
-self._dirty = True
 
 def __iter__(self):
 return iter(self._dict)
@@ -76,26 +79,54 @@ def __iter__(self):
 def __len__(self):
 return len(self._dict)
 
+def update_validity(self, ttl=None):
+if ttl is None:
+ttl = 3600
+self['expiration'] = time.time() + ttl
+self['language'] = self._language
+
+def is_valid(self):
+if self._force_check:
+return False
+
+try:
+expiration = self._dict['expiration']
+language = self._dict['language']
+self._dict['fingerprint']
+except KeyError:
+# if any of these is missing consider the entry expired
+return False
+
+if expiration < time.time():
+# validity passed
+return False
+
+if language != self._language:
+# language changed since last check
+return False
+
+return True
+
 
 def get_package(api):
 if api.env.in_tree:
 from ipaserver import plugins
 else:
-client = rpcclient(api)
-client.finalize()
-
 try:
-server_info = api._server_info
+plugins = api._remote_plugins
 except AttributeError:
-server_info = api._server_info = ServerInfo(api)
-
-try:
-plugins = schema.get_package(api, server_info, client)
-except schema.NotAvailable:
-plugins = compat.get_package(api, server_info, client)
-finally:
-server_info.flush()
-if client.isconnected():
-client.disconnect()
+with ServerInfo(api) as server_info:
+client = rpcclient(api)
+client.finalize()
+
+try:
+plugins = schema.get_package(server_info, client)
+except schema.NotAvailable:
+plugins = compat.get_package(server_info, client)
+finally:
+if client.isconnected():
+client.disconnect()
+
+object.__setattr__(api,

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Petr Spacek

On 1.9.2016 14:09, Standa Laznicka wrote:
> On 09/01/2016 01:26 PM, Standa Laznicka wrote:
>> On 08/31/2016 12:57 PM, Petr Spacek wrote:
>>> On 31.8.2016 12:42, Standa Laznicka wrote:
 On 08/30/2016 03:34 PM, Simo Sorce wrote:
> On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:
>> On 08/26/2016 05:37 PM, Simo Sorce wrote:
>>> On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:
 On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:
> On Fri, 26 Aug 2016, Simo Sorce wrote:
>> On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
 I miss "why" part of "To be able to handle backward compatibility
>>> with
 ease, a new object called ipaHBACRulev2 is introduced. " in the
>>> design
 page. If the reason is the above - old client's should ignore time
>>> rules
 then it has to be mentioned there. Otherwise I don't see a reason 
 to
 introduce a new object type instead of extending the current.
>>> How do you want to enforce HBAC rule that have set time from 10 to 
>>> 14
>>> everyday? With the same objectclass old clients will allow this HBAC
>>> for
>>> all day. Isn't this CVE?
>> This is a discussion worth having.
>>
>> In general it is a CVE only if an authorization mechanism fails to 
>> work
>> as advertised.
>>
>> If you make it clear that old clients *DO NOT* respect time rules 
>> then
>> there is no CVE material, it is working as "described".
>>
>> The admins already have a way to not set those rules for older 
>> clients
>> by simply grouping newer clients in a different host group and 
>> applying
>> time rules only there.
>>
>> So the question really is: should we allow admins to apply an HBAC 
>> Rule
>> potentially to older clients that do not understand it and will
>> therefore allow access at any time of the day, or should we prevent
>> it ?
>>
>> This is a hard question to answer and can go both ways.
>>
>> A time rule may be something that admins want to enforce at all cost 
>> or
>> deny access. In this case a client that fails to handle it would be a
>> problem.
>>
>> But it may be something that is just used for defense in depth and
>> not a
>> strictly hard requirement. In this case allowing older clients would
>> make it an easy transition as you just set up the rule and the client
>> will start enforcing the time when it is upgraded but work otherwise
>> with the same rules.
>>
>> I am a bit conflicted on trying to decide what scenario we should
>> target, but the second one appeals to me because host groups do 
>> already
>> give admins a good way to apply rules to a specific set of hosts and
>> exclude old clients w/o us making it a hard rule.
>> OTOH if an admin does not understand this difference, they may be
>> surprised to find out there are clients that do not honor it.
>>
>> Perhaps we could find a way to set a flag on the rule such that when
>> set
>> (and only when set) older clients get excluded by way of changing the
>> objectlass or something else to similar effect.
>>
>> Open to discussion.
> At this point using new object class becomes an attractive approach. 
> We
> don't have means to exclude HBAC rules other than applying them
> per-host/hostgroup. We also have no deny rules.
>
> I have another idea: what about enforcing time rules always to apply
> per-host or per-hostgroup by default? Add --force option to override 
> the
> behavior but default to not allow --hostcat=all. This would raise
> awareness and make sure admins are actually applying these rules with
> intention.
 This sounds like a good idea, but it is not a silver bullet I am 
 afraid.

 Simo.
>>> I was thinking that for future proofing we could add a version field,
>>> then reasoned more and realized that changing the object class is
>>> basically the same thing.
>>>
>>> There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
>>> (I know 389ds allows us to do an LDAPv3 illegal operation and change it,
>>> but I do not like to depend on that behavoir).
>>>
>>> Now looking into this I had an idea to solve the problem of legacy
>>> clients without having to swap classes.
>>> We can redefine the accessRuleType attribute to be a "capability" type.
>>>
>>> Ie rules that have a timeAccess component will be of type
>>> "allow_with_time" instead of

[Freeipa-devel] [freeipa PR#46] Always fetch forest info from root DCs when establishing two-way trust (comment)

2016-09-01 Thread abbra

abbra commented on a pull request

"""
The change is incomplete: we need also to handle oddjobd helper because it 
directly calls to dcerpc.fetch_domains() with explicitly set trusted domain 
name.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/46#issuecomment-244059726
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Standa Laznicka


On 09/01/2016 01:26 PM, Standa Laznicka wrote:

On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
I miss "why" part of "To be able to handle backward 
compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design
page. If the reason is the above - old client's should 
ignore time

rules
then it has to be mentioned there. Otherwise I don't see a 
reason to

introduce a new object type instead of extending the current.
How do you want to enforce HBAC rule that have set time from 
10 to 14
everyday? With the same objectclass old clients will allow 
this HBAC

for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism 
fails to work

as advertised.

If you make it clear that old clients *DO NOT* respect time 
rules then

there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older 
clients
by simply grouping newer clients in a different host group and 
applying

time rules only there.

So the question really is: should we allow admins to apply an 
HBAC Rule

potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we 
prevent it ?


This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at 
all cost or
deny access. In this case a client that fails to handle it 
would be a

problem.

But it may be something that is just used for defense in depth 
and not a
strictly hard requirement. In this case allowing older clients 
would
make it an easy transition as you just set up the rule and the 
client
will start enforcing the time when it is upgraded but work 
otherwise

with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups 
do already
give admins a good way to apply rules to a specific set of 
hosts and

exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such 
that when set
(and only when set) older clients get excluded by way of 
changing the

objectlass or something else to similar effect.

Open to discussion.
At this point using new object class becomes an attractive 
approach. We

don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to 
apply
per-host or per-hostgroup by default? Add --force option to 
override the

behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these 
rules with

intention.
This sounds like a good idea, but it is not a silver bullet I am 
afraid.


Simo.
I was thinking that for future proofing we could add a version 
field,

then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL 
objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and 
change it,

but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" 
type.


Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and 
I can

see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access 
rule

type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if 
we want

to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer 
client

but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer version of HBAC rules from the 
older

so

[Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (closed)

2016-09-01 Thread mbasti-rh

mirielka's pull request #42: "Tests: Avoid skipping tests due to missing files" 
was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/42
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/42/head:pr42
git checkout pr42
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (+pushed)

2016-09-01 Thread mbasti-rh

mirielka's pull request #42: "Tests: Avoid skipping tests due to missing files" 
label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/42
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#46] Always fetch forest info from root DCs when establishing two-way trust (opened)

2016-09-01 Thread martbab

martbab's pull request #46: "Always fetch forest info from root DCs when 
establishing two-way trust" was opened

PR body:
"""
Prior To Windows Server 2012R2, the `netr_DsRGetForestTrustInformation` calls
performed against non-root forest domain DCs were automatically routed to the
root domain DCs to resolve trust topology information.

This is no longer the case, so the `dcerpc.fetch_domains` function must
explicitly contact root domain DCs even in the case when an external two-way
trust to non-root domain is requested.

https://fedorahosted.org/freeipa/ticket/6057
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/46
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/46/head:pr46
git checkout pr46
From 5a70f5dc53067f7a21a4fc60f95d7b11b2220611 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 1 Sep 2016 09:30:23 +0200
Subject: [PATCH] Always fetch forest info from root DCs when establishing
 two-way trust

Prior To Windows Server 2012R2, the `netr_DsRGetForestTrustInformation` calls
performed against non-root forest domain DCs were automatically routed to the
root domain DCs to resolve trust topology information.

This is no longer the case, so the `dcerpc.fetch_domains` function must
explicitly contact root domain DCs even in the case when an external two-way
trust to non-root domain is requested.

https://fedorahosted.org/freeipa/ticket/6057
---
 ipaserver/plugins/trust.py | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index 65dc1f4..8f8f987 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -770,7 +770,7 @@ def execute(self, *keys, **options):
 # Bidirectional trust allows us to use cross-realm TGT, so we can
 # run the call under original user's credentials
 res = fetch_domains_from_trust(self.api, self.trustinstance,
-   result['result'], **options)
+   **options)
 domains = add_new_domains_from_trust(self.api, self.trustinstance,
  result['result'], res, **options)
 else:
@@ -1631,8 +1631,21 @@ def execute(self, *keys, **options):
 return result
 
 
-def fetch_domains_from_trust(myapi, trustinstance, trust_entry, **options):
-trust_name = trust_entry['cn'][0]
+def fetch_domains_from_trust(myapi, trustinstance, **options):
+"""
+Contact trust forest root DC and fetch trusted forest topology information.
+
+:param myapi: API instance
+:param trustinstance: Initialized instance of `dcerpc.TrustDomainJoins`
+class
+:param options: options passed from API command's `execute()` method
+
+:returns: dict containing forest domain information and forest-wide UPN
+suffixes (if any)
+"""
+
+forest_root_name = trustinstance.remote_domain.info['dns_forest']
+
 # We want to use Kerberos if we have admin credentials even with SMB calls
 # as eventually use of NTLMSSP will be deprecated for trusted domain operations
 # If admin credentials are missing, 'creds' will be None and fetch_domains
@@ -1640,10 +1653,10 @@ def fetch_domains_from_trust(myapi, trustinstance, trust_entry, **options):
 # as well.
 creds = generate_creds(trustinstance, style=CRED_STYLE_KERBEROS, **options)
 server = options.get('realm_server', None)
-domains = ipaserver.dcerpc.fetch_domains(myapi,
- trustinstance.local_flatname,
- trust_name, creds=creds,
- server=server)
+domains = ipaserver.dcerpc.fetch_domains(
+myapi, trustinstance.local_flatname, forest_root_name, creds=creds,
+server=server)
+
 return domains
 
 
@@ -1749,7 +1762,7 @@ def execute(self, *keys, **options):
 'on the IPA server first'
 )
 )
-res = fetch_domains_from_trust(self.api, trustinstance, trust, **options)
+res = fetch_domains_from_trust(self.api, trustinstance, **options)
 domains = add_new_domains_from_trust(self.api, trustinstance, trust, res, **options)
 
 if len(domains) > 0:
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#34] dns: prompt for missing record parts in CLI (comment)

2016-09-01 Thread mbasti-rh

mbasti-rh commented on a pull request

"""
Fix works for me partially, it fixes issues reported in ticket. Do you want to 
open new ticket for this or should it be part of this ticket?

Expected:
```
[root@vm-058-080 ~]# ipa dnsrecord-add test. rec
Please choose a type of DNS resource record to be added
The most common types for this type of zone are: A, 

DNS resource record type: srv
SRV Priority: 5
SRV Weight: 5
SRV Port: 5
SRV Target: host.example.com.
  Record name: rec
  SRV record: 5 5 5 host.example.com.
```

Got:
```
[root@vm-058-017 ~]# ipa dnsrecord-add test. rec
Please choose a type of DNS resource record to be added
The most common types for this type of zone are: A, 

DNS resource record type: srv
ipa: ERROR: No options to add a specific record provided.
Command help may be consulted for all supported record types.
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/34#issuecomment-244051256
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-09-01 Thread Standa Laznicka


On 08/31/2016 12:57 PM, Petr Spacek wrote:

On 31.8.2016 12:42, Standa Laznicka wrote:

On 08/30/2016 03:34 PM, Simo Sorce wrote:

On Tue, 2016-08-30 at 08:47 +0200, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses. Also, I believe that accessRuleType was originally
actually used to distinguish newer version of HBAC rules from the older
so we may just do this again and profit from its original purpose. To
top it off, this change should

[Freeipa-devel] [freeipa PR#44] rpcserver: fix crash in XML-RPC system commands (+pushed)

2016-09-01 Thread dkupka

jcholast's pull request #44: "rpcserver: fix crash in XML-RPC system commands" 
label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/44
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#44] rpcserver: fix crash in XML-RPC system commands (comment)

2016-09-01 Thread dkupka

dkupka commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/afcb3bd3c32aa33dcd68cd0a2ca85bda677000a8
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/44#issuecomment-244049974
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (comment)

2016-09-01 Thread stlaz

stlaz commented on a pull request

"""
I pushed the latest changes of the time rules to this pull request. These 
changes were made according to the discussion on freeipa-devel mailing list, 
the main change is cutting off some attributes from the ipaHBACRuleV2 
objectclass.
Please note that python-icalendar rebase request for Fedora-rawhide still needs 
to be created as I am waiting for the python-icalendar upstream to ACK my pull 
request https://github.com/collective/icalendar/pull/196.
Also, all the previous issues from this thread should now be fixed. A new 
privilege was created and added to the IT Security Specialist role.
API tests are still TODO.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/23#issuecomment-244049988
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#44] rpcserver: fix crash in XML-RPC system commands (closed)

2016-09-01 Thread dkupka

jcholast's pull request #44: "rpcserver: fix crash in XML-RPC system commands" 
was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/44
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/44/head:pr44
git checkout pr44
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#45] custodia: force reconnect before retrieving CA certs from LDAP (closed)

2016-09-01 Thread mbasti-rh

jcholast's pull request #45: "custodia: force reconnect before retrieving CA 
certs from LDAP" was closed

See the full pull-request at https://github.com/freeipa/freeipa/pull/45
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/45/head:pr45
git checkout pr45
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#45] custodia: force reconnect before retrieving CA certs from LDAP (comment)

2016-09-01 Thread mbasti-rh

mbasti-rh commented on a pull request

"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/17ea4ae6b9007e121ae1ea7748643394fec84ad7
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/45#issuecomment-244048121
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#45] custodia: force reconnect before retrieving CA certs from LDAP (+pushed)

2016-09-01 Thread mbasti-rh

jcholast's pull request #45: "custodia: force reconnect before retrieving CA 
certs from LDAP" label *pushed* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/45
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#23] Time-Based HBAC Policies (synchronize)

2016-09-01 Thread stlaz

stlaz's pull request #23: "Time-Based HBAC Policies" was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/23
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/23/head:pr23
git checkout pr23
From 5098b2f62790d65ce2abc084465cedc6de790b00 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Fri, 19 Feb 2016 08:35:31 +0100
Subject: [PATCH] Added Time Rules functionality to IPA

Time Rules are rules based on the iCalendar format. They are now
currently used for restriction of access in the HBAC Rules.
To learn more about the time rules, see their design at
http://www.freeipa.org/page/V4/Time-Based_Account_Policies.

https://fedorahosted.org/freeipa/ticket/547
---
 ACI.txt   |  20 ++-
 API.txt   | 100 +++-
 VERSION   |   4 +-
 freeipa.spec.in   |   2 +
 install/share/60basev2.ldif   |   3 +
 install/share/bootstrap-template.ldif |   6 +
 install/share/indices.ldif|  10 ++
 install/share/memberof-conf.ldif  |   4 +-
 install/updates/20-indices.update |   9 ++
 install/updates/40-delegation.update  |   8 +
 install/updates/45-roles.update   |   3 +
 install/updates/45-timerules.update   |   5 +
 install/updates/Makefile.am   |   1 +
 ipaclient/plugins/timerule.py |  59 +++
 ipalib/constants.py   |   1 +
 ipaserver/plugins/hbacrule.py | 177 +++-
 ipaserver/plugins/timerule.py | 295 ++
 17 files changed, 620 insertions(+), 87 deletions(-)
 create mode 100644 install/updates/45-timerules.update
 create mode 100644 ipaclient/plugins/timerule.py
 create mode 100644 ipaserver/plugins/timerule.py

diff --git a/ACI.txt b/ACI.txt
index fddd598..95f4643 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -97,15 +97,15 @@ aci: (targetattr = "businesscategory || cn || createtimestamp || description ||
 dn: cn=groups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Remove Groups";allow (delete) groupdn = "ldap:///cn=System: Remove Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Add HBAC Rule";allow (add) groupdn = "ldap:///cn=System: Add HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacrulev2))")(version 3.0;acl "permission:System: Add HBAC Rule";allow (add) groupdn = "ldap:///cn=System: Add HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Delete HBAC Rule";allow (delete) groupdn = "ldap:///cn=System: Delete HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacrulev2))")(version 3.0;acl "permission:System: Delete HBAC Rule";allow (delete) groupdn = "ldap:///cn=System: Delete HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "externalhost || memberhost || memberservice || memberuser")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Manage HBAC Rule Membership";allow (write) groupdn = "ldap:///cn=System: Manage HBAC Rule Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "externalhost || ipamembertimerule || memberhost || memberservice || memberuser")(targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacrulev2))")(version 3.0;acl "permission:System: Manage HBAC Rule Membership";allow (write) groupdn = "ldap:///cn=System: Manage HBAC Rule Membership,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "accessruletype || accesstime || cn || description || hostcategory || ipaenabledflag || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Modify HBAC Rule";allow (write) groupdn = "ldap:///cn=System: Modify HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetattr = "accessruletype || accesstime || cn || description || hostcategory || ipaenabledflag || ipamembertimerule || servicecategory || sourcehost || sourcehostcategory || usercategory")(targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacrulev2))")(version 3.0;acl "permission:System: Modify HBAC Rule";allow (write) groupdn = "ldap:///cn=System: Modify HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "accessruletype || accesstime || cn || createtimestamp || description || entryusn || externalhost || hostcategory

[Freeipa-devel] [freeipa PR#45] custodia: force reconnect before retrieving CA certs from LDAP (+ack)

2016-09-01 Thread mbasti-rh

jcholast's pull request #45: "custodia: force reconnect before retrieving CA 
certs from LDAP" label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/45
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#44] rpcserver: fix crash in XML-RPC system commands (+ack)

2016-09-01 Thread mirielka

jcholast's pull request #44: "rpcserver: fix crash in XML-RPC system commands" 
label *ack* has been added

See the full pull-request at https://github.com/freeipa/freeipa/pull/44
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#45] custodia: force reconnect before retrieving CA certs from LDAP (opened)

2016-09-01 Thread jcholast

jcholast's pull request #45: "custodia: force reconnect before retrieving CA 
certs from LDAP" was opened

PR body:
"""
Force reconnect to LDAP as DS might have been restarted after the
connection was opened, rendering the connection invalid.

This fixes a crash in ipa-replica-install with --setup-ca.

https://fedorahosted.org/freeipa/ticket/6207
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/45
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/45/head:pr45
git checkout pr45
From 903aa2c43e5c165cea20ba4c215c4f65290ad0a5 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Thu, 1 Sep 2016 10:32:18 +0200
Subject: [PATCH] custodia: force reconnect before retrieving CA certs from
 LDAP

Force reconnect to LDAP as DS might have been restarted after the
connection was opened, rendering the connection invalid.

This fixes a crash in ipa-replica-install with --setup-ca.

https://fedorahosted.org/freeipa/ticket/6207
---
 ipaserver/install/custodiainstance.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipaserver/install/custodiainstance.py b/ipaserver/install/custodiainstance.py
index 18bd514..3274027 100644
--- a/ipaserver/install/custodiainstance.py
+++ b/ipaserver/install/custodiainstance.py
@@ -158,6 +158,8 @@ def __get_keys(self, ca_host, cacerts_file, cacerts_pwd, data):
 # Add CA certificates
 tmpdb = CertDB(self.realm, nssdir=tmpnssdir)
 self.suffix = ipautil.realm_to_suffix(self.realm)
+if self.admin_conn is not None:
+self.ldap_disconnect()
 self.import_ca_certs(tmpdb, True)
 
 # Now that we gathered all certs, re-export
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#44] rpcserver: fix crash in XML-RPC system commands (opened)

2016-09-01 Thread jcholast

jcholast's pull request #44: "rpcserver: fix crash in XML-RPC system commands" 
was opened

PR body:
"""
Fix an AttributeError in XML-RPC methodSignature and methodHelp commands
caused by incorrect mangled name usage.

https://fedorahosted.org/freeipa/ticket/6217
"""

See the full pull-request at https://github.com/freeipa/freeipa/pull/44
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/44/head:pr44
git checkout pr44
From bb4a0bd9b76b003a33f9c1136cc595e9b2923c07 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Thu, 1 Sep 2016 09:59:37 +0200
Subject: [PATCH] rpcserver: fix crash in XML-RPC system commands

Fix an AttributeError in XML-RPC methodSignature and methodHelp commands
caused by incorrect mangled name usage.

https://fedorahosted.org/freeipa/ticket/6217
---
 ipaserver/rpcserver.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py
index dd446ae..f1d5a40 100644
--- a/ipaserver/rpcserver.py
+++ b/ipaserver/rpcserver.py
@@ -311,7 +311,7 @@ def _on_finalize(self):
 if 'wsgi_dispatch' in self.api.Backend:
 self.api.Backend.wsgi_dispatch.mount(self, self.key)
 
-def __get_command(self, name):
+def _get_command(self, name):
 try:
 # assume version 1 for unversioned command calls
 command = self.api.Command[name, '1']
@@ -362,7 +362,7 @@ def wsgi_execute(self, environ):
 if name in self._system_commands:
 result = self._system_commands[name](self, *args, **options)
 else:
-command = self.__get_command(name)
+command = self._get_command(name)
 result = command(*args, **options)
 except PublicError as e:
 if self.api.env.debug:
@@ -713,7 +713,7 @@ def methodSignature(self, *params):
 # for now let's not go out of our way to document standard XML-RPC
 return u'undef'
 else:
-self.__get_command(method_name)
+self._get_command(method_name)
 
 # All IPA commands return a dict (struct),
 # and take a params, options - list and dict (array, struct)
@@ -725,7 +725,7 @@ def methodHelp(self, *params):
 if method_name in self._system_commands:
 return u''
 else:
-command = self.__get_command(method_name)
+command = self._get_command(method_name)
 return unicode(command.doc or '')
 
 _system_commands = {
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [freeipa PR#42] Tests: Avoid skipping tests due to missing files (synchronize)

2016-09-01 Thread mirielka

mirielka's pull request #42: "Tests: Avoid skipping tests due to missing files" 
was synchronize

See the full pull-request at https://github.com/freeipa/freeipa/pull/42
... or pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/42/head:pr42
git checkout pr42
From afadf30be59933daab429231f51e87bf57559038 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Thu, 1 Sep 2016 09:46:17 +0200
Subject: [PATCH] Tests: Avoid skipping tests due to missing files

When running test_install/test_updates and test_pkcs10/test_pkcs10 as
outoftree, these are skipped with reason 'Unable to find test update files'.
For outoftree tests wrong paths are checked for these files.
Changing file localization to provide proper test setup.

https://fedorahosted.org/freeipa/ticket/6284
---
 ipatests/test_install/test_updates.py | 41 +--
 ipatests/test_pkcs10/test_pkcs10.py   | 11 +-
 2 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/ipatests/test_install/test_updates.py b/ipatests/test_install/test_updates.py
index b41a7c5..3fa2cd7 100644
--- a/ipatests/test_install/test_updates.py
+++ b/ipatests/test_install/test_updates.py
@@ -65,11 +65,9 @@ def setUp(self):
 self.updater = LDAPUpdate(dm_password=self.dm_password, sub_dict={})
 self.ld = ipaldap.IPAdmin(fqdn)
 self.ld.do_simple_bind(bindpw=self.dm_password)
-if ipautil.file_exists("0_reset.update"):
-self.testdir="./"
-elif ipautil.file_exists("ipatests/test_install/0_reset.update"):
-self.testdir= "./ipatests/test_install/"
-else:
+self.testdir = os.path.abspath(os.path.dirname(__file__))
+if not ipautil.file_exists(os.path.join(self.testdir,
+"0_reset.update")):
 raise nose.SkipTest("Unable to find test update files")
 
 self.container_dn = DN(self.updater._template_str('cn=test, cn=accounts, $SUFFIX'))
@@ -84,7 +82,8 @@ def test_0_reset(self):
 Reset the updater test data to a known initial state (test_0_reset)
 """
 try:
-modified = self.updater.update([self.testdir + "0_reset.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "0_reset.update")])
 except errors.NotFound:
 # Just means the entry doesn't exist yet
 modified = True
@@ -103,7 +102,8 @@ def test_1_add(self):
 """
 Test the updater with an add directive (test_1_add)
 """
-modified = self.updater.update([self.testdir + "1_add.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "1_add.update")])
 
 self.assertTrue(modified)
 
@@ -137,7 +137,8 @@ def test_2_update(self):
 """
 Test the updater when adding an attribute to an existing entry (test_2_update)
 """
-modified = self.updater.update([self.testdir + "2_update.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "2_update.update")])
 self.assertTrue(modified)
 
 entries = self.ld.get_entries(
@@ -150,7 +151,8 @@ def test_3_update(self):
 """
 Test the updater forcing an attribute to a given value (test_3_update)
 """
-modified = self.updater.update([self.testdir + "3_update.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "3_update.update")])
 self.assertTrue(modified)
 
 entries = self.ld.get_entries(
@@ -163,7 +165,8 @@ def test_4_update(self):
 """
 Test the updater adding a new value to a single-valued attribute (test_4_update)
 """
-modified = self.updater.update([self.testdir + "4_update.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "4_update.update")])
 self.assertTrue(modified)
 
 entries = self.ld.get_entries(
@@ -176,7 +179,8 @@ def test_5_update(self):
 """
 Test the updater adding a new value to a multi-valued attribute (test_5_update)
 """
-modified = self.updater.update([self.testdir + "5_update.update"])
+modified = self.updater.update([os.path.join(self.testdir,
+ "5_update.update")])
 self.assertTrue(modified)
 
 entries = self.ld.get_entries(
@@ -189,7 +193,8 @@ def test_6_update(self):
 """
 Test the updater removing a value from a multi-valued attribute (test_6_update)
 """
-modified = self.updater.update([self.testdir + "6_update.update"])
+modified =