[PATCH] SELinux user maps: pick just one map

[Jan Zelený]

This patch modifies behavior of SSSD when putting together content of
user config file for pam_selinux. SSSD will now pick only the first user map in
the priority list which matches to the user logging in. Other maps are
ignored.

https://fedorahosted.org/sssd/ticket/1360

Rob, please confirm that this is the right and expected behavior.

Thanks
Jan

[Rob Crittenden]

Jan Zelený wrote:
>  This patch modifies behavior of SSSD when putting together content
> of
>  user config file for pam_selinux. SSSD will now pick only the first user map in
>  the priority list which matches to the user logging in. Other maps are
>  ignored.
>
>  https://fedorahosted.org/sssd/ticket/1360
>
>  Rob, please confirm that this is the right and expected behavior.
>
>  Thanks
>  Jan 
What you have described sounds right. I don't have enough context in 
sssd to know whether this patch will achieve that.

rob

[Jan Zelený]

Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  Jan Zelený wrote:
>  > This patch modifies behavior of SSSD when putting together content of
>  > user config file for pam_selinux. SSSD will now pick only the first user
>  > map in the priority list which matches to the user logging in. Other maps
>  > are ignored.
>  > 
>  > https://fedorahosted.org/sssd/ticket/1360
>  > 
>  > Rob, please confirm that this is the right and expected behavior.
>  > 
>  > Thanks
>  > Jan
>  
>  What you have described sounds right. I don't have enough context in
>  sssd to know whether this patch will achieve that. 
I realize that. I just wanted to verify that the described behavior is 
correct. The patch itself will be reviewed by someone else from SSSD team.

Thank you for the confirmation


Jan

[Jan Zelený]

Dne pátek 22 června 2012 15:27:14, Jan Zelený napsal(a):
>  Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  > Jan Zelený wrote:
>  > > This patch modifies behavior of SSSD when putting together content of
>  > > user config file for pam_selinux. SSSD will now pick only the first user
>  > > map in the priority list which matches to the user logging in. Other
>  > > maps
>  > > are ignored.
>  > > 
>  > > https://fedorahosted.org/sssd/ticket/1360
>  > > 
>  > > Rob, please confirm that this is the right and expected behavior.
>  > > 
>  > > Thanks
>  > > Jan
>  > 
>  > What you have described sounds right. I don't have enough context in
>  > sssd to know whether this patch will achieve that.
>  
>  I realize that. I just wanted to verify that the described behavior is
>  correct. The patch itself will be reviewed by someone else from SSSD team.
>  
>  Thank you for the confirmation 
Self-NACK after a discussion on IRC.

The problem with this patch is that user will receive only the lowest 
permissions possible because of the order of SELinux user priority list stored 
on IPA server. We want it exactly the other way.

Another patch coming soon.

Thanks
Jan

[Rob Crittenden]

Jan Zelený wrote:
>  Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
> > Jan Zelený wrote:
> >> This patch modifies behavior of SSSD when putting together content of
> >> user config file for pam_selinux. SSSD will now pick only the first user
> >> map in the priority list which matches to the user logging in. Other maps
> >> are ignored.
> >>
> >> https://fedorahosted.org/sssd/ticket/1360
> >>
> >> Rob, please confirm that this is the right and expected behavior.
> >>
> >> Thanks
> >> Jan
> >
> > What you have described sounds right. I don't have enough context in
> > sssd to know whether this patch will achieve that.
>
>  I realize that. I just wanted to verify that the described behavior is
>  correct. The patch itself will be reviewed by someone else from SSSD team.
>
>  Thank you for the confirmation 
We had a discussion in IRC and it seems that the using of the usermap 
order is incorrect. The list is ordered from least to most permissive 
(xguest ... unconfined).

We want to assign the most permissive context available. So if several 
rules evaluate the same except for context we need to refer to the 
ordered list and pick the most permissive one.

rob

[Jan Zelený]

Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  Jan Zelený wrote:
>  > Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  >> Jan Zelený wrote:
>  >>> This patch modifies behavior of SSSD when putting together content of
>  >>> user config file for pam_selinux. SSSD will now pick only the first user
>  >>> map in the priority list which matches to the user logging in. Other
>  >>> maps
>  >>> are ignored.
>  >>> 
>  >>> https://fedorahosted.org/sssd/ticket/1360
>  >>> 
>  >>> Rob, please confirm that this is the right and expected behavior.
>  >>> 
>  >>> Thanks
>  >>> Jan
>  >> 
>  >> What you have described sounds right. I don't have enough context in
>  >> sssd to know whether this patch will achieve that.
>  > 
>  > I realize that. I just wanted to verify that the described behavior is
>  > correct. The patch itself will be reviewed by someone else from SSSD team.
>  > 
>  > Thank you for the confirmation
>  
>  We had a discussion in IRC and it seems that the using of the usermap
>  order is incorrect. The list is ordered from least to most permissive
>  (xguest ... unconfined).
>  
>  We want to assign the most permissive context available. So if several
>  rules evaluate the same except for context we need to refer to the
>  ordered list and pick the most permissive one. 
Following patch selects the right record with respect to ascending order of 
permission levels.

Thanks
Jan

[Stephen Gallagher]

On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  > Jan Zelený wrote:
>  > > Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  > >> Jan Zelený wrote:
>  > >>> This patch modifies behavior of SSSD when putting together content of
>  > >>> user config file for pam_selinux. SSSD will now pick only the first
> user
>  > >>> map in the priority list which matches to the user logging in. Other
>  > >>> maps
>  > >>> are ignored.
>  > >>> 
>  > >>> https://fedorahosted.org/sssd/ticket/1360
>  > >>> 
>  > >>> Rob, please confirm that this is the right and expected behavior.
>  > >>> 
>  > >>> Thanks
>  > >>> Jan
>  > >> 
>  > >> What you have described sounds right. I don't have enough context in
>  > >> sssd to know whether this patch will achieve that.
>  > > 
>  > > I realize that. I just wanted to verify that the described behavior is
>  > > correct. The patch itself will be reviewed by someone else from SSSD team.
>  > > 
>  > > Thank you for the confirmation
>  > 
>  > We had a discussion in IRC and it seems that the using of the usermap
>  > order is incorrect. The list is ordered from least to most permissive
>  > (xguest ... unconfined).
>  > 
>  > We want to assign the most permissive context available. So if several
>  > rules evaluate the same except for context we need to refer to the
>  > ordered list and pick the most permissive one.
>  
>  Following patch selects the right record with respect to ascending order of 
>  permission levels. 

