[SSSD] [PATCHES] Modify priority evaluation in SELinux user maps

Jan Zelený jzeleny at redhat.com
Wed Jul 18 10:19:00 UTC 2012


Dne úterý 17 července 2012 16:27:40, Jakub Hrozek napsal(a):
> On Tue, Jul 17, 2012 at 04:07:27PM +0200, Jan Zelený wrote:
> > Dne úterý 17 července 2012 15:53:48, Jakub Hrozek napsal(a):
> > > On Tue, Jul 17, 2012 at 09:14:14AM +0200, Jan Zelený wrote:
> > > > Dne pondělí 16 července 2012 17:45:05, Jakub Hrozek napsal(a):
> > > > > On Mon, Jul 16, 2012 at 04:20:23PM +0200, Jan Zelený wrote:
> > > > > > The functionality is now following:
> > > > > > 
> > > > > > When rule is being matched, its priority is determined as a
> > > > > > combination
> > > > > > of user and host specificity (host taking preference).
> > > > > > 
> > > > > > After the rule is matched in provider, its host priority is stored
> > > > > > in sysdb for later usage.
> > > > > > 
> > > > > > When rules are matched in the responder, their user priority is
> > > > > > determined. After that their host priority is retrieved directly
> > > > > > from
> > > > > > sysdb and sum of both priorities is used to determine whether to
> > > > > > take
> > > > > > that rule into account or not. If more rules have the same
> > > > > > priority,
> > > > > > the
> > > > > > order given in IPA config is used.
> > > > > > 
> > > > > > Thanks
> > > > > > Jan
> > > > > 
> > > > > Nack, I don't like the concept of storing the priority scores in the
> > > > > sysdb -- the priority scores depend on the user being processed and
> > > > > the
> > > > > hostname that comes from pam data. I think the scores should be
> > > > > computed
> > > > > in responder and the provider should only store the data in the
> > > > > sysdb.
> > > > 
> > > > Your assumption is not entirely accurate. The host priority depends on
> > > > host- related data that are retrieved from IPA server. Therefore we
> > > > would
> > > > need to store this data in sysdb instead of the priority and do the
> > > > same
> > > > processing twice - once in provider to know what rules apply to the
> > > > host
> > > > and once in responder to determine their priority. That's why I think
> > > > calculating priority in the first pass and then utilize this number
> > > > (which don't change by the way) further instead of calculating it
> > > > againg
> > > > is far better.
> > > > 
> > > > However if you insist, I won't argue with you and do the change.
> > > 
> > > It's wrong because the priority is computer *per-user* and stored in a
> > > generic object, at least that's how I read the code.
> > > 
> > > How would this work for a different user, would we store
> > > per-user value in a generic object on each login? What about offline
> > > logins, what if a different user logs in?
> > 
> > No, the priority in sysdb is *per host*. The user part is then computed
> > and
> > added to the host part in responder as you suggest.
> 
> Right, I saw SYSDB_SELINUX_USER_PRIORITY and got confused. Please remove
> that constant, add ticket URL to the commit message and I'll ack.

Yep, sorry for that. I used that for a while but removed it in the end and 
forgot about the definition. Both things you requested have been done.

Thanks
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jzeleny-154-sysdb_attrs_copy_values.patch
Type: text/x-patch
Size: 2215 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120718/baa15ec5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jzeleny-155-1-priority-evaluation-in-SELinux-user-maps.patch
Type: text/x-patch
Size: 11252 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120718/baa15ec5/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120718/baa15ec5/attachment.sig>


More information about the sssd-devel mailing list