Re: [Freeipa-devel] Time-based account policies

2015-03-26 Thread Jan Cholasta 

Dne 24.3.2015 v 19:20 Simo Sorce napsal(a):

On Tue, 2015-03-24 at 08:40 +0100, Martin Kosek wrote:

On 03/24/2015 08:20 AM, Jakub Hrozek wrote:

On Tue, Mar 24, 2015 at 08:07:53AM +0100, Martin Kosek wrote:

On 03/24/2015 07:16 AM, Jan Cholasta wrote:

Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):

...

Given the above, HBAC rules could contain (time, anchor), where anchor
is UTC, user local time or host local time.

Truth is, it was not really clear to me from the last week's discussion
whose Local Time to use - do we use host's or do we use user's?  It
would make sense to me to use the user's local time. But then you would
need to really store at least the timezone information with each user
object. And that information should probably change with user moving
between different timezones. That's quite a pickle I am in right here.


IMO whether to use user or host local time depends on organization local
policy, hence my suggestion to support both.


I am bit confused, I would like to make sure we are on the same page with
regards to Local Time. When the Local Time rule is created, anchor will be set
to Local Time. Then SSSD would simply use host's local time, in whichever
time zone the HBAC host is.


Yes, that was my understanding also.



So this is the default host enforcement. For the user, you want to let SSSD
check authenticated user's entry, to see if there is a timezone information?
This would of course depend on the information being available. For AD users,
you would need to set it in ID Views or similar.


Yes, also in a previous e-mail, there was a suggestion to change
timezones by admin when the user changes timezones -- I didn't like that
part, it seems really error prone and tedious. *If* there was this
choice, it should not be the default, rather the default should also be
host local time IMO.


Host local time zone was the original case I expected. Enforcing *user* local
time zone is where this discussion started. Honze proposed making this an
option - leaving us to 3 different time modes:

* UTC - stored as (time + olson time zone), enforcement is clear
* Host Local Time - stored as  (time + Host Local Time), enforcement by
/etc/localtime
* User Local Time - stored as  (time + User Local Time), enforcement by ???

So the rule may be:
* Employee Foo can access web service Bar only in his work hours

IMO, it is realistic for an administrator to set the time zone setting in the
employee entry. Of course, it gets tricky when the user starts moving around
the globe...



Host Based Access Control is about controlling access based on the
*HOST*.


Except you can control access based on user identity or group membership 
with HBAC.




I do not see any space for user time zones honestly.


Well, I don't see what's so interesting about host time. Users have 
bussiness hours, hosts don't. Users can move between time zones by 
themselves, hosts can't.




If and when someone will vehemently ask for 'per-user' time zones we can
talk about it.

Simo.




--
Jan Cholasta

--
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] Time-based account policies

2015-03-26 Thread Jan Cholasta 

Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):

On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:

When using hbactest command you just need to supply implied time zone
as an option to the command itself. After all, you are simulating rule
execution so it does not matter where the value comes from.

Oh, good, I haven't thought of that. That certainly eases things up.

Let me make a summary then, a short one this time, of what's been
discussed .

It seems the best way to store time policies is indeed the format (time,
anchor) where anchor is either Olson database timezone or Local Time
for host local time. We are omitting users' local time because, after
all, we are talking HBAC Rules here (great point by Simo). If the admins
really needed that, there's a workaround Jan mentioned that should work
just fine.


What I originally meant as anchor was a value specifying the time offset 
(e.g. utc - access time uses UTC, rule - access time uses time zone 
specified in the HBAC rule, host - access time uses host's time zone), 
rather than the time zone itself or Local Time.




That leaves us with 2 kinds of policies - UTC and Local Time (which is
enforced by hosts' /etc/localtime). Now with the (time, anchor) format
for time policies, the LDAP schema wouldn't have to change and we could
just use the AccessTime attribute of the HBAC Rule object that's already
there. That seems like a good solution to me.

I hope we can agree on the above although any notes are, of course,
welcome. Now we would need to choose the right format for the time part
of (time, anchor) I guess. There's been a discussion some 2 weeks ago
about the need for event recurrence support in the format, the need for
exceptions support and the need for iCalendar import possibility. So
far, there are three possible languages to choose from - use the actual
iCalendar or just a part of it, use a reworked version of the old
language used in FreeIPA and SSSD, or use the language I proposed
earlier in this thread.

I would be very keen on hearing your ideas and opinions on this one.

Thanks!
Standa



--
Jan Cholasta

--
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] Time-based account policies

2015-03-26 Thread Standa Láznička 

On 3/26/2015 11:13 AM, Jan Cholasta wrote:

Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):

On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:

When using hbactest command you just need to supply implied time zone
as an option to the command itself. After all, you are simulating rule
execution so it does not matter where the value comes from.

Oh, good, I haven't thought of that. That certainly eases things up.

Let me make a summary then, a short one this time, of what's been
discussed .

It seems the best way to store time policies is indeed the format (time,
anchor) where anchor is either Olson database timezone or Local Time
for host local time. We are omitting users' local time because, after
all, we are talking HBAC Rules here (great point by Simo). If the admins
really needed that, there's a workaround Jan mentioned that should work
just fine.


What I originally meant as anchor was a value specifying the time 
offset (e.g. utc - access time uses UTC, rule - access time uses 
time zone specified in the HBAC rule, host - access time uses host's 
time zone), rather than the time zone itself or Local Time.


You're right, that's probably more descriptive than just Local Time. 
Still, I think that instead of rule a timezone might just as well 
appear on the anchor part. I think UTC is also part of Olson's so it 
should be at the same spot as the timezone.


That leaves us with 2 kinds of policies - UTC and Local Time (which is
enforced by hosts' /etc/localtime). Now with the (time, anchor) format
for time policies, the LDAP schema wouldn't have to change and we could
just use the AccessTime attribute of the HBAC Rule object that's already
there. That seems like a good solution to me.

I hope we can agree on the above although any notes are, of course,
welcome. Now we would need to choose the right format for the time part
of (time, anchor) I guess. There's been a discussion some 2 weeks ago
about the need for event recurrence support in the format, the need for
exceptions support and the need for iCalendar import possibility. So
far, there are three possible languages to choose from - use the actual
iCalendar or just a part of it, use a reworked version of the old
language used in FreeIPA and SSSD, or use the language I proposed
earlier in this thread.

I would be very keen on hearing your ideas and opinions on this one.

Thanks!
Standa





--
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] FreeIPA 4.1.4 release and fixes for CVE-2015-1827 and CVE-2015-0283

2015-03-26 Thread Alexander Bokovoy 

Hi,

I've released slapi-nis 0.54.2 this morning as a fix for CVE-2015-0283,
packages are built for Fedora and RHEL7.1. However, to complete the
cycle, we need to release FreeIPA 4.1.4 to fix CVE-2015-1827.

Both CVEs are for processing of group membership when dealing with users
from trusted AD domains. Fix in FreeIPA is in extdom plugin which is in
use by sssd 1.12.x, while slapi-nis fix is for legacy clients.

We need to commit attached patches to FreeIPA and make a release of
FreeIPA 4.1.4 today. Then I can do Fedora builds and a combined update
push for slapi-nis+freeipa packages in Fedora.

Patch 1 is actual CVE-2015-1827 fix.

