Proposed changes to the HBAC grammar

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

During a discussion today about how to represent the HBAC grammar in the
FreeIPA GUI, it became apparent that there was a limitation in the
grammar. Specifically, it's not possible to describe in a non-ambiguous
way "The first Wednesday of the month".

Right now, this would be described by:
accessTime: periodic monthly week 1 day 3 0800-1700

However, this literally means "Wednesdays that appear as the first week
on a wall calendar". Meaning that if the month began on a Thursday, this
rule would not fire this month. Thus it's not behaving in a way that
would be reasonably expected by a user.

After extended discussion, Simo, Ben and I discussed replacing this
week-of-the-month concept with a septet-of-the-month concept instead.

This would be described by:
accessTime: periodic monthly septet 1 day 3 0800-1700

and would literally translate as "The wednesday that exists within the
first septet of the month". The first septet being the range of day 1
through day 7, the second septet being day 8 through 14, and so forth.

We all feel that this would map closer to a user's expectation when
describing "the Nth Wednesday of the month", since it's a guarantee that
Wednesday will appear only once within a septet.

This will require two changes to the HBAC schema. First of all, we plan
to drop the week-of-the-month concept entirely and replace it with
septet-of-the-month. This is being done to eliminate the ambiguity
entirely. Secondly, we will need to describe day-of-the-septet in the
grammar (where the day of the septet describes the name of the weekday,
and not its numerical position within the septet, as that would be a
useless and complex duplication of the day-of-the-month concept).


In a related note, we also discussed how to handle describing activity
windows that cross the midnight boundary. It's my recommendation that we
should handle examples like the following by breaking them into two
separate accessTime attributes, one that describes the portion preceding
midnight and describes the set of days wherein the block starts, and a
second accessTime attribute that is offset by one day and describes the
portion taking place after midnight.

Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
becomes
accessTime: periodic weekly day 1-5 1700-2359
accessTime: periodic weekly day 2-6 0000-0159

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzkRAwACgkQeiVVYja6o6NtHwCgi3Vk2Q2aZXKIRHM3fbWOsLHE
> X6UAn3zECofcDzG1+gJClyUlDVZvKnmS
> =+zfc
> -----END PGP SIGNATURE-----

[Dmitri Pal]

Stephen Gallagher wrote:
>  During a discussion today about how to represent the HBAC grammar in
> the
>  FreeIPA GUI, it became apparent that there was a limitation in the
>  grammar. Specifically, it's not possible to describe in a non-ambiguous
>  way "The first Wednesday of the month".
>
>  Right now, this would be described by:
>  accessTime: periodic monthly week 1 day 3 0800-1700
>
>  However, this literally means "Wednesdays that appear as the first week
>  on a wall calendar". Meaning that if the month began on a Thursday, this
>  rule would not fire this month. Thus it's not behaving in a way that
>  would be reasonably expected by a user.
>
>  After extended discussion, Simo, Ben and I discussed replacing this
>  week-of-the-month concept with a septet-of-the-month concept instead.
>
>  This would be described by:
>  accessTime: periodic monthly septet 1 day 3 0800-1700
>
>  and would literally translate as "The wednesday that exists within the
>  first septet of the month". The first septet being the range of day 1
>  through day 7, the second septet being day 8 through 14, and so forth.
>
>  We all feel that this would map closer to a user's expectation when
>  describing "the Nth Wednesday of the month", since it's a guarantee that
>  Wednesday will appear only once within a septet.
>
>  This will require two changes to the HBAC schema. First of all, we plan
>  to drop the week-of-the-month concept entirely and replace it with
>  septet-of-the-month. This is being done to eliminate the ambiguity
>  entirely. Secondly, we will need to describe day-of-the-septet in the
>  grammar (where the day of the septet describes the name of the weekday,
>  and not its numerical position within the septet, as that would be a
>  useless and complex duplication of the day-of-the-month concept).
>
>
>  In a related note, we also discussed how to handle describing activity
>  windows that cross the midnight boundary. It's my recommendation that we
>  should handle examples like the following by breaking them into two
>  separate accessTime attributes, one that describes the portion preceding
>  midnight and describes the set of days wherein the block starts, and a
>  second accessTime attribute that is offset by one day and describes the
>  portion taking place after midnight.
>
>  Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
>  becomes
>  accessTime: periodic weekly day 1-5 1700-2359
>  accessTime: periodic weekly day 2-6 0000-0159
>  
I agree with the proposal the only issue I see is the issue of the time
zone of the user. When the user schedules the window it should be clear
what time zone he is using. If we in v2 use UTC for all I am fine but if
we allow user to enter window in the local time to his machine and then
rely on the client UI/CLI to convert it to UTC we can face a problem of
the local time window not crossing midnight while the  UTC window will
cross the boundary. We need to define how this case will be handled and
how we interpret the input.