Ack

[Stephen Gallagher]

On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  > Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  > > Jan Zelený wrote:
>  > > > Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  > > >> Jan Zelený wrote:
>  > > >>> This patch modifies behavior of SSSD when putting together content
> of
>  > > >>> user config file for pam_selinux. SSSD will now pick only the
> first user
>  > > >>> map in the priority list which matches to the user logging in.
> Other
>  > > >>> maps
>  > > >>> are ignored.
>  > > >>> 
>  > > >>> https://fedorahosted.org/sssd/ticket/1360
>  > > >>> 
>  > > >>> Rob, please confirm that this is the right and expected behavior.
>  > > >>> 
>  > > >>> Thanks
>  > > >>> Jan
>  > > >> 
>  > > >> What you have described sounds right. I don't have enough context
> in
>  > > >> sssd to know whether this patch will achieve that.
>  > > > 
>  > > > I realize that. I just wanted to verify that the described behavior is
>  > > > correct. The patch itself will be reviewed by someone else from SSSD
> team.
>  > > > 
>  > > > Thank you for the confirmation
>  > > 
>  > > We had a discussion in IRC and it seems that the using of the usermap
>  > > order is incorrect. The list is ordered from least to most permissive
>  > > (xguest ... unconfined).
>  > > 
>  > > We want to assign the most permissive context available. So if several
>  > > rules evaluate the same except for context we need to refer to the
>  > > ordered list and pick the most permissive one.
>  > 
>  > Following patch selects the right record with respect to ascending order of 
>  > permission levels.
>  
>  
>  Ack 
Pushed to master.

[Rob Crittenden]

Stephen Gallagher wrote:
>  On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
> > On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
> >> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
> >>> Jan Zelený wrote:
> >>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
> >>>>> Jan Zelený wrote:
> >>>>>> This patch modifies behavior of SSSD when putting together
> content of
> >>>>>> user config file for pam_selinux. SSSD will now pick only the
> first user
> >>>>>> map in the priority list which matches to the user logging in.
> Other
> >>>>>> maps
> >>>>>> are ignored.
> >>>>>>
> >>>>>> https://fedorahosted.org/sssd/ticket/1360
> >>>>>>
> >>>>>> Rob, please confirm that this is the right and expected
> behavior.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Jan
> >>>>>
> >>>>> What you have described sounds right. I don't have enough context
> in
> >>>>> sssd to know whether this patch will achieve that.
> >>>>
> >>>> I realize that. I just wanted to verify that the described behavior is
> >>>> correct. The patch itself will be reviewed by someone else from SSSD
> team.
> >>>>
> >>>> Thank you for the confirmation
> >>>
> >>> We had a discussion in IRC and it seems that the using of the usermap
> >>> order is incorrect. The list is ordered from least to most permissive
> >>> (xguest ... unconfined).
> >>>
> >>> We want to assign the most permissive context available. So if several
> >>> rules evaluate the same except for context we need to refer to the
> >>> ordered list and pick the most permissive one.
> >>
> >> Following patch selects the right record with respect to ascending order of
> >> permission levels.
> >
> >
> > Ack
>
>  Pushed to master. 
Maps are still not working properly.

It now always selects the highest priority that a user is associated 
with. This is incorrect. It needs to go through an HBAC-style evaluation 
where the specificity of the user (vs usercat=all) and the host are 
taken into consideration.

So for example these three rules:

   Rule name: test_all
   SELinux User: unconfined_u:s0-s0:c0.c1023
   User category: all
   Host category: all
   Enabled: TRUE

   Rule name: test_tuser1_pinto
   SELinux User: staff_u:s0-s0:c0.c1023
   Enabled: TRUE
   Users: tuser1
   Hosts: pinto.greyoak.com

   Rule name: test_user
   SELinux User: user_u:s0-s0:c0.c1023
   Host category: all
   Enabled: TRUE
   Users: tuser1

If I log into pinto as tuser1 I get assigned unconfined_u. It should be 
staff_u because that rule is more specific than test_all. The only time 
the context ordering should be considered is when there are two rules 
that match with the same specificity.

rob

[Jan Zelený]

Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>  Stephen Gallagher wrote:
>  > On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  >> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  >>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  >>>> Jan Zelený wrote:
>  >>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  >>>>>> Jan Zelený wrote:
>  >>>>>>> This patch modifies behavior of SSSD when putting together
> content
>  >>>>>>> of
>  >>>>>>> user config file for pam_selinux. SSSD will now pick only
> the first
>  >>>>>>> user
>  >>>>>>> map in the priority list which matches to the user logging
> in. Other
>  >>>>>>> maps
>  >>>>>>> are ignored.
>  >>>>>>> 
>  >>>>>>> https://fedorahosted.org/sssd/ticket/1360
>  >>>>>>> 
>  >>>>>>> Rob, please confirm that this is the right and expected
> behavior.
>  >>>>>>> 
>  >>>>>>> Thanks
>  >>>>>>> Jan
>  >>>>>> 
>  >>>>>> What you have described sounds right. I don't have enough
> context in
>  >>>>>> sssd to know whether this patch will achieve that.
>  >>>>> 
>  >>>>> I realize that. I just wanted to verify that the described behavior
> is
>  >>>>> correct. The patch itself will be reviewed by someone else from
> SSSD
>  >>>>> team.
>  >>>>> 
>  >>>>> Thank you for the confirmation
>  >>>> 
>  >>>> We had a discussion in IRC and it seems that the using of the usermap
>  >>>> order is incorrect. The list is ordered from least to most permissive
>  >>>> (xguest ... unconfined).
>  >>>> 
>  >>>> We want to assign the most permissive context available. So if several
>  >>>> rules evaluate the same except for context we need to refer to the
>  >>>> ordered list and pick the most permissive one.
>  >>> 
>  >>> Following patch selects the right record with respect to ascending order
>  >>> of
>  >>> permission levels.
>  >> 
>  >> Ack
>  > 
>  > Pushed to master.
>  
>  Maps are still not working properly.
>  
>  It now always selects the highest priority that a user is associated
>  with. This is incorrect. It needs to go through an HBAC-style evaluation
>  where the specificity of the user (vs usercat=all) and the host are
>  taken into consideration.
>  
>  So for example these three rules:
>  
>     Rule name: test_all
>     SELinux User: unconfined_u:s0-s0:c0.c1023
>     User category: all
>     Host category: all
>     Enabled: TRUE
>  
>     Rule name: test_tuser1_pinto
>     SELinux User: staff_u:s0-s0:c0.c1023
>     Enabled: TRUE
>     Users: tuser1
>     Hosts: pinto.greyoak.com
>  
>     Rule name: test_user
>     SELinux User: user_u:s0-s0:c0.c1023
>     Host category: all
>     Enabled: TRUE
>     Users: tuser1
>  
>  If I log into pinto as tuser1 I get assigned unconfined_u. It should be
>  staff_u because that rule is more specific than test_all. The only time
>  the context ordering should be considered is when there are two rules
>  that match with the same specificity. 
I'm sorry but I think this is a design decision that should have been made 
clear in the design phase. I looked at both documents I was building my design 
on to be sure and I can't find any reference to your approach. Could you give 
me any pointer to a place where it has been described? Or is the specification 
you just provided complete?