Patch 2 is to remove wrong values from Makefile.am files that actually
prevent regenerating Makefiles in daemons/ subdirectory, causing
non-working RHEL build. We fixed 4.1.0 base with this patch in RHEL and
we just need to bring upstream in sync with downstream on this.

Patch 3 raises requirement of slapi-nis to the fixed version.

--
/ Alexander Bokovoy
From 175a63357354ae3b4c04fa9cbef0cbe6084f0bee Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Wed, 25 Feb 2015 10:28:22 +0100
Subject: [PATCH 1/3] extdom: fix wrong realloc size

---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index 47bcb17..686128e 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -386,7 +386,7 @@ static int get_user_grouplist(const char *name, gid_t gid,
 
 ret = getgrouplist(name, gid, groups, ngroups);
 if (ret == -1) {
-new_groups = realloc(groups, ngroups);
+new_groups = realloc(groups, ngroups * sizeof(gid_t));
 if (new_groups == NULL) {
 free(groups);
 return LDAP_OPERATIONS_ERROR;
-- 
2.1.0

From 3811fee25fff1074e39cf541a5fa0c411255e9f4 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Wed, 18 Mar 2015 17:09:06 +
Subject: [PATCH 2/3] fix Makefile.am for daemons

---
 daemons/Makefile.am| 2 +-
 daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am| 1 -
 daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am | 1 -
 daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am| 1 -
 4 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/daemons/Makefile.am b/daemons/Makefile.am
index 956f399..f919429 100644
--- a/daemons/Makefile.am
+++ b/daemons/Makefile.am
@@ -1,6 +1,6 @@
 # This file will be processed with automake-1.7 to create Makefile.in
 #
-AUTOMAKE_OPTIONS = 1.7
+AUTOMAKE_OPTIONS = 1.7 subdir-objects
 
 NULL =
 
diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am 
b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am
index 8e35cdb..fba5b08 100644
--- a/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-cldap/Makefile.am
@@ -6,7 +6,6 @@ AM_CPPFLAGS =   
\
-I. \
-I$(srcdir) \
-I$(PLUGIN_COMMON_DIR)  \
-   -I$(COMMON_BER_DIR) \
-DPREFIX=\$(prefix)\\
-DBINDIR=\$(bindir)\\
-DLIBDIR=\$(libdir)\\
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
index a167981..8ee26a7 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
@@ -7,7 +7,6 @@ AM_CPPFLAGS =   
\
-I$(srcdir) \
-I$(PLUGIN_COMMON_DIR)  \
-I$(KRB5_UTIL_DIR)  \
-   -I$(COMMON_BER_DIR) \
-DPREFIX=\$(prefix)\\
-DBINDIR=\$(bindir)\\
-DLIBDIR=\$(libdir)\\
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
index 1ab6c67..078ff9c 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
@@ -14,7 +14,6 @@ AM_CPPFLAGS = 
\
-I$(PLUGIN_COMMON_DIR)  \
-I$(KRB5_UTIL_DIR)  \
-I$(ASN1_UTIL_DIR)  \
-   -I$(COMMON_BER_DIR)

Re: [Freeipa-devel] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 01:08 PM, Standa Láznička wrote:
 On 3/26/2015 11:13 AM, Jan Cholasta wrote:
 Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
 On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
 When using hbactest command you just need to supply implied time zone
 as an option to the command itself. After all, you are simulating rule
 execution so it does not matter where the value comes from.
 Oh, good, I haven't thought of that. That certainly eases things up.

 Let me make a summary then, a short one this time, of what's been
 discussed .

 It seems the best way to store time policies is indeed the format (time,
 anchor) where anchor is either Olson database timezone or Local Time
 for host local time. We are omitting users' local time because, after
 all, we are talking HBAC Rules here (great point by Simo). If the admins
 really needed that, there's a workaround Jan mentioned that should work
 just fine.

 What I originally meant as anchor was a value specifying the time offset
 (e.g. utc - access time uses UTC, rule - access time uses time zone
 specified in the HBAC rule, host - access time uses host's time zone),
 rather than the time zone itself or Local Time.

 You're right, that's probably more descriptive than just Local Time. Still, 
 I
 think that instead of rule a timezone might just as well appear on the 
 anchor
 part. I think UTC is also part of Olson's so it should be at the same spot 
 as
 the timezone.

I am not little confused about all the places where we want to add the time
zone. I thought that it was originally meant for hosts objects, so that we can
HBAC rule is created, UI/CLI can already suggest the right time zone for the
HBAC rule. But it should have been only informative value serving mostly UX,
not something that SSSD would decide on.

HBAC rule itself is always the authoritative source. We should also avoid
having time zone in 2 places in the HBAC rule itself - if this is what you are
steering at. I thought the authoritative time zone would be only in the HBAC
time definition only, i.e. only in the anchor specifically.

Can we show specific examples of these tuples, to make sure we are in
agreement? My take was:

(Mon-Fri 08:00-17:00, UTC+1)
(Mon-Fri 08:00-17:00, local)

UTC+1 may not be ideal as it would not work for daylight saving, a better way
would indeed be the Olson time zone ID, i.e:

(Mon-Fri 08:00-17:00, Europe/Prague)
(Mon-Fri 08:00-17:00, local)

-- 
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 0023] enable debugging of spawned ntpd command during client install

2015-03-26 Thread Martin Babinsky 

On 03/26/2015 01:14 PM, Martin Kosek wrote:

On 03/25/2015 04:18 PM, Jan Cholasta wrote:

Hi,

Dne 25.3.2015 v 15:26 Martin Babinsky napsal(a):

The attached patch related to https://fedorahosted.org/freeipa/ticket/4931


Please make sure https://fedorahosted.org/freeipa/ticket/3048 stays fixed.
This should be ok as we do not use ntpdate for timesync anymore (I have 
tested client-install with this patch in VM with quite large clock skews 
between client and server and it did sync just fine also with -d flag).




It is certainly not a final solution, more of an initial hack of sorts
just to gather some suggestions, since I am not even sure if this is the
right thing to do.

The reporter from bugzilla suggests to enable debugging of ALL commands
called through ipautil.run(), but I think that fixing all cca 157 found
usages of run() is too much work with a quite small benefit.

Anyway I would welcome some opinions about this: should the external
commands really inherit the debug settings of ipa-* utilities, and if
so, is the method showed in this patch the right way to do it?


I am not a fan of this method, ipautil.run does not know anything about the
command it runs and I think it should stay that way.

I would prefer to have an ipautil.run wrapper with debug flag using appropriate
debugging option for each command where we need to conditionally enable
debugging. Or just add the debugging option unconditionally to every command
where it could be useful.


+1, I do not like this change to ipautil.run either. It should be sole
responsibility of the caller to specify the right combinations of options,
including debug option, where applicable.



How should we attack this issue then?

If we really would do all comands inherit the debug option, then it 
would be a good idea to avoid things like


if options.debug:
args.append('-d')

littered all over the install/upgrade/etc. code. Jan's idea of a wrapper 
around run() then sounds like a good move. But I suppose we would then 
need to store somewhere (ipaplatform?) an additional data saying which 
command uses which option for debugging.


(Or should we just slap on an optional '-d' passed to ntpd to quickly 
resolve the main issue in the ticket and worry about all of this later? ;))


--
Martin^3 Babinsky

--
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] [PATCHES 0001-0002] ipa-client-install NTP fixes

2015-03-26 Thread Petr Vobornik 

On 03/16/2015 03:58 PM, Martin Kosek wrote:

On 03/16/2015 01:56 PM, Martin Babinsky wrote:


I have tested the patches on F21 client and they work as expected.



I take that as an ACK. Before pushing the change, I just changed one print
format from %s to %d given a number was printed.

Pushed to:
master: a58b77ca9cd3620201306258dd6bd05ea1c73c73
ipa-4-1: 80aeb445e2034776f08668bf04dfd711af477b25

Petr1, it would be nice to get this one built on F21+, to unblock Ipsilon 
project.



I've noticed that patch 0001 was not pushed.

Pushed to:
master:
* f0c1daf7a2a8c88f6d84d81d66c7e39f571e0894 Skip time sync during client 
install when using --no-ntp

ipa-4-1:
* b5969c1d1ae6eb1e392e0420fcbf094ae7b34102 Skip time sync during client 
install when using --no-ntp


Note: it's part of Fedora builds as a separate patch (that's why I noticed)
--
Petr Vobornik