Please add the clarification about this.

_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Freeipa-devel] Proposed changes to the HBAC grammar

[Endi Sukma Dewata]

On 11/17/2010 3:21 PM, Dmitri Pal wrote:
> > In a related note, we also discussed how to handle describing
> activity
> > windows that cross the midnight boundary. It's my recommendation that we
> > should handle examples like the following by breaking them into two
> > separate accessTime attributes, one that describes the portion preceding
> > midnight and describes the set of days wherein the block starts, and a
> > second accessTime attribute that is offset by one day and describes the
> > portion taking place after midnight.
> >
> > Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
> > becomes
> > accessTime: periodic weekly day 1-5 1700-2359
> > accessTime: periodic weekly day 2-6 0000-0159
>
>  I agree with the proposal the only issue I see is the issue of the time
>  zone of the user. When the user schedules the window it should be clear
>  what time zone he is using. If we in v2 use UTC for all I am fine but if
>  we allow user to enter window in the local time to his machine and then
>  rely on the client UI/CLI to convert it to UTC we can face a problem of
>  the local time window not crossing midnight while the  UTC window will
>  cross the boundary. We need to define how this case will be handled and
>  how we interpret the input. 
Will the user need to be aware of this issue? In other words, will the 
UI enforce the user to split a schedule that crosses midnight manually?

If yes, there are some issues:

1. Some schedules that have to be split because of local time zone can 
actually be merged in UTC. In that case do we want to merge it or keep 
them separate? For example:
    - Original: 2100-0159 local (UTC-3)
    - Entered in UI: 2100-2359 and 0000-0159 local
    - Stored on server:
      a) keep the split schedules: 0000-0259 and 0300-0459 UTC
      b) merge it: 0000-0359 UTC

2. Some schedules that have to be split because of local time zone may 
need to be split differently in UTC. Will this confuse users? For example:
    - Original: 2100-0159 local (UTC-2)
    - Entered in UI: 2100-2359 and 0000-0159 local
    - Stored on server:
      a) split the first part: 2300-2359, 0000-0159, and 0200-0359 UTC
      b) merge if possible: 2300-2359 and 0000-0359 UTC

Alternatively, the splitting issue can be hidden by the UI, but UI and 
CLI will be inconsistent.

-- 
Endi S. Dewata

[Freeipa-devel] Proposed changes to the HBAC grammar

[Endi Sukma Dewata]

On 11/17/2010 5:24 PM, Endi Sukma Dewata wrote:
>  Will the user need to be aware of this issue? In other words, will
> the
>  UI enforce the user to split a schedule that crosses midnight manually?
>
>  If yes, there are some issues:
>
>  1. Some schedules that have to be split because of local time zone can
>  actually be merged in UTC. In that case do we want to merge it or keep
>  them separate? For example:
>  - Original: 2100-0159 local (UTC-3)
>  - Entered in UI: 2100-2359 and 0000-0159 local
>  - Stored on server:
>  a) keep the split schedules: 0000-0259 and 0300-0459 UTC
>  b) merge it: 0000-0359 UTC
>
>  2. Some schedules that have to be split because of local time zone may
>  need to be split differently in UTC. Will this confuse users? For example:
>  - Original: 2100-0159 local (UTC-2)
>  - Entered in UI: 2100-2359 and 0000-0159 local
>  - Stored on server:
>  a) split the first part: 2300-2359, 0000-0159, and 0200-0359 UTC
>  b) merge if possible: 2300-2359 and 0000-0359 UTC
>
>  Alternatively, the splitting issue can be hidden by the UI, but UI and
>  CLI will be inconsistent.
>  
Also, when viewing an existing schedule, the UTC schedule may not fit 
the UI for the local time zone, requiring a split too.

-- 
Endi S. Dewata

[Freeipa-devel] Proposed changes to the HBAC grammar

[Dmitri Pal]