Also this is not some minor change, this might require implementation of some 
decision making logic into NSS responder. I'd like to do a triage first to 
figure out when do we want to do this / what priority does this task have.


Thanks
Jan

[Stephen Gallagher]

On Tue, 2012-06-26 at 08:37 +0200, Jan Zelený wrote:
>  Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>  > Stephen Gallagher wrote:
>  > > On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  > >> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  > >>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  > >>>> Jan Zelený wrote:
>  > >>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
>  > >>>>>> Jan Zelený wrote:
>  > >>>>>>> This patch modifies behavior of SSSD when putting
> together content
>  > >>>>>>> of
>  > >>>>>>> user config file for pam_selinux. SSSD will now pick
> only the first
>  > >>>>>>> user
>  > >>>>>>> map in the priority list which matches to the user
> logging in. Other
>  > >>>>>>> maps
>  > >>>>>>> are ignored.
>  > >>>>>>> 
>  > >>>>>>> https://fedorahosted.org/sssd/ticket/1360
>  > >>>>>>> 
>  > >>>>>>> Rob, please confirm that this is the right and expected
> behavior.
>  > >>>>>>> 
>  > >>>>>>> Thanks
>  > >>>>>>> Jan
>  > >>>>>> 
>  > >>>>>> What you have described sounds right. I don't have
> enough context in
>  > >>>>>> sssd to know whether this patch will achieve that.
>  > >>>>> 
>  > >>>>> I realize that. I just wanted to verify that the described
> behavior is
>  > >>>>> correct. The patch itself will be reviewed by someone else from
> SSSD
>  > >>>>> team.
>  > >>>>> 
>  > >>>>> Thank you for the confirmation
>  > >>>> 
>  > >>>> We had a discussion in IRC and it seems that the using of the
> usermap
>  > >>>> order is incorrect. The list is ordered from least to most
> permissive
>  > >>>> (xguest ... unconfined).
>  > >>>> 
>  > >>>> We want to assign the most permissive context available. So if
> several
>  > >>>> rules evaluate the same except for context we need to refer to the
>  > >>>> ordered list and pick the most permissive one.
>  > >>> 
>  > >>> Following patch selects the right record with respect to ascending
> order
>  > >>> of
>  > >>> permission levels.
>  > >> 
>  > >> Ack
>  > > 
>  > > Pushed to master.
>  > 
>  > Maps are still not working properly.
>  > 
>  > It now always selects the highest priority that a user is associated
>  > with. This is incorrect. It needs to go through an HBAC-style evaluation
>  > where the specificity of the user (vs usercat=all) and the host are
>  > taken into consideration.
>  > 
>  > So for example these three rules:
>  > 
>  >    Rule name: test_all
>  >    SELinux User: unconfined_u:s0-s0:c0.c1023
>  >    User category: all
>  >    Host category: all
>  >    Enabled: TRUE
>  > 
>  >    Rule name: test_tuser1_pinto
>  >    SELinux User: staff_u:s0-s0:c0.c1023
>  >    Enabled: TRUE
>  >    Users: tuser1
>  >    Hosts: pinto.greyoak.com
>  > 
>  >    Rule name: test_user
>  >    SELinux User: user_u:s0-s0:c0.c1023
>  >    Host category: all
>  >    Enabled: TRUE
>  >    Users: tuser1
>  > 
>  > If I log into pinto as tuser1 I get assigned unconfined_u. It should be
>  > staff_u because that rule is more specific than test_all. The only time
>  > the context ordering should be considered is when there are two rules
>  > that match with the same specificity.
>  
>  I'm sorry but I think this is a design decision that should have been made 
>  clear in the design phase. I looked at both documents I was building my design 
>  on to be sure and I can't find any reference to your approach. Could you give 
>  me any pointer to a place where it has been described? Or is the specification 
>  you just provided complete?
>  
>  Also this is not some minor change, this might require implementation of some 
>  decision making logic into NSS responder. I'd like to do a triage first to 
>  figure out when do we want to do this / what priority does this task have. 
I agree with Jan here. Our original design instructions were to find a
match, and if more than one matches, use the priority to break the tie.
Specificity is a *very* difficult concept to implement, especially where
groups are involved. (e.g. suppose the SELinux rule is users in groupA
get one role assigned, users in groupB get a different role assigned,
but groupB is a nested group below groupA).

This is a brand-new feature that should have a separate RFE filed. We
need a new, complete design documentation describing the methods for
determining specificity.

[Simo Sorce]