--
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.1.4

2015-03-26 Thread Petr Vobornik 

The FreeIPA team would like to announce FreeIPA v4.1.4 security release!

It can be downloaded from http://www.freeipa.org/page/Downloads. The 
builds will be available for Fedora 21. Builds for Fedora 20 are 
available in the official COPR repository 
https://copr.fedoraproject.org/coprs/mkosek/freeipa/.


== Highlights in 4.1.4 ==

=== Security fixes ===
* 'CVE-2015-1827' It was discovered that the IPA extdom Directory Server 
plug-in did not correctly perform memory reallocation when handling user 
account information. A request for a list of groups for a user that 
belongs to a large number of groups would cause a Directory Server to 
crash.
* 'CVE-2015-0283' Additionally, FreeIPA 4.1.4 requires use of slapi-nis 
0.54.2 which includes number of fixes for the CVE-2015-0283:


It was discovered that the slapi-nis Directory Server plug-in did not 
correctly perform memory reallocation when handling user account 
information. A request for information about a group with many members, 
or a request for a user that belongs to a large number of groups, would 
cause a Directory Server to enter an infinite loop and consume an 
excessive amount of CPU time.


These issues were discovered by Sumit Bose of Red Hat.

=== Enhancements ===
* Various documentation improvements by Gabe Alford

=== Bug fixes ===
* Various fixes to DNSSEC support and overall DNS deployment scripts
* Improvements in handling CA certificates from previous deployments 
when installing FreeIPA clients

* Licensing of FreeIPA is clarified with regards to OpenSSL integration
* More robust configuration of slapi-nis plugin to prevent potential 
dead-locks with other operations requiring lower-level database access.


== Upgrading ==
Upgrade instructions are available on upgrade page 
http://www.freeipa.org/page/Upgrade.


== 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.1.3 ==
=== Alexander Bokovoy (2) ===
* fix Makefile.am for daemons
* slapi-nis: require 0.54.2 for CVE-2015-0283 fixes

=== David Kupka (2) ===
* Use IPA CA certificate when available and ignore NO_TLS_LDAP when not.
* Restore default.conf and use it to build API.

=== Gabe Alford (3) ===
* ipa-replica-prepare should document ipv6 options
* ipatests: Add tests for valid and invalid ipa-advise
* ipa-replica-prepare can only be created on the first master

=== Jan Cholasta (4) ===
* certstore: Make certificate retrieval more robust
* client-install: Do not crash on invalid CA certificate in LDAP
* client: Fix ca_is_enabled calls
* upload_cacrt: Fix empty cACertificate in cn=CAcert

=== Martin Babinsky (3) ===
* ipa-dns-install: use STARTTLS to connect to DS
* migrate-ds: print out failed attempts when no users/groups are migrated
* show the exception message thrown by dogtag._parse_ca_status during 
install


=== Martin Bašti (7) ===
* DNSSEC add support for CKM_RSA_PKCS_OAEP mechanism
* Fix memory leaks in ipap11helper
* Remove unused method from ipap11pkcs helper module
* DNS fix: do not traceback if unsupported records are in LDAP
* DNS fix: do not show part options for unsupported records
* DNS: remove NSEC3PARAM from records
* Fix dead code in ipap11helper module

=== Martin Košek (1) ===
* Remove references to GPL v2.0 license

=== Nathan Kinder (1) ===
* Timeout when performing time sync during client install

=== Petr Voborník (2) ===
* ipatests: add missing ssh object classes to idoverrideuser
* Become IPA 4.1.4

=== Petr Špaček (3) ===
* p11helper: standardize indentation and other visual aspects of the code
* p11helper: use sizeof() instead of magic constants
* p11helper: clarify error message

=== Simo Sorce (2) ===
* Add a clear OpenSSL exception.
* Stop including the DES algorythm from openssl.

=== Sumit Bose (7) ===
* ipa-range-check: do not treat missing objects as error
* Add configure check for cwrap libraries
* extdom: handle ERANGE return code for getXXYYY_r() calls
* extdom: make nss buffer configurable
* extdom: return LDAP_NO_SUCH_OBJECT to the client
* extdom: fix memory leak
* extdom: fix wrong realloc size

=== Tomáš Babej (3) ===
* ipatests: Add coverage for adding and removing sshpubkeys in ID overrides
* ipalib: Make sure correct attribute name is referenced for fax
* idviews: Use case-insensitive detection of Default Trust View

=== Thierry Bordaz (1) ===
* Limit deadlocks between DS plugin DNA and slapi-nis
--
Petr Vobornik

--
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 05:06 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:47 +0100, Martin Kosek wrote:
...
 Reference:
 http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html
 
 I see how the language I sued may be confusing. But I was pointing out
 only that you can't just do one or the other you have to support all
 these cases, I wasn't advocating using UTC as the timezoned option.
 
 If I should choose I would support all three flavors:
 - the special Local Time string
 - the Olson database (Europe/Rome)
 - absolute UTC offsets (UTC+4)

Yup, makes sense.

 However I would not publicize the latter much in the UI, as it is rarely
 what the admin really should do.



-- 
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 04:57 PM, Jan Cholasta wrote:
 Dne 26.3.2015 v 16:47 Martin Kosek napsal(a):
 On 03/26/2015 04:39 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
 On 03/26/2015 04:26 PM, Jan Cholasta wrote:

 [...]
 I don't see any point in storing time zone in the host object, if it's not
 used
 for anything meaningful and has to be manually synchronized with the 
 host's
 actual configured time zone.

 It would be mostly used for aiding the HBAC rule creation process, i.e. for
 the
 UX. It would be optional. If you do not fill it, you would have to always
 select the right time zone in when setting the UTC HBAC time,

 If you fill the zone, UI could already select the right time zone for you.


 It will only help to do mistakes, how does the host object get to know
 what is the host's timezone ? And in any case you generally create HBAC
 rules using groups of hosts, what is the UI gonna do ? Crawl all the
 hosts in a group and then ? Average add the most common time zone ?

 Search hosts, gather all time zones and list them as choices or simply warn
 that there are more time zones and Local Time based rule is preferred? :-)

 Drop it please :)

 If there is no one interested in it, we can drop it. Such UX improvement can
 also be added later, if there is a need.
 
 If we want to improve the UX by babysitting the administrator based on random
 guesses, we might as well add Clippy to IPA:
 
  __
 /  \_
 |  |   / \
 @  @   | It looks|
 || ||  | like you|
 || ||   --| are setting |
 |\_/|  | time zone   |
 \___/  \_/
 
 
 ;-)
 