Endi Sukma Dewata wrote:
>  On 11/17/2010 3:21 PM, Dmitri Pal wrote:
> >> In a related note, we also discussed how to handle describing activity
> >> windows that cross the midnight boundary. It's my recommendation
> >> that we
> >> should handle examples like the following by breaking them into two
> >> separate accessTime attributes, one that describes the portion
> >> preceding
> >> midnight and describes the set of days wherein the block starts, and a
> >> second accessTime attribute that is offset by one day and describes the
> >> portion taking place after midnight.
> >>
> >> Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
> >> becomes
> >> accessTime: periodic weekly day 1-5 1700-2359
> >> accessTime: periodic weekly day 2-6 0000-0159
> >
> > I agree with the proposal the only issue I see is the issue of the time
> > zone of the user. When the user schedules the window it should be clear
> > what time zone he is using. If we in v2 use UTC for all I am fine but if
> > we allow user to enter window in the local time to his machine and then
> > rely on the client UI/CLI to convert it to UTC we can face a problem of
> > the local time window not crossing midnight while the  UTC window will
> > cross the boundary. We need to define how this case will be handled and
> > how we interpret the input.
>
>  Will the user need to be aware of this issue? In other words, will the
>  UI enforce the user to split a schedule that crosses midnight manually?
>
>  If yes, there are some issues:
>
>  1. Some schedules that have to be split because of local time zone can
>  actually be merged in UTC. In that case do we want to merge it or keep
>  them separate? For example:
>     - Original: 2100-0159 local (UTC-3)
>     - Entered in UI: 2100-2359 and 0000-0159 local
>     - Stored on server:
>       a) keep the split schedules: 0000-0259 and 0300-0459 UTC
>       b) merge it: 0000-0359 UTC
>
>  2. Some schedules that have to be split because of local time zone may
>  need to be split differently in UTC. Will this confuse users? For
>  example:
>     - Original: 2100-0159 local (UTC-2)
>     - Entered in UI: 2100-2359 and 0000-0159 local
>     - Stored on server:
>       a) split the first part: 2300-2359, 0000-0159, and 0200-0359 UTC
>       b) merge if possible: 2300-2359 and 0000-0359 UTC
>
>  Alternatively, the splitting issue can be hidden by the UI, but UI and
>  CLI will be inconsistent.
>  
Yes. This is exactly the problem I am concerned about.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Sumit Bose]

On Wed, Nov 17, 2010 at 04:07:24PM -0500, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  During a discussion today about how to represent the HBAC grammar in the
>  FreeIPA GUI, it became apparent that there was a limitation in the
>  grammar. Specifically, it's not possible to describe in a non-ambiguous
>  way "The first Wednesday of the month".
>  
>  Right now, this would be described by:
>  accessTime: periodic monthly week 1 day 3 0800-1700
>  
>  However, this literally means "Wednesdays that appear as the first week
>  on a wall calendar". Meaning that if the month began on a Thursday, this
>  rule would not fire this month. Thus it's not behaving in a way that
>  would be reasonably expected by a user.
>  
>  After extended discussion, Simo, Ben and I discussed replacing this
>  week-of-the-month concept with a septet-of-the-month concept instead.
>  
>  This would be described by:
>  accessTime: periodic monthly septet 1 day 3 0800-1700
>  
>  and would literally translate as "The wednesday that exists within the
>  first septet of the month". The first septet being the range of day 1
>  through day 7, the second septet being day 8 through 14, and so forth. 
I would like to suggest to allow negative numbers to cover 'the last
Wednesdays of the month'.

bye,
Sumit