On Tue, 2012-06-26 at 07:23 -0400, Stephen Gallagher wrote:
>  On Tue, 2012-06-26 at 08:37 +0200, Jan Zelený wrote:
>  > Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>  > > Stephen Gallagher wrote:
>  > > > On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  > > >> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  > > >>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  > > >>>> Jan Zelený wrote:
>  > > >>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden
> napsal(a):
>  > > >>>>>> Jan Zelený wrote:
>  > > >>>>>>> This patch modifies behavior of SSSD when putting
> together content
>  > > >>>>>>> of
>  > > >>>>>>> user config file for pam_selinux. SSSD will now
> pick only the first
>  > > >>>>>>> user
>  > > >>>>>>> map in the priority list which matches to the user
> logging in. Other
>  > > >>>>>>> maps
>  > > >>>>>>> are ignored.
>  > > >>>>>>> 
>  > > >>>>>>> https://fedorahosted.org/sssd/ticket/1360
>  > > >>>>>>> 
>  > > >>>>>>> Rob, please confirm that this is the right and
> expected behavior.
>  > > >>>>>>> 
>  > > >>>>>>> Thanks
>  > > >>>>>>> Jan
>  > > >>>>>> 
>  > > >>>>>> What you have described sounds right. I don't have
> enough context in
>  > > >>>>>> sssd to know whether this patch will achieve that.
>  > > >>>>> 
>  > > >>>>> I realize that. I just wanted to verify that the described
> behavior is
>  > > >>>>> correct. The patch itself will be reviewed by someone else
> from SSSD
>  > > >>>>> team.
>  > > >>>>> 
>  > > >>>>> Thank you for the confirmation
>  > > >>>> 
>  > > >>>> We had a discussion in IRC and it seems that the using of the
> usermap
>  > > >>>> order is incorrect. The list is ordered from least to most
> permissive
>  > > >>>> (xguest ... unconfined).
>  > > >>>> 
>  > > >>>> We want to assign the most permissive context available. So if
> several
>  > > >>>> rules evaluate the same except for context we need to refer to
> the
>  > > >>>> ordered list and pick the most permissive one.
>  > > >>> 
>  > > >>> Following patch selects the right record with respect to ascending
> order
>  > > >>> of
>  > > >>> permission levels.
>  > > >> 
>  > > >> Ack
>  > > > 
>  > > > Pushed to master.
>  > > 
>  > > Maps are still not working properly.
>  > > 
>  > > It now always selects the highest priority that a user is associated
>  > > with. This is incorrect. It needs to go through an HBAC-style evaluation
>  > > where the specificity of the user (vs usercat=all) and the host are
>  > > taken into consideration.
>  > > 
>  > > So for example these three rules:
>  > > 
>  > >    Rule name: test_all
>  > >    SELinux User: unconfined_u:s0-s0:c0.c1023
>  > >    User category: all
>  > >    Host category: all
>  > >    Enabled: TRUE
>  > > 
>  > >    Rule name: test_tuser1_pinto
>  > >    SELinux User: staff_u:s0-s0:c0.c1023
>  > >    Enabled: TRUE
>  > >    Users: tuser1
>  > >    Hosts: pinto.greyoak.com
>  > > 
>  > >    Rule name: test_user
>  > >    SELinux User: user_u:s0-s0:c0.c1023
>  > >    Host category: all
>  > >    Enabled: TRUE
>  > >    Users: tuser1
>  > > 
>  > > If I log into pinto as tuser1 I get assigned unconfined_u. It should be
>  > > staff_u because that rule is more specific than test_all. The only time
>  > > the context ordering should be considered is when there are two rules
>  > > that match with the same specificity.
>  > 
>  > I'm sorry but I think this is a design decision that should have been made 
>  > clear in the design phase. I looked at both documents I was building my design 
>  > on to be sure and I can't find any reference to your approach. Could you give 
>  > me any pointer to a place where it has been described? Or is the specification 
>  > you just provided complete?
>  > 
>  > Also this is not some minor change, this might require implementation of some 
>  > decision making logic into NSS responder. I'd like to do a triage first to 
>  > figure out when do we want to do this / what priority does this task have.
>  
>  I agree with Jan here. Our original design instructions were to find a
>  match, and if more than one matches, use the priority to break the tie.
>  Specificity is a *very* difficult concept to implement, especially where
>  groups are involved. (e.g. suppose the SELinux rule is users in groupA
>  get one role assigned, users in groupB get a different role assigned,
>  but groupB is a nested group below groupA).
>  
>  This is a brand-new feature that should have a separate RFE filed. We
>  need a new, complete design documentation describing the methods for
>  determining specificity. 
Sorry Steve, but without the correct logic the whole feature is useless.
It is unfortunate the requirements were not communicated properly, but
they are required. The current logic simply doesn't work.

Simo.

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

[Stephen Gallagher]