:-D

I see your point. Just note that what seems as neeedless babysitting from your
(or other) POV may be a very useful UX for the real world user. But in this
case we can wait until we hear from that real world user that he struggles with
the potential time based rules UI.

-- 
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] Time-based account policies

2015-03-26 Thread Simo Sorce 
On Thu, 2015-03-26 at 16:47 +0100, Martin Kosek wrote:
 On 03/26/2015 04:39 PM, Simo Sorce wrote:
  On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
  On 03/26/2015 04:26 PM, Jan Cholasta wrote:
  
  [...]
  I don't see any point in storing time zone in the host object, if it's 
  not used
  for anything meaningful and has to be manually synchronized with the 
  host's
  actual configured time zone.
 
  It would be mostly used for aiding the HBAC rule creation process, i.e. 
  for the
  UX. It would be optional. If you do not fill it, you would have to always
  select the right time zone in when setting the UTC HBAC time,
 
  If you fill the zone, UI could already select the right time zone for you.
  
  
  It will only help to do mistakes, how does the host object get to know
  what is the host's timezone ? And in any case you generally create HBAC
  rules using groups of hosts, what is the UI gonna do ? Crawl all the
  hosts in a group and then ? Average add the most common time zone ?
 
 Search hosts, gather all time zones and list them as choices or simply warn
 that there are more time zones and Local Time based rule is preferred? :-)
 
  Drop it please :)
 
 If there is no one interested in it, we can drop it. Such UX improvement can
 also be added later, if there is a need.
 
  
  Host's Local Time and UTC time are 2 different approaches how to set the 
  time
  for the HBAC rule. With Local Time type, you would of course not have to 
  deal
  with time zones. I thought this was already cleared out.
  
  Sorry you confuse me, in which case do you need UTC ?
  In case you want to set an absolute time  that doesn't change with DST ?
 
 I am confused as well. Wasn't it you who expressed the need to have 2 
 different
 approaches for HBAC time rules - Local Time and fixed UTC time?

Not really, Olson is correct.

 Reference:
 http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html

I see how the language I sued may be confusing. But I was pointing out
only that you can't just do one or the other you have to support all
these cases, I wasn't advocating using UTC as the timezoned option.

If I should choose I would support all three flavors:
- the special Local Time string
- the Olson database (Europe/Rome)
- absolute UTC offsets (UTC+4)

However I would not publicize the latter much in the UI, as it is rarely
what the admin really should do.

Simo.

-- 
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] Time-based account policies

2015-03-26 Thread Standa Láznička 

On 3/26/2015 1:24 PM, Martin Kosek wrote:

On 03/26/2015 01:08 PM, Standa Láznička wrote:

On 3/26/2015 11:13 AM, Jan Cholasta wrote:

Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):

On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:

When using hbactest command you just need to supply implied time zone
as an option to the command itself. After all, you are simulating 
rule

execution so it does not matter where the value comes from.

Oh, good, I haven't thought of that. That certainly eases things up.

Let me make a summary then, a short one this time, of what's been
discussed .

It seems the best way to store time policies is indeed the format 
(time,

anchor) where anchor is either Olson database timezone or Local Time
for host local time. We are omitting users' local time because, after
all, we are talking HBAC Rules here (great point by Simo). If the 
admins
really needed that, there's a workaround Jan mentioned that should 
work

just fine.
What I originally meant as anchor was a value specifying the time 
offset

(e.g. utc - access time uses UTC, rule - access time uses time zone
specified in the HBAC rule, host - access time uses host's time 
zone),

rather than the time zone itself or Local Time.

You're right, that's probably more descriptive than just Local 
Time. Still, I
think that instead of rule a timezone might just as well appear on 
the anchor
part. I think UTC is also part of Olson's so it should be at the 
same spot as

the timezone.
I am not little confused about all the places where we want to add the 
time
zone. I thought that it was originally meant for hosts objects, so 
that we can
HBAC rule is created, UI/CLI can already suggest the right time zone 
for the
HBAC rule. But it should have been only informative value serving 
mostly UX,

not something that SSSD would decide on.

HBAC rule itself is always the authoritative source. We should also avoid
having time zone in 2 places in the HBAC rule itself - if this is what 
you are
steering at. I thought the authoritative time zone would be only in 
the HBAC

time definition only, i.e. only in the anchor specifically.
I think the timezone still may be with the host object but only as the 
UI helper as you suggest. Although I would maybe rather not see it with 
the object at all and have the admin just set the right timezone for the 
HBAC rule themselves. After all, if there's a collision of host helper 
timezones, I think admin would have to do that anyway.


I agree that there should only be one timezone record for each HBAC and 
I wouldn't suggest differently. There was a confusion when Jan suggested 
to use rule as anchor in the (time, anchor) tuple to get the rule's 
timezone which, he suggested, should be stored elsewhere but in the 
tuple. I think there's no harm having the timezone/host keyword stored 
with this tuple and therefore nowhere else.

Can we show specific examples of these tuples, to make sure we are in
agreement? My take was:

(Mon-Fri 08:00-17:00, UTC+1)
(Mon-Fri 08:00-17:00, local)

UTC+1 may not be ideal as it would not work for daylight saving, a 
better way

would indeed be the Olson time zone ID, i.e:

(Mon-Fri 08:00-17:00, Europe/Prague)
(Mon-Fri 08:00-17:00, local)
Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we 
want to use Olson's database names. If I understand it right, UTC is 
in Olson's and stands for UTC+0 offset. If not, we can have UTC 
keyword in the anchor part of the tuple mentioned above to signalize 
just that (UTC+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

Re: [Freeipa-devel] [PATCH 0020] show the exception message raised by dogtag._parse_ca_status during install

2015-03-26 Thread Petr Vobornik 

On 03/26/2015 04:26 AM, Fraser Tweedale wrote:

On Wed, Mar 25, 2015 at 12:09:09PM +0100, Martin Babinsky wrote:

This should be patch 20 I think. I must make some cleanup in my patch
numbers.

https://fedorahosted.org/freeipa/ticket/4885

--
Martin^3 Babinsky


ACK



Pushed to:
master: e8d4f6dba1743389962e9d51871a88dc384840ec
ipa-4-1: d7863f3e1ee8cbd5acda26ce1170913ca936ce7e
--
Petr Vobornik

--
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 02:40 PM, Standa Láznička wrote:
 On 3/26/2015 1:24 PM, Martin Kosek wrote:
 On 03/26/2015 01:08 PM, Standa Láznička wrote:
 On 3/26/2015 11:13 AM, Jan Cholasta wrote:
 Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
 On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
 When using hbactest command you just need to supply implied time zone
 as an option to the command itself. After all, you are simulating rule
 execution so it does not matter where the value comes from.
 Oh, good, I haven't thought of that. That certainly eases things up.

 Let me make a summary then, a short one this time, of what's been
 discussed .

 It seems the best way to store time policies is indeed the format (time,
 anchor) where anchor is either Olson database timezone or Local Time
 for host local time. We are omitting users' local time because, after
 all, we are talking HBAC Rules here (great point by Simo). If the admins
 really needed that, there's a workaround Jan mentioned that should work
 just fine.
 What I originally meant as anchor was a value specifying the time offset
 (e.g. utc - access time uses UTC, rule - access time uses time zone
 specified in the HBAC rule, host - access time uses host's time zone),
 rather than the time zone itself or Local Time.

 You're right, that's probably more descriptive than just Local Time. 
 Still, I
 think that instead of rule a timezone might just as well appear on the 
 anchor
 part. I think UTC is also part of Olson's so it should be at the same 
 spot as
 the timezone.
 I am not little confused about all the places where we want to add the time
 zone. I thought that it was originally meant for hosts objects, so that we 
 can
 HBAC rule is created, UI/CLI can already suggest the right time zone for the
 HBAC rule. But it should have been only informative value serving mostly UX,
 not something that SSSD would decide on.

 HBAC rule itself is always the authoritative source. We should also avoid
 having time zone in 2 places in the HBAC rule itself - if this is what you 
 are
 steering at. I thought the authoritative time zone would be only in the HBAC
 time definition only, i.e. only in the anchor specifically.
 I think the timezone still may be with the host object but only as the UI
 helper as you suggest. Although I would maybe rather not see it with the 
 object
 at all and have the admin just set the right timezone for the HBAC rule
 themselves. After all, if there's a collision of host helper timezones, I 
 think
 admin would have to do that anyway.

Right. But UI could then offer:

Warning, time zone is ambiguous. Please select the right time zone:
HostA time zone: Europe/Prague  [ ]
HostB time zone: Europe/London  [ ]

 I agree that there should only be one timezone record for each HBAC and I
 wouldn't suggest differently. There was a confusion when Jan suggested to use
 rule as anchor in the (time, anchor) tuple to get the rule's timezone which,
 he suggested, should be stored elsewhere but in the tuple. I think there's no
 harm having the timezone/host keyword stored with this tuple and therefore
 nowhere else.
 Can we show specific examples of these tuples, to make sure we are in
 agreement? My take was:

 (Mon-Fri 08:00-17:00, UTC+1)
 (Mon-Fri 08:00-17:00, local)

 UTC+1 may not be ideal as it would not work for daylight saving, a better way
 would indeed be the Olson time zone ID, i.e:

 (Mon-Fri 08:00-17:00, Europe/Prague)
 (Mon-Fri 08:00-17:00, local)
 Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we want 
 to
 use Olson's database names. If I understand it right, UTC is in Olson's and
 stands for UTC+0 offset. If not, we can have UTC keyword in the anchor part
 of the tuple mentioned above to signalize just that (UTC+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

Re: [Freeipa-devel] [PATCH] FreeIPA 4.1.4 release and fixes for CVE-2015-1827 and CVE-2015-0283

2015-03-26 Thread Petr Vobornik 

On 03/26/2015 02:20 PM, Alexander Bokovoy wrote:

Hi,

I've released slapi-nis 0.54.2 this morning as a fix for CVE-2015-0283,
packages are built for Fedora and RHEL7.1. However, to complete the
cycle, we need to release FreeIPA 4.1.4 to fix CVE-2015-1827.

Both CVEs are for processing of group membership when dealing with users
from trusted AD domains. Fix in FreeIPA is in extdom plugin which is in
use by sssd 1.12.x, while slapi-nis fix is for legacy clients.

We need to commit attached patches to FreeIPA and make a release of
FreeIPA 4.1.4 today. Then I can do Fedora builds and a combined update
push for slapi-nis+freeipa packages in Fedora.

Patch 1 is actual CVE-2015-1827 fix.

Patch 2 is to remove wrong values from Makefile.am files that actually
prevent regenerating Makefiles in daemons/ subdirectory, causing
non-working RHEL build. We fixed 4.1.0 base with this patch in RHEL and
we just need to bring upstream in sync with downstream on this.

Patch 3 raises requirement of slapi-nis to the fixed version.



These patches has been already tested while the CVE was embargoed.

pushed to
ipa-4-1:
* 447c5c7b0d76482dbb4273ea968a87cee2f4cddd fix Makefile.am for daemons
* fd8e796873f34c942b8ab28d486b5edfe1c27abd extdom: fix wrong realloc size
master:
* 704c79d91d58f87b80afe6e9331e8060116b5ec0 fix Makefile.am for daemons
* c1114ef82516002de08e004a930b5ba4a1791b25 extdom: fix wrong realloc size

ipa-4-1:
* 93302a8c28731625a0e38e647be50a9598bb49e7 slapi-nis: require 0.54.2 for 
CVE-2015-0283 fixes

master:
* 1b781b777f534b12a178202afa0982afd2d9c1dd slapi-nis: require 0.54.2 for 
CVE-2015-0283 fixes


I'm going to do the FreeIPA 4.1.4 release now.
--
Petr Vobornik

--
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 0021] show the exception message thrown by dogtag._parse_ca_status during install

2015-03-26 Thread Martin Basti 

On 25/03/15 15:15, Martin Basti wrote:

On 16/03/15 18:15, Martin Babinsky wrote:

https://fedorahosted.org/freeipa/ticket/4885




ACK

--
Martin Basti
This is the same patch as mbabinsk-0020, please ignore this thread as 
duplicated.


--
Martin Basti

-- 
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] Time-based account policies

2015-03-26 Thread Simo Sorce 
On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
 On 03/26/2015 04:26 PM, Jan Cholasta wrote:

[...]
  I don't see any point in storing time zone in the host object, if it's not 
  used
  for anything meaningful and has to be manually synchronized with the host's
  actual configured time zone.
 
 It would be mostly used for aiding the HBAC rule creation process, i.e. for 
 the
 UX. It would be optional. If you do not fill it, you would have to always
 select the right time zone in when setting the UTC HBAC time,
 
 If you fill the zone, UI could already select the right time zone for you.


It will only help to do mistakes, how does the host object get to know
what is the host's timezone ? And in any case you generally create HBAC
rules using groups of hosts, what is the UI gonna do ? Crawl all the
hosts in a group and then ? Average add the most common time zone ?

Drop it please :)

 Host's Local Time and UTC time are 2 different approaches how to set the time
 for the HBAC rule. With Local Time type, you would of course not have to deal
 with time zones. I thought this was already cleared out.

Sorry you confuse me, in which case do you need UTC ?
In case you want to set an absolute time  that doesn't change with DST ?


Simo.

-- 
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 04:30 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
 I think the timezone still may be with the host object but only as
 the UI
 helper as you suggest. Although I would maybe rather not see it
 with the object
 at all and have the admin just set the right timezone for the HBAC
 rule
 themselves. After all, if there's a collision of host helper
 timezones, I think
 admin would have to do that anyway.

 I don't see any point in storing time zone in the host object, if
 it's 
 not used for anything meaningful and has to be manually synchronized 
 with the host's actual configured time zone.
 
 +1
 The host *knows* it's local time zone, let's not set us up for sync
 issues.
 

 Right. But UI could then offer:

 Warning, time zone is ambiguous. Please select the right time zone:
 HostA time zone: Europe/Prague  [ ]
 HostB time zone: Europe/London  [ ]

 No, thanks. The whole point of Local Time is being able to use 
 whatever time zone is configured on each host instead of having to 
 specify one time zone for all of them, which is exactly what the above
 does.
 
 +1
 Local Time is a special name the stray out of the Olson database, you
 can see it as the wildcard '*' or 'ALL' in other rules and it means that
 the host will use its local time zone with the specified times of day
 and days of the week