>  
>  We all feel that this would map closer to a user's expectation when
>  describing "the Nth Wednesday of the month", since it's a guarantee that
>  Wednesday will appear only once within a septet.
>  
>  This will require two changes to the HBAC schema. First of all, we plan
>  to drop the week-of-the-month concept entirely and replace it with
>  septet-of-the-month. This is being done to eliminate the ambiguity
>  entirely. Secondly, we will need to describe day-of-the-septet in the
>  grammar (where the day of the septet describes the name of the weekday,
>  and not its numerical position within the septet, as that would be a
>  useless and complex duplication of the day-of-the-month concept).
>  
>  
>  In a related note, we also discussed how to handle describing activity
>  windows that cross the midnight boundary. It's my recommendation that we
>  should handle examples like the following by breaking them into two
>  separate accessTime attributes, one that describes the portion preceding
>  midnight and describes the set of days wherein the block starts, and a
>  second accessTime attribute that is offset by one day and describes the
>  portion taking place after midnight.
>  
>  Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning
>  becomes
>  accessTime: periodic weekly day 1-5 1700-2359
>  accessTime: periodic weekly day 2-6 0000-0159
>  
>  - -- 
>  Stephen Gallagher
>  RHCE 804006346421761
>  
>  Delivering value year after year.
>  Red Hat ranks #1 in value among software vendors.
>  http://www.redhat.com/promo/vendor/
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.11 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> >  
> >  iEYEARECAAYFAkzkRAwACgkQeiVVYja6o6NtHwCgi3Vk2Q2aZXKIRHM3fbWOsLHE
> >  X6UAn3zECofcDzG1+gJClyUlDVZvKnmS
> >  =+zfc
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/17/2010 04:48 PM, Sumit Bose wrote:
>  On Wed, Nov 17, 2010 at 04:07:24PM -0500, Stephen Gallagher wrote:
>  After extended discussion, Simo, Ben and I discussed replacing this
>  week-of-the-month concept with a septet-of-the-month concept instead.
>  
>  This would be described by:
>  accessTime: periodic monthly septet 1 day 3 0800-1700
>  
>  and would literally translate as "The wednesday that exists within the
>  first septet of the month". The first septet being the range of day 1
>  through day 7, the second septet being day 8 through 14, and so forth.
>  
> > I would like to suggest to allow negative numbers to cover 'the last
> > Wednesdays of the month'.
>   
Doing the forward septets is easy (1*x..7*x), but the reverse septets
are more complicated (since they would be (y-1*x..y-7*x), where y is the
total number of days in the month (which also has to account for leap
years).

I think it might be a nice enhancement, but I recommend that we not
include it right now, given the tight release schedule for FreeIPA v2.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzlGjAACgkQeiVVYja6o6PLxQCfW4OakzaQH+OPtlD4kOsyh7BN
> voMAn1G+dMWRTx5jwxL1yu5lkbuWX+Qz
> =ZDmw
> -----END PGP SIGNATURE-----

[Freeipa-devel] Proposed changes to the HBAC grammar

[Simo Sorce]

On Thu, 18 Nov 2010 07:21:04 -0500
Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

>  Doing the forward septets is easy (1*x..7*x), but the reverse
> septets
>  are more complicated (since they would be (y-1*x..y-7*x), where y is
>  the total number of days in the month (which also has to account for
>  leap years).
>  
>  I think it might be a nice enhancement, but I recommend that we not
>  include it right now, given the tight release schedule for FreeIPA v2. 
As I said before it is a now or never condition.
If you do not put it in now, then when you put it in, old clients will
not understand the rule. And they will have only one option, always
deny access, because they have no way to understand when it is ok to
allow/deny it.

Simo.

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

[Freeipa-devel] Proposed changes to the HBAC grammar

[Dmitri Pal]

Simo Sorce wrote:
>  On Thu, 18 Nov 2010 07:21:04 -0500
>  Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>
>    
> > Doing the forward septets is easy (1*x..7*x), but the reverse septets
> > are more complicated (since they would be (y-1*x..y-7*x), where y is
> > the total number of days in the month (which also has to account for
> > leap years).
> >
> > I think it might be a nice enhancement, but I recommend that we not
> > include it right now, given the tight release schedule for FreeIPA v2.
> >     
>
>  As I said before it is a now or never condition.
>  If you do not put it in now, then when you put it in, old clients will
>  not understand the rule. And they will have only one option, always
>  deny access, because they have no way to understand when it is ok to
>  allow/deny it.
>
>  Simo.
>
>     
What about just using the cron spec then with the addition of the duration?
And completely abandon our grammar for the periodic part (I know it is a
lot of work and start over again but if we have one shot wouldn't it be
best to use something existing?)
Will that work?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Freeipa-devel] Proposed changes to the HBAC grammar

[Simo Sorce]

On Thu, 18 Nov 2010 08:37:32 -0500
Dmitri Pal <dpal(a)redhat.com&gt; wrote:

>  Simo Sorce wrote:
>  > On Thu, 18 Nov 2010 07:21:04 -0500
>  > Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  >
>  >   
>  >> Doing the forward septets is easy (1*x..7*x), but the reverse
>  >> septets are more complicated (since they would be (y-1*x..y-7*x),
>  >> where y is the total number of days in the month (which also has
>  >> to account for leap years).
>  >>
>  >> I think it might be a nice enhancement, but I recommend that we not
>  >> include it right now, given the tight release schedule for FreeIPA
>  >> v2. 
>  >
>  > As I said before it is a now or never condition.
>  > If you do not put it in now, then when you put it in, old clients
>  > will not understand the rule. And they will have only one option,
>  > always deny access, because they have no way to understand when it
>  > is ok to allow/deny it.
>  >
>  > Simo.
>  >
>  >   
>  What about just using the cron spec then with the addition of the
>  duration? And completely abandon our grammar for the periodic part (I
>  know it is a lot of work and start over again but if we have one shot
>  wouldn't it be best to use something existing?)
>  Will that work? 
The Cron grammar is very ugly and can't do many of the things we need
anyway.
The problems we have with the current grammar are minor, and can be
easily solved.
We have done 98% of the work, I wouldn't throw it all away just becaue
we need to fix the remaining 2%

Simo.

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