On Tue, 2012-06-26 at 07:49 -0400, Simo Sorce wrote:
>  On Tue, 2012-06-26 at 07:23 -0400, Stephen Gallagher wrote:
>  > On Tue, 2012-06-26 at 08:37 +0200, Jan Zelený wrote:
>  > > Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>  > > > Stephen Gallagher wrote:
>  > > > > On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  > > > >> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  > > > >>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  > > > >>>> Jan Zelený wrote:
>  > > > >>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden
> napsal(a):
>  > > > >>>>>> Jan Zelený wrote:
>  > > > >>>>>>> This patch modifies behavior of SSSD when
> putting together content
>  > > > >>>>>>> of
>  > > > >>>>>>> user config file for pam_selinux. SSSD will
> now pick only the first
>  > > > >>>>>>> user
>  > > > >>>>>>> map in the priority list which matches to the
> user logging in. Other
>  > > > >>>>>>> maps
>  > > > >>>>>>> are ignored.
>  > > > >>>>>>> 
>  > > > >>>>>>> https://fedorahosted.org/sssd/ticket/1360
>  > > > >>>>>>> 
>  > > > >>>>>>> Rob, please confirm that this is the right
> and expected behavior.
>  > > > >>>>>>> 
>  > > > >>>>>>> Thanks
>  > > > >>>>>>> Jan
>  > > > >>>>>> 
>  > > > >>>>>> What you have described sounds right. I don't
> have enough context in
>  > > > >>>>>> sssd to know whether this patch will achieve
> that.
>  > > > >>>>> 
>  > > > >>>>> I realize that. I just wanted to verify that the
> described behavior is
>  > > > >>>>> correct. The patch itself will be reviewed by someone
> else from SSSD
>  > > > >>>>> team.
>  > > > >>>>> 
>  > > > >>>>> Thank you for the confirmation
>  > > > >>>> 
>  > > > >>>> We had a discussion in IRC and it seems that the using of
> the usermap
>  > > > >>>> order is incorrect. The list is ordered from least to
> most permissive
>  > > > >>>> (xguest ... unconfined).
>  > > > >>>> 
>  > > > >>>> We want to assign the most permissive context available.
> So if several
>  > > > >>>> rules evaluate the same except for context we need to
> refer to the
>  > > > >>>> ordered list and pick the most permissive one.
>  > > > >>> 
>  > > > >>> Following patch selects the right record with respect to
> ascending order
>  > > > >>> of
>  > > > >>> permission levels.
>  > > > >> 
>  > > > >> Ack
>  > > > > 
>  > > > > Pushed to master.
>  > > > 
>  > > > Maps are still not working properly.
>  > > > 
>  > > > It now always selects the highest priority that a user is associated
>  > > > with. This is incorrect. It needs to go through an HBAC-style evaluation
>  > > > where the specificity of the user (vs usercat=all) and the host are
>  > > > taken into consideration.
>  > > > 
>  > > > So for example these three rules:
>  > > > 
>  > > >    Rule name: test_all
>  > > >    SELinux User: unconfined_u:s0-s0:c0.c1023
>  > > >    User category: all
>  > > >    Host category: all
>  > > >    Enabled: TRUE
>  > > > 
>  > > >    Rule name: test_tuser1_pinto
>  > > >    SELinux User: staff_u:s0-s0:c0.c1023
>  > > >    Enabled: TRUE
>  > > >    Users: tuser1
>  > > >    Hosts: pinto.greyoak.com
>  > > > 
>  > > >    Rule name: test_user
>  > > >    SELinux User: user_u:s0-s0:c0.c1023
>  > > >    Host category: all
>  > > >    Enabled: TRUE
>  > > >    Users: tuser1
>  > > > 
>  > > > If I log into pinto as tuser1 I get assigned unconfined_u. It should be
>  > > > staff_u because that rule is more specific than test_all. The only time
>  > > > the context ordering should be considered is when there are two rules
>  > > > that match with the same specificity.
>  > > 
>  > > I'm sorry but I think this is a design decision that should have been made
>
>  > > clear in the design phase. I looked at both documents I was building my design
>
>  > > on to be sure and I can't find any reference to your approach. Could you
> give 
>  > > me any pointer to a place where it has been described? Or is the specification
>
>  > > you just provided complete?
>  > > 
>  > > Also this is not some minor change, this might require implementation of some 
>  > > decision making logic into NSS responder. I'd like to do a triage first to
>
>  > > figure out when do we want to do this / what priority does this task have.
>  > 
>  > I agree with Jan here. Our original design instructions were to find a
>  > match, and if more than one matches, use the priority to break the tie.
>  > Specificity is a *very* difficult concept to implement, especially where
>  > groups are involved. (e.g. suppose the SELinux rule is users in groupA
>  > get one role assigned, users in groupB get a different role assigned,
>  > but groupB is a nested group below groupA).
>  > 
>  > This is a brand-new feature that should have a separate RFE filed. We
>  > need a new, complete design documentation describing the methods for
>  > determining specificity.
>  
>  Sorry Steve, but without the correct logic the whole feature is useless.
>  It is unfortunate the requirements were not communicated properly, but
>  they are required. The current logic simply doesn't work. 

This has been discussed off-list. Simo is correct, we need to implement
this behavior before the feature can come off the "experimental" list.
Jan, please open an upstream ticket to track it. We'll try to get this
done for 1.9.0 beta 5. If it cannot be done in that time, we'll defer it
to 1.10.

[Rob Crittenden]

Jan Zelený wrote:
>  Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
> > Stephen Gallagher wrote:
> >> On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
> >>> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
> >>>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
> >>>>> Jan Zelený wrote:
> >>>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
> >>>>>>> Jan Zelený wrote:
> >>>>>>>> This patch modifies behavior of SSSD when putting
> together content
> >>>>>>>> of
> >>>>>>>> user config file for pam_selinux. SSSD will now pick only
> the first
> >>>>>>>> user
> >>>>>>>> map in the priority list which matches to the user
> logging in. Other
> >>>>>>>> maps
> >>>>>>>> are ignored.
> >>>>>>>>
> >>>>>>>> https://fedorahosted.org/sssd/ticket/1360
> >>>>>>>>
> >>>>>>>> Rob, please confirm that this is the right and expected
> behavior.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Jan
> >>>>>>>
> >>>>>>> What you have described sounds right. I don't have enough
> context in
> >>>>>>> sssd to know whether this patch will achieve that.
> >>>>>>
> >>>>>> I realize that. I just wanted to verify that the described
> behavior is
> >>>>>> correct. The patch itself will be reviewed by someone else from
> SSSD
> >>>>>> team.
> >>>>>>
> >>>>>> Thank you for the confirmation
> >>>>>
> >>>>> We had a discussion in IRC and it seems that the using of the
> usermap
> >>>>> order is incorrect. The list is ordered from least to most
> permissive
> >>>>> (xguest ... unconfined).
> >>>>>
> >>>>> We want to assign the most permissive context available. So if
> several
> >>>>> rules evaluate the same except for context we need to refer to the
> >>>>> ordered list and pick the most permissive one.
> >>>>
> >>>> Following patch selects the right record with respect to ascending order
> >>>> of
> >>>> permission levels.
> >>>
> >>> Ack
> >>
> >> Pushed to master.
> >
> > Maps are still not working properly.
> >
> > It now always selects the highest priority that a user is associated
> > with. This is incorrect. It needs to go through an HBAC-style evaluation
> > where the specificity of the user (vs usercat=all) and the host are
> > taken into consideration.
> >
> > So for example these three rules:
> >
> >     Rule name: test_all
> >     SELinux User: unconfined_u:s0-s0:c0.c1023
> >     User category: all
> >     Host category: all
> >     Enabled: TRUE
> >
> >     Rule name: test_tuser1_pinto
> >     SELinux User: staff_u:s0-s0:c0.c1023
> >     Enabled: TRUE
> >     Users: tuser1
> >     Hosts: pinto.greyoak.com
> >
> >     Rule name: test_user
> >     SELinux User: user_u:s0-s0:c0.c1023
> >     Host category: all
> >     Enabled: TRUE
> >     Users: tuser1
> >
> > If I log into pinto as tuser1 I get assigned unconfined_u. It should be
> > staff_u because that rule is more specific than test_all. The only time
> > the context ordering should be considered is when there are two rules
> > that match with the same specificity.
>
>  I'm sorry but I think this is a design decision that should have been made
>  clear in the design phase. I looked at both documents I was building my design
>  on to be sure and I can't find any reference to your approach. Could you give
>  me any pointer to a place where it has been described? Or is the specification
>  you just provided complete?
>
>  Also this is not some minor change, this might require implementation of some
>  decision making logic into NSS responder. I'd like to do a triage first to
>  figure out when do we want to do this / what priority does this task have.
>
>
>  Thanks
>  Jan 
http://freeipa.org/page/SELinux_user_mapping#Evaluation