See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.

I agree with you both if we are talking about Local Time rules. I was mostly
talking about UTC rules where the time zone is required to set the right UTC 
time.

-- 
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 04:39 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
 On 03/26/2015 04:26 PM, Jan Cholasta wrote:
 
 [...]
 I don't see any point in storing time zone in the host object, if it's not 
 used
 for anything meaningful and has to be manually synchronized with the host's
 actual configured time zone.

 It would be mostly used for aiding the HBAC rule creation process, i.e. for 
 the
 UX. It would be optional. If you do not fill it, you would have to always
 select the right time zone in when setting the UTC HBAC time,

 If you fill the zone, UI could already select the right time zone for you.
 
 
 It will only help to do mistakes, how does the host object get to know
 what is the host's timezone ? And in any case you generally create HBAC
 rules using groups of hosts, what is the UI gonna do ? Crawl all the
 hosts in a group and then ? Average add the most common time zone ?

Search hosts, gather all time zones and list them as choices or simply warn
that there are more time zones and Local Time based rule is preferred? :-)

 Drop it please :)

If there is no one interested in it, we can drop it. Such UX improvement can
also be added later, if there is a need.

 
 Host's Local Time and UTC time are 2 different approaches how to set the time
 for the HBAC rule. With Local Time type, you would of course not have to deal
 with time zones. I thought this was already cleared out.
 
 Sorry you confuse me, in which case do you need UTC ?
 In case you want to set an absolute time  that doesn't change with DST ?

I am confused as well. Wasn't it you who expressed the need to have 2 different
approaches for HBAC time rules - Local Time and fixed UTC time?

Reference:
http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html

-- 
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 0222] DNSSEC: do not log into files

2015-03-26 Thread Martin Basti 

We want to log DNSSEC daemons only into console (journald).

This patch also fixes unexpected log file in 
/var/lib/softhsm/.ipa/log/default.log


Patch attached.

--
Martin Basti

From 8e9b1e59490117b4d0dd4fb53850e0ec8e4f95d6 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Thu, 26 Mar 2015 13:33:20 +0100
Subject: [PATCH] DNSSEC: Do not log into files

We want to log DNSSEC daemons only into console (journald)

https://fedorahosted.org/freeipa/ticket/4657
---
 daemons/dnssec/ipa-dnskeysync-replica | 2 +-
 daemons/dnssec/ipa-dnskeysyncd| 2 +-
 daemons/dnssec/ipa-ods-exporter   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/daemons/dnssec/ipa-dnskeysync-replica b/daemons/dnssec/ipa-dnskeysync-replica
index d04f360e04ee018dcdd1ba9b2ca42b1844617af9..8a0ae8a9aedf128e85e1a666cdb25b7dfe23c475 100755
--- a/daemons/dnssec/ipa-dnskeysync-replica
+++ b/daemons/dnssec/ipa-dnskeysync-replica
@@ -130,7 +130,7 @@ def ldap2replica_zone_keys_sync(log, ldapkeydb, localhsm):
 
 
 # IPA framework initialization
-ipalib.api.bootstrap()
+ipalib.api.bootstrap(in_server=True, log=None)  # no logging to file
 ipalib.api.finalize()
 standard_logging_setup(verbose=True, debug = True)  # debug=ipalib.api.env.debug)
 log = root_logger
diff --git a/daemons/dnssec/ipa-dnskeysyncd b/daemons/dnssec/ipa-dnskeysyncd
index 54a08a1e6307e89b3f52e78bddbe28cda8ac1345..9191303438dd6419902a94b43043e46304c9c397 100755
--- a/daemons/dnssec/ipa-dnskeysyncd
+++ b/daemons/dnssec/ipa-dnskeysyncd
@@ -56,7 +56,7 @@ signal.signal(signal.SIGTERM, commenceShutdown)
 signal.signal(signal.SIGINT, commenceShutdown)
 
 # IPA framework initialization
-api.bootstrap()
+api.bootstrap(in_server=True, log=None)  # no logging to file
 api.finalize()
 standard_logging_setup(verbose=True, debug=api.env.debug)
 log = root_logger
diff --git a/daemons/dnssec/ipa-ods-exporter b/daemons/dnssec/ipa-ods-exporter
index 79570266d29abde1e6b31f84491736e4a1973c8b..fe4134ccd851cc0aa8611a4da5bba34ee4be1633 100755
--- a/daemons/dnssec/ipa-ods-exporter
+++ b/daemons/dnssec/ipa-ods-exporter
@@ -392,7 +392,7 @@ if len(sys.argv) != 1:
 sys.exit(1)
 
 # IPA framework initialization
-ipalib.api.bootstrap()
+ipalib.api.bootstrap(in_server=True, log=None)  # no logging to file
 ipalib.api.finalize()
 
 # Kerberos initialization
-- 
2.1.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

Re: [Freeipa-devel] Time-based account policies

2015-03-26 Thread Jan Cholasta 

Dne 26.3.2015 v 16:47 Martin Kosek napsal(a):

On 03/26/2015 04:39 PM, Simo Sorce wrote:

On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:

On 03/26/2015 04:26 PM, Jan Cholasta wrote:


[...]

I don't see any point in storing time zone in the host object, if it's not used
for anything meaningful and has to be manually synchronized with the host's
actual configured time zone.


It would be mostly used for aiding the HBAC rule creation process, i.e. for the
UX. It would be optional. If you do not fill it, you would have to always
select the right time zone in when setting the UTC HBAC time,

If you fill the zone, UI could already select the right time zone for you.



It will only help to do mistakes, how does the host object get to know
what is the host's timezone ? And in any case you generally create HBAC
rules using groups of hosts, what is the UI gonna do ? Crawl all the
hosts in a group and then ? Average add the most common time zone ?


Search hosts, gather all time zones and list them as choices or simply warn
that there are more time zones and Local Time based rule is preferred? :-)


Drop it please :)


If there is no one interested in it, we can drop it. Such UX improvement can
also be added later, if there is a need.


If we want to improve the UX by babysitting the administrator based on 
random guesses, we might as well add Clippy to IPA:


 __
/  \_
|  |   / \
@  @   | It looks|
|| ||  | like you|
|| ||   --| are setting |
|\_/|  | time zone   |
\___/  \_/


;-)

--
Jan Cholasta