rob

[Jan Zelený]

Dne úterý 26 června 2012 09:19:34, Rob Crittenden napsal(a):
>  Jan Zelený wrote:
>  > Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
>  >> Stephen Gallagher wrote:
>  >>> On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
>  >>>> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
>  >>>>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
>  >>>>>> Jan Zelený wrote:
>  >>>>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden
> napsal(a):
>  >>>>>>>> Jan Zelený wrote:
>  >>>>>>>>> This patch modifies behavior of SSSD when putting
> together content
>  >>>>>>>>> of
>  >>>>>>>>> user config file for pam_selinux. SSSD will now pick
> only the
>  >>>>>>>>> first
>  >>>>>>>>> user
>  >>>>>>>>> map in the priority list which matches to the user
> logging in.
>  >>>>>>>>> Other
>  >>>>>>>>> maps
>  >>>>>>>>> are ignored.
>  >>>>>>>>> 
>  >>>>>>>>> https://fedorahosted.org/sssd/ticket/1360
>  >>>>>>>>> 
>  >>>>>>>>> Rob, please confirm that this is the right and
> expected behavior.
>  >>>>>>>>> 
>  >>>>>>>>> Thanks
>  >>>>>>>>> Jan
>  >>>>>>>> 
>  >>>>>>>> What you have described sounds right. I don't have
> enough context
>  >>>>>>>> in
>  >>>>>>>> sssd to know whether this patch will achieve that.
>  >>>>>>> 
>  >>>>>>> I realize that. I just wanted to verify that the described
> behavior
>  >>>>>>> is
>  >>>>>>> correct. The patch itself will be reviewed by someone else
> from SSSD
>  >>>>>>> team.
>  >>>>>>> 
>  >>>>>>> Thank you for the confirmation
>  >>>>>> 
>  >>>>>> We had a discussion in IRC and it seems that the using of the
> usermap
>  >>>>>> order is incorrect. The list is ordered from least to most
> permissive
>  >>>>>> (xguest ... unconfined).
>  >>>>>> 
>  >>>>>> We want to assign the most permissive context available. So if
>  >>>>>> several
>  >>>>>> rules evaluate the same except for context we need to refer to
> the
>  >>>>>> ordered list and pick the most permissive one.
>  >>>>> 
>  >>>>> Following patch selects the right record with respect to ascending
>  >>>>> order
>  >>>>> of
>  >>>>> permission levels.
>  >>>> 
>  >>>> Ack
>  >>> 
>  >>> Pushed to master.
>  >> 
>  >> Maps are still not working properly.
>  >> 
>  >> It now always selects the highest priority that a user is associated
>  >> with. This is incorrect. It needs to go through an HBAC-style evaluation
>  >> where the specificity of the user (vs usercat=all) and the host are
>  >> taken into consideration.
>  >> 
>  >> So for example these three rules:
>  >>     Rule name: test_all
>  >>     SELinux User: unconfined_u:s0-s0:c0.c1023
>  >>     User category: all
>  >>     Host category: all
>  >>     Enabled: TRUE
>  >>     
>  >>     Rule name: test_tuser1_pinto
>  >>     SELinux User: staff_u:s0-s0:c0.c1023
>  >>     Enabled: TRUE
>  >>     Users: tuser1
>  >>     Hosts: pinto.greyoak.com
>  >>     
>  >>     Rule name: test_user
>  >>     SELinux User: user_u:s0-s0:c0.c1023
>  >>     Host category: all
>  >>     Enabled: TRUE
>  >>     Users: tuser1
>  >> 
>  >> If I log into pinto as tuser1 I get assigned unconfined_u. It should be
>  >> staff_u because that rule is more specific than test_all. The only time
>  >> the context ordering should be considered is when there are two rules
>  >> that match with the same specificity.
>  > 
>  > I'm sorry but I think this is a design decision that should have been made
>  > clear in the design phase. I looked at both documents I was building my
>  > design on to be sure and I can't find any reference to your approach.
>  > Could you give me any pointer to a place where it has been described? Or
>  > is the specification you just provided complete?
>  > 
>  > Also this is not some minor change, this might require implementation of
>  > some decision making logic into NSS responder. I'd like to do a triage
>  > first to figure out when do we want to do this / what priority does this
>  > task have.
>  > 
>  > 
>  > Thanks
>  > Jan
>  
>  http://freeipa.org/page/SELinux_user_mapping#Evaluation 
I'm sorry, I completely missed this documentation.

I have just one question. When it comes to priority, host specificity is more 
important than user specificity, right? Let's say I'll have two rules:

Rule name: rule1
SELinux User: staff_u:s0-s0:c0.c1023
Enabled: TRUE
Users: tuser1
Host category: all

Rule name: rule2
SELinux User: user_u:s0-s0:c0.c1023
Hosts: pinto.greyoak.com
Enabled: TRUE
User category: all

If I understand this correctly, then rule2 should have higher priority and I 
should be assigned user_u, is that right?

Thanks
Jan

[Rob Crittenden]