--
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 04:26 PM, Jan Cholasta wrote:
 Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):
 On 03/26/2015 02:40 PM, Standa Láznička wrote:
 On 3/26/2015 1:24 PM, Martin Kosek wrote:
 On 03/26/2015 01:08 PM, Standa Láznička wrote:
 On 3/26/2015 11:13 AM, Jan Cholasta wrote:
 Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
 On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
 When using hbactest command you just need to supply implied time zone
 as an option to the command itself. After all, you are simulating rule
 execution so it does not matter where the value comes from.
 Oh, good, I haven't thought of that. That certainly eases things up.

 Let me make a summary then, a short one this time, of what's been
 discussed .

 It seems the best way to store time policies is indeed the format (time,
 anchor) where anchor is either Olson database timezone or Local Time
 for host local time. We are omitting users' local time because, after
 all, we are talking HBAC Rules here (great point by Simo). If the admins
 really needed that, there's a workaround Jan mentioned that should work
 just fine.
 What I originally meant as anchor was a value specifying the time offset
 (e.g. utc - access time uses UTC, rule - access time uses time zone
 specified in the HBAC rule, host - access time uses host's time zone),
 rather than the time zone itself or Local Time.

 You're right, that's probably more descriptive than just Local Time.
 Still, I
 think that instead of rule a timezone might just as well appear on the
 anchor
 part. I think UTC is also part of Olson's so it should be at the same
 spot as
 the timezone.
 
 Ah, right. OK then.
 
 I am not little confused about all the places where we want to add the time
 zone. I thought that it was originally meant for hosts objects, so that we 
 can
 HBAC rule is created, UI/CLI can already suggest the right time zone for 
 the
 HBAC rule. But it should have been only informative value serving mostly 
 UX,
 not something that SSSD would decide on.

 HBAC rule itself is always the authoritative source. We should also avoid
 having time zone in 2 places in the HBAC rule itself - if this is what you 
 are
 steering at. I thought the authoritative time zone would be only in the 
 HBAC
 time definition only, i.e. only in the anchor specifically.
 I think the timezone still may be with the host object but only as the UI
 helper as you suggest. Although I would maybe rather not see it with the 
 object
 at all and have the admin just set the right timezone for the HBAC rule
 themselves. After all, if there's a collision of host helper timezones, I 
 think
 admin would have to do that anyway.
 
 I don't see any point in storing time zone in the host object, if it's not 
 used
 for anything meaningful and has to be manually synchronized with the host's
 actual configured time zone.

It would be mostly used for aiding the HBAC rule creation process, i.e. for the
UX. It would be optional. If you do not fill it, you would have to always
select the right time zone in when setting the UTC HBAC time,

If you fill the zone, UI could already select the right time zone for you.

 Right. But UI could then offer:

 Warning, time zone is ambiguous. Please select the right time zone:
 HostA time zone: Europe/Prague  [ ]
 HostB time zone: Europe/London  [ ]
 
 No, thanks. The whole point of Local Time is being able to use whatever time
 zone is configured on each host instead of having to specify one time zone for
 all of them, which is exactly what the above does.

Host's Local Time and UTC time are 2 different approaches how to set the time
for the HBAC rule. With Local Time type, you would of course not have to deal
with time zones. I thought this was already cleared out.

 I agree that there should only be one timezone record for each HBAC and I
 wouldn't suggest differently. There was a confusion when Jan suggested to 
 use
 rule as anchor in the (time, anchor) tuple to get the rule's timezone 
 which,
 he suggested, should be stored elsewhere but in the tuple. I think there's 
 no
 harm having the timezone/host keyword stored with this tuple and therefore
 nowhere else.
 Can we show specific examples of these tuples, to make sure we are in
 agreement? My take was:

 (Mon-Fri 08:00-17:00, UTC+1)
 (Mon-Fri 08:00-17:00, local)

 UTC+1 may not be ideal as it would not work for daylight saving, a better 
 way
 would indeed be the Olson time zone ID, i.e:

 (Mon-Fri 08:00-17:00, Europe/Prague)
 (Mon-Fri 08:00-17:00, local)
 Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we 
 want to
 use Olson's database names. If I understand it right, UTC is in Olson's 
 and
 stands for UTC+0 offset. If not, we can have UTC keyword in the anchor 
 part
 of the tuple mentioned above to signalize just that (UTC+0).

 
 Can we please stop using the word anchor for time zone, rather than source 
 of
 time zone information as I originally suggested?
 

-- 
Manage your subscription for the

Re: [Freeipa-devel] Time-based account policies

2015-03-26 Thread Standa Láznička 


 On 26. 3. 2015, at 14:55, Martin Kosek mko...@redhat.com wrote:
 
 On 03/26/2015 02:40 PM, Standa Láznička wrote:
 On 3/26/2015 1:24 PM, Martin Kosek wrote:
 On 03/26/2015 01:08 PM, Standa Láznička wrote:
 On 3/26/2015 11:13 AM, Jan Cholasta wrote:
 Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
 On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
 When using hbactest command you just need to supply implied time zone
 as an option to the command itself. After all, you are simulating rule
 execution so it does not matter where the value comes from.
 Oh, good, I haven't thought of that. That certainly eases things up.
 
 Let me make a summary then, a short one this time, of what's been
 discussed .
 
 It seems the best way to store time policies is indeed the format (time,
 anchor) where anchor is either Olson database timezone or Local Time
 for host local time. We are omitting users' local time because, after
 all, we are talking HBAC Rules here (great point by Simo). If the admins
 really needed that, there's a workaround Jan mentioned that should work
 just fine.
 What I originally meant as anchor was a value specifying the time offset
 (e.g. utc - access time uses UTC, rule - access time uses time zone
 specified in the HBAC rule, host - access time uses host's time zone),
 rather than the time zone itself or Local Time.
 You're right, that's probably more descriptive than just Local Time. 
 Still, I
 think that instead of rule a timezone might just as well appear on the 
 anchor
 part. I think UTC is also part of Olson's so it should be at the same 
 spot as
 the timezone.
 I am not little confused about all the places where we want to add the time
 zone. I thought that it was originally meant for hosts objects, so that we 
 can
 HBAC rule is created, UI/CLI can already suggest the right time zone for the
 HBAC rule. But it should have been only informative value serving mostly UX,
 not something that SSSD would decide on.
 
 HBAC rule itself is always the authoritative source. We should also avoid
 having time zone in 2 places in the HBAC rule itself - if this is what you 
 are
 steering at. I thought the authoritative time zone would be only in the HBAC
 time definition only, i.e. only in the anchor specifically.
 I think the timezone still may be with the host object but only as the UI
 helper as you suggest. Although I would maybe rather not see it with the 
 object
 at all and have the admin just set the right timezone for the HBAC rule
 themselves. After all, if there's a collision of host helper timezones, I 
 think
 admin would have to do that anyway.
 
 Right. But UI could then offer:
 
 Warning, time zone is ambiguous. Please select the right time zone:
 HostA time zone: Europe/Prague  [ ]
 HostB time zone: Europe/London  [ ]
I see. An option to choose a different time zone than the hosts' might also 
come handy here but I see where you're going.
 
 I agree that there should only be one timezone record for each HBAC and I
 wouldn't suggest differently. There was a confusion when Jan suggested to use
 rule as anchor in the (time, anchor) tuple to get the rule's timezone 
 which,
 he suggested, should be stored elsewhere but in the tuple. I think there's no
 harm having the timezone/host keyword stored with this tuple and therefore
 nowhere else.
 Can we show specific examples of these tuples, to make sure we are in
 agreement? My take was:
 
 (Mon-Fri 08:00-17:00, UTC+1)
 (Mon-Fri 08:00-17:00, local)
 
 UTC+1 may not be ideal as it would not work for daylight saving, a better 
 way
 would indeed be the Olson time zone ID, i.e:
 
 (Mon-Fri 08:00-17:00, Europe/Prague)
 (Mon-Fri 08:00-17:00, local)
 Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we want 
 to
 use Olson's database names. If I understand it right, UTC is in Olson's and
 stands for UTC+0 offset. If not, we can have UTC keyword in the anchor part
 of the tuple mentioned above to signalize just that (UTC+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

Re: [Freeipa-devel] Time-based account policies

2015-03-26 Thread Simo Sorce 
On Thu, 2015-03-26 at 16:39 +0100, Martin Kosek wrote:
 On 03/26/2015 04:30 PM, Simo Sorce wrote:
  On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
  I think the timezone still may be with the host object but only as
  the UI
  helper as you suggest. Although I would maybe rather not see it
  with the object
  at all and have the admin just set the right timezone for the HBAC
  rule
  themselves. After all, if there's a collision of host helper
  timezones, I think
  admin would have to do that anyway.
 
  I don't see any point in storing time zone in the host object, if
  it's 
  not used for anything meaningful and has to be manually synchronized 
  with the host's actual configured time zone.
  
  +1
  The host *knows* it's local time zone, let's not set us up for sync
  issues.
  
 
  Right. But UI could then offer:
 
  Warning, time zone is ambiguous. Please select the right time zone:
  HostA time zone: Europe/Prague  [ ]
  HostB time zone: Europe/London  [ ]
 
  No, thanks. The whole point of Local Time is being able to use 
  whatever time zone is configured on each host instead of having to 
  specify one time zone for all of them, which is exactly what the above
  does.
  
  +1
  Local Time is a special name the stray out of the Olson database, you
  can see it as the wildcard '*' or 'ALL' in other rules and it means that
  the host will use its local time zone with the specified times of day
  and days of the week
 
 See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.
 
 I agree with you both if we are talking about Local Time rules. I was mostly
 talking about UTC rules where the time zone is required to set the right UTC 
 time.

Sorry, but if I understand what you are suggesting then I do not agree.
Either you use UTC based timezones *or* you use an Olson time zone. You
do *not* try to convert something like Europe/Prague to UTC as you would
change the meaning of the rule.

Simo.

-- 
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] Time-based account policies

2015-03-26 Thread Jan Cholasta 

Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):

On 03/26/2015 02:40 PM, Standa Láznička wrote:

On 3/26/2015 1:24 PM, Martin Kosek wrote:

On 03/26/2015 01:08 PM, Standa Láznička wrote:

On 3/26/2015 11:13 AM, Jan Cholasta wrote:

Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):