Jan Zelený wrote:
>  Dne úterý 26 června 2012 09:19:34, Rob Crittenden napsal(a):
> > Jan Zelený wrote:
> >> Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
> >>> Stephen Gallagher wrote:
> >>>> On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
> >>>>> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
> >>>>>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
> >>>>>>> Jan Zelený wrote:
> >>>>>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden
> napsal(a):
> >>>>>>>>> Jan Zelený wrote:
> >>>>>>>>>> This patch modifies behavior of SSSD when putting
> together content
> >>>>>>>>>> of
> >>>>>>>>>> user config file for pam_selinux. SSSD will now
> pick only the
> >>>>>>>>>> first
> >>>>>>>>>> user
> >>>>>>>>>> map in the priority list which matches to the
> user logging in.
> >>>>>>>>>> Other
> >>>>>>>>>> maps
> >>>>>>>>>> are ignored.
> >>>>>>>>>>
> >>>>>>>>>> https://fedorahosted.org/sssd/ticket/1360
> >>>>>>>>>>
> >>>>>>>>>> Rob, please confirm that this is the right and
> expected behavior.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Jan
> >>>>>>>>>
> >>>>>>>>> What you have described sounds right. I don't
> have enough context
> >>>>>>>>> in
> >>>>>>>>> sssd to know whether this patch will achieve that.
> >>>>>>>>
> >>>>>>>> I realize that. I just wanted to verify that the
> described behavior
> >>>>>>>> is
> >>>>>>>> correct. The patch itself will be reviewed by someone
> else from SSSD
> >>>>>>>> team.
> >>>>>>>>
> >>>>>>>> Thank you for the confirmation
> >>>>>>>
> >>>>>>> We had a discussion in IRC and it seems that the using of the
> usermap
> >>>>>>> order is incorrect. The list is ordered from least to most
> permissive
> >>>>>>> (xguest ... unconfined).
> >>>>>>>
> >>>>>>> We want to assign the most permissive context available. So
> if
> >>>>>>> several
> >>>>>>> rules evaluate the same except for context we need to refer
> to the
> >>>>>>> ordered list and pick the most permissive one.
> >>>>>>
> >>>>>> Following patch selects the right record with respect to
> ascending
> >>>>>> order
> >>>>>> of
> >>>>>> permission levels.
> >>>>>
> >>>>> Ack
> >>>>
> >>>> Pushed to master.
> >>>
> >>> Maps are still not working properly.
> >>>
> >>> It now always selects the highest priority that a user is associated
> >>> with. This is incorrect. It needs to go through an HBAC-style evaluation
> >>> where the specificity of the user (vs usercat=all) and the host are
> >>> taken into consideration.
> >>>
> >>> So for example these three rules:
> >>>      Rule name: test_all
> >>>      SELinux User: unconfined_u:s0-s0:c0.c1023
> >>>      User category: all
> >>>      Host category: all
> >>>      Enabled: TRUE
> >>>
> >>>      Rule name: test_tuser1_pinto
> >>>      SELinux User: staff_u:s0-s0:c0.c1023
> >>>      Enabled: TRUE
> >>>      Users: tuser1
> >>>      Hosts: pinto.greyoak.com
> >>>
> >>>      Rule name: test_user
> >>>      SELinux User: user_u:s0-s0:c0.c1023
> >>>      Host category: all
> >>>      Enabled: TRUE
> >>>      Users: tuser1
> >>>
> >>> If I log into pinto as tuser1 I get assigned unconfined_u. It should be
> >>> staff_u because that rule is more specific than test_all. The only time
> >>> the context ordering should be considered is when there are two rules
> >>> that match with the same specificity.
> >>
> >> I'm sorry but I think this is a design decision that should have been made
> >> clear in the design phase. I looked at both documents I was building my
> >> design on to be sure and I can't find any reference to your approach.
> >> Could you give me any pointer to a place where it has been described? Or
> >> is the specification you just provided complete?
> >>
> >> Also this is not some minor change, this might require implementation of
> >> some decision making logic into NSS responder. I'd like to do a triage
> >> first to figure out when do we want to do this / what priority does this
> >> task have.
> >>
> >>
> >> Thanks
> >> Jan
> >
> > http://freeipa.org/page/SELinux_user_mapping#Evaluation
>
>  I'm sorry, I completely missed this documentation.
>
>  I have just one question. When it comes to priority, host specificity is more
>  important than user specificity, right? Let's say I'll have two rules:
>
>  Rule name: rule1
>  SELinux User: staff_u:s0-s0:c0.c1023
>  Enabled: TRUE
>  Users: tuser1
>  Host category: all
>
>  Rule name: rule2
>  SELinux User: user_u:s0-s0:c0.c1023
>  Hosts: pinto.greyoak.com
>  Enabled: TRUE
>  User category: all
>
>  If I understand this correctly, then rule2 should have higher priority and I
>  should be assigned user_u, is that right?
>
>  Thanks
>  Jan
>  
user_u is correct.

rob

[Dmitri Pal]

On 06/27/2012 08:53 AM, Rob Crittenden wrote:
>  Jan Zelený wrote:
> > Dne úterý 26 června 2012 09:19:34, Rob Crittenden napsal(a):
> >> Jan Zelený wrote:
> >>> Dne pondělí 25 června 2012 17:35:55, Rob Crittenden napsal(a):
> >>>> Stephen Gallagher wrote:
> >>>>> On Fri, 2012-06-22 at 15:49 -0400, Stephen Gallagher wrote:
> >>>>>> On Fri, 2012-06-22 at 16:12 +0200, Jan Zelený wrote:
> >>>>>>> Dne pátek 22 června 2012 09:41:37, Rob Crittenden napsal(a):
> >>>>>>>> Jan Zelený wrote:
> >>>>>>>>> Dne pátek 22 června 2012 09:15:15, Rob Crittenden
> napsal(a):
> >>>>>>>>>> Jan Zelený wrote:
> >>>>>>>>>>> This patch modifies behavior of SSSD when
> putting together
> >>>>>>>>>>> content
> >>>>>>>>>>> of
> >>>>>>>>>>> user config file for pam_selinux. SSSD will
> now pick only the
> >>>>>>>>>>> first
> >>>>>>>>>>> user
> >>>>>>>>>>> map in the priority list which matches to the
> user logging in.
> >>>>>>>>>>> Other
> >>>>>>>>>>> maps
> >>>>>>>>>>> are ignored.
> >>>>>>>>>>>
> >>>>>>>>>>> https://fedorahosted.org/sssd/ticket/1360
> >>>>>>>>>>>
> >>>>>>>>>>> Rob, please confirm that this is the right
> and expected
> >>>>>>>>>>> behavior.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks
> >>>>>>>>>>> Jan
> >>>>>>>>>>
> >>>>>>>>>> What you have described sounds right. I don't
> have enough
> >>>>>>>>>> context
> >>>>>>>>>> in
> >>>>>>>>>> sssd to know whether this patch will achieve
> that.
> >>>>>>>>>
> >>>>>>>>> I realize that. I just wanted to verify that the
> described
> >>>>>>>>> behavior
> >>>>>>>>> is
> >>>>>>>>> correct. The patch itself will be reviewed by someone
> else
> >>>>>>>>> from SSSD
> >>>>>>>>> team.
> >>>>>>>>>
> >>>>>>>>> Thank you for the confirmation
> >>>>>>>>
> >>>>>>>> We had a discussion in IRC and it seems that the using of
> the
> >>>>>>>> usermap
> >>>>>>>> order is incorrect. The list is ordered from least to
> most
> >>>>>>>> permissive
> >>>>>>>> (xguest ... unconfined).
> >>>>>>>>
> >>>>>>>> We want to assign the most permissive context available.
> So if
> >>>>>>>> several
> >>>>>>>> rules evaluate the same except for context we need to
> refer to
> >>>>>>>> the
> >>>>>>>> ordered list and pick the most permissive one.
> >>>>>>>
> >>>>>>> Following patch selects the right record with respect to
> ascending
> >>>>>>> order
> >>>>>>> of
> >>>>>>> permission levels.
> >>>>>>
> >>>>>> Ack
> >>>>>
> >>>>> Pushed to master.
> >>>>
> >>>> Maps are still not working properly.
> >>>>
> >>>> It now always selects the highest priority that a user is associated
> >>>> with. This is incorrect. It needs to go through an HBAC-style
> >>>> evaluation
> >>>> where the specificity of the user (vs usercat=all) and the host are
> >>>> taken into consideration.
> >>>>
> >>>> So for example these three rules:
> >>>>      Rule name: test_all
> >>>>      SELinux User: unconfined_u:s0-s0:c0.c1023
> >>>>      User category: all
> >>>>      Host category: all
> >>>>      Enabled: TRUE
> >>>>
> >>>>      Rule name: test_tuser1_pinto
> >>>>      SELinux User: staff_u:s0-s0:c0.c1023
> >>>>      Enabled: TRUE
> >>>>      Users: tuser1
> >>>>      Hosts: pinto.greyoak.com
> >>>>
> >>>>      Rule name: test_user
> >>>>      SELinux User: user_u:s0-s0:c0.c1023
> >>>>      Host category: all
> >>>>      Enabled: TRUE
> >>>>      Users: tuser1
> >>>>
> >>>> If I log into pinto as tuser1 I get assigned unconfined_u. It
> >>>> should be
> >>>> staff_u because that rule is more specific than test_all. The only
> >>>> time
> >>>> the context ordering should be considered is when there are two rules
> >>>> that match with the same specificity.
> >>>
> >>> I'm sorry but I think this is a design decision that should have
> >>> been made
> >>> clear in the design phase. I looked at both documents I was
> >>> building my
> >>> design on to be sure and I can't find any reference to your approach.
> >>> Could you give me any pointer to a place where it has been
> >>> described? Or
> >>> is the specification you just provided complete?
> >>>
> >>> Also this is not some minor change, this might require
> >>> implementation of
> >>> some decision making logic into NSS responder. I'd like to do a triage
> >>> first to figure out when do we want to do this / what priority does
> >>> this
> >>> task have.
> >>>
> >>>
> >>> Thanks
> >>> Jan
> >>
> >> http://freeipa.org/page/SELinux_user_mapping#Evaluation
> >
> > I'm sorry, I completely missed this documentation.
> >
> > I have just one question. When it comes to priority, host specificity
> > is more
> > important than user specificity, right? Let's say I'll have two rules:
> >
> > Rule name: rule1
> > SELinux User: staff_u:s0-s0:c0.c1023
> > Enabled: TRUE
> > Users: tuser1
> > Host category: all
> >
> > Rule name: rule2
> > SELinux User: user_u:s0-s0:c0.c1023
> > Hosts: pinto.greyoak.com
> > Enabled: TRUE
> > User category: all
> >
> > If I understand this correctly, then rule2 should have higher
> > priority and I
> > should be assigned user_u, is that right?
> >
> > Thanks
> > Jan
> >
>
>  user_u is correct. 
Yes. The logic is based on the specificity.
A more specific rule wins and host part takes precedence over the user part.
>  rob
>
>  _______________________________________________
>  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/

[Dmitri Pal]

On 06/22/2012 09:27 AM, Jan Zelený wrote:
>  Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
> > Jan Zelený wrote:
> >> This patch modifies behavior of SSSD when putting together content of
> >> user config file for pam_selinux. SSSD will now pick only the first user
> >> map in the priority list which matches to the user logging in. Other maps
> >> are ignored.
> >>
> >> https://fedorahosted.org/sssd/ticket/1360
> >>
> >> Rob, please confirm that this is the right and expected behavior.
> >>
> >> Thanks
> >> Jan
> > What you have described sounds right. I don't have enough context in
> > sssd to know whether this patch will achieve that.
>  I realize that. I just wanted to verify that the described behavior is 
>  correct. The patch itself will be reviewed by someone else from SSSD team.
>
>  Thank you for the confirmation
>  
Have you checked with Dan?
>  Jan
>
>
>  _______________________________________________
>  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/

[Daniel J Walsh]

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

On 06/22/2012 09:41 AM, Dmitri Pal wrote:
>  On 06/22/2012 09:27 AM, Jan Zelený wrote:
> > Dne pátek 22 června 2012 09:15:15, Rob Crittenden napsal(a):
> >> Jan Zelený wrote:
> >>> This patch modifies behavior of SSSD when putting together content
> >>> of user config file for pam_selinux. SSSD will now pick only the
> >>> first user map in the priority list which matches to the user logging
> >>> in. Other maps are ignored.
> >>> 
> >>> https://fedorahosted.org/sssd/ticket/1360
> >>> 
> >>> Rob, please confirm that this is the right and expected behavior.
> >>> 
> >>> Thanks Jan
> >> What you have described sounds right. I don't have enough context in 
> >> sssd to know whether this patch will achieve that.
> > I realize that. I just wanted to verify that the described behavior is 
> > correct. The patch itself will be reviewed by someone else from SSSD
> > team.
> > 
> > Thank you for the confirmation
> > 
>  
>  Have you checked with Dan?
> > Jan
> > 
> > 
> > _______________________________________________ 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/
>  
>   
Well I only want one, so what ever the selection criteria you guys have chosen
is fine with me, as long as the admin can understand it.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/kerAACgkQrlYvE4MpobNT3wCglKScLQKvKifw/cnV+1X7wVej
> F5MAoImlYfs5dzBhkcGZ/qReLKC0mXHt
> =xhCT
> -----END PGP SIGNATURE-----