On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:

When using hbactest command you just need to supply implied time zone
as an option to the command itself. After all, you are simulating rule
execution so it does not matter where the value comes from.

Oh, good, I haven't thought of that. That certainly eases things up.

Let me make a summary then, a short one this time, of what's been
discussed .

It seems the best way to store time policies is indeed the format (time,
anchor) where anchor is either Olson database timezone or Local Time
for host local time. We are omitting users' local time because, after
all, we are talking HBAC Rules here (great point by Simo). If the admins
really needed that, there's a workaround Jan mentioned that should work
just fine.

What I originally meant as anchor was a value specifying the time offset
(e.g. utc - access time uses UTC, rule - access time uses time zone
specified in the HBAC rule, host - access time uses host's time zone),
rather than the time zone itself or Local Time.


You're right, that's probably more descriptive than just Local Time. Still, I
think that instead of rule a timezone might just as well appear on the anchor
part. I think UTC is also part of Olson's so it should be at the same spot as
the timezone.


Ah, right. OK then.


I am not little confused about all the places where we want to add the time
zone. I thought that it was originally meant for hosts objects, so that we can
HBAC rule is created, UI/CLI can already suggest the right time zone for the
HBAC rule. But it should have been only informative value serving mostly UX,
not something that SSSD would decide on.

HBAC rule itself is always the authoritative source. We should also avoid
having time zone in 2 places in the HBAC rule itself - if this is what you are
steering at. I thought the authoritative time zone would be only in the HBAC
time definition only, i.e. only in the anchor specifically.

I think the timezone still may be with the host object but only as the UI
helper as you suggest. Although I would maybe rather not see it with the object
at all and have the admin just set the right timezone for the HBAC rule
themselves. After all, if there's a collision of host helper timezones, I think
admin would have to do that anyway.


I don't see any point in storing time zone in the host object, if it's 
not used for anything meaningful and has to be manually synchronized 
with the host's actual configured time zone.




Right. But UI could then offer:

Warning, time zone is ambiguous. Please select the right time zone:
HostA time zone: Europe/Prague  [ ]
HostB time zone: Europe/London  [ ]


No, thanks. The whole point of Local Time is being able to use 
whatever time zone is configured on each host instead of having to 
specify one time zone for all of them, which is exactly what the above does.





I agree that there should only be one timezone record for each HBAC and I
wouldn't suggest differently. There was a confusion when Jan suggested to use
rule as anchor in the (time, anchor) tuple to get the rule's timezone which,
he suggested, should be stored elsewhere but in the tuple. I think there's no
harm having the timezone/host keyword stored with this tuple and therefore
nowhere else.

Can we show specific examples of these tuples, to make sure we are in
agreement? My take was:

(Mon-Fri 08:00-17:00, UTC+1)
(Mon-Fri 08:00-17:00, local)

UTC+1 may not be ideal as it would not work for daylight saving, a better way
would indeed be the Olson time zone ID, i.e:

(Mon-Fri 08:00-17:00, Europe/Prague)
(Mon-Fri 08:00-17:00, local)

Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we want to
use Olson's database names. If I understand it right, UTC is in Olson's and
stands for UTC+0 offset. If not, we can have UTC keyword in the anchor part
of the tuple mentioned above to signalize just that (UTC+0).




Can we please stop using the word anchor for time zone, rather than 
source of time zone information as I originally suggested?


--
Jan Cholasta

--
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] Time-based account policies

2015-03-26 Thread Martin Kosek 
On 03/26/2015 04:42 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:39 +0100, Martin Kosek wrote:
 On 03/26/2015 04:30 PM, Simo Sorce wrote:
 On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
 I think the timezone still may be with the host object but only as
 the UI
 helper as you suggest. Although I would maybe rather not see it
 with the object
 at all and have the admin just set the right timezone for the HBAC
 rule
 themselves. After all, if there's a collision of host helper
 timezones, I think
 admin would have to do that anyway.

 I don't see any point in storing time zone in the host object, if
 it's 
 not used for anything meaningful and has to be manually synchronized 
 with the host's actual configured time zone.

 +1
 The host *knows* it's local time zone, let's not set us up for sync
 issues.


 Right. But UI could then offer:

 Warning, time zone is ambiguous. Please select the right time zone:
 HostA time zone: Europe/Prague  [ ]
 HostB time zone: Europe/London  [ ]

 No, thanks. The whole point of Local Time is being able to use 
 whatever time zone is configured on each host instead of having to 
 specify one time zone for all of them, which is exactly what the above
 does.

 +1
 Local Time is a special name the stray out of the Olson database, you
 can see it as the wildcard '*' or 'ALL' in other rules and it means that
 the host will use its local time zone with the specified times of day
 and days of the week

 See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.

 I agree with you both if we are talking about Local Time rules. I was mostly
 talking about UTC rules where the time zone is required to set the right UTC 
 time.
 
 Sorry, but if I understand what you are suggesting then I do not agree.
 Either you use UTC based timezones *or* you use an Olson time zone. You
 do *not* try to convert something like Europe/Prague to UTC as you would
 change the meaning of the rule.

Ah, I think where the confusion is coming from. When I said UTC, I rather meant
time + Olson TZ, i.e. time rule that is the same across globe, unlike the Local
Time. Sorry.

I think this guy
(http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html)
injected the UTC as an alias for this method :-)

-- 
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