libini - config file validity checks
by Michal Židek
Hi!
This is the WIP design stub for config file checks:
https://fedorahosted.org/sssd/wiki/DesignDocs/libini-config-file-checks
For the first version we just want to
have the typo detection mechanism. To be more
precise, we want to detect:
1. options with wrong names
2. options in wrong sections
For the more complicated checks in later
version I would like to add possibility
to define constraints for the config file.
The idea is also described in the design stub.
For the definitions of constraints, we can use INI format
as well and not the custom format that I use now.
However the custom format is quite simple and
looks better IMO and allows to parse different
attributes in different way which results in less
verbose and better formatted file. However as I said it
is not required to get the functionality.
The abilities of the rules can be further
extended by adding new attributes with special
meaning (see the design).
Lukas could you also describe the idea you told
me with the hooks in C? It sounded like a
good idea but I do not remember all the
details.
Michal
6 years, 4 months
URI in HBAC rules - patch - request for feedback
by Lukáš Hellebrandt
Hi, FreeIPA and SSSD communities!
I am working on adding URI to HBAC as my thesis [1]. The goal is to
control access not only based on (user, host, service), but on (user,
host, service, resource's URI).
I created a patch for FreeIPA [2] so it is capable of storing URI as
part of HBAC rule. I created a patch for SSSD [3] so it is able to get
this URI from FreeIPA and use it in HBAC evaluation.
I still need to develop a part of SSSD receiving URI-aware requests. It
will either be an enhancement of Infopipe or I will use PAM responder
(any suggestions?).
I wanted to kindly ask you for review and your opinions on the patches
and generally on my approach. This would be my first contribution to
FreeIPA and SSSD so there might be bugs. What do you think?
Btw, is there some better place to share patches than a pasting tool?
Maybe some form of pull request?
Thanks for your opinions!
[1]
https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uri...
[2]
http://pastebin.com/rsHzXeAR
[3]
http://pastebin.com/atcZMuP1
--
Lukas Hellebrandt
6 years, 4 months
[PATCH] IPA: lookup idview name even if there is no master domain
by Sumit Bose
Hi,
these two patches fixes and issue which was reported on
https://www.redhat.com/archives/freeipa-users/2016-February/msg00148.html
and is now tracked in https://fedorahosted.org/sssd/ticket/2960 .
The first patch makes sure the view name is read even if there is an
error with the master domain lookup.
The second patch makes sure that SSSD will pick up the new override data
immediately after the upgrade without additional changes. This change is
needed because currently SSSD assumes that the cache was empty if no
view name was read from the cache and does not cleanup the override
data. But if a version of SSSD with the issue fixed by the first patch
was run before the cache will contain the override data for the default
view which most be removed to make sure SSSD will read the new override
data.
To reproduce use a FreeIPA where ipa-adtrust-install was not run, add a
new idview and assign it to an IPA client. Without the patch the IPA
client will continue to show the default IPA user data and no override
value.
bye,
Sumit
6 years, 4 months
[DESIGN] Invalidate cached sudo rules
by Petr Cech
Hello,
I've started the design page for Invalidating cached sudo rules here:
https://fedorahosted.org/sssd/wiki/DesignDocs/SUDOCachingRulesInvalidate
This task consists of two tickets (see below). So far, I have worked on
the first one. The second one is waiting for SSSD Status Tool.
For your convenience, I've included the text below as well:
= Invalidate Cached SUDO Rules =
Related ticket(s):
* https://fedorahosted.org/sssd/ticket/2081
* https://fedorahosted.org/sssd/ticket/2884
=== Problem statement ===
Currently sss_cache can't be used to reliably invalidate sudo rules.
=== Use cases ===
Usually if admin changes sudo rules he would like to see an effect
immediately.
=== Overview of the solution ===
Sudo rules are stored in sss_cache. Sometimes ''smart'' or ''full''
refresh of sudo rules is done, but there is no effective way to
invalidate them (see
https://fedorahosted.org/sssd/wiki/DesignDocs/SUDOCachingRules).
Solution consists of two steps:
1. Invalidate sudo rules by setting expiration time to 0 which can
prevent to use old rules.
2. Trigger full refresh (and maybe even smart refresh) on demand.
=== Implementation details ===
==== Invalidating sudo rules ====
SSSD provides tool sss_cache for invalidating items.
{{{
$ sss_cache --help
Usage: sss_cache [OPTION...]
-E, --everything Invalidate all cached entries except for
sudo rules
-u, --user=STRING Invalidate particular user
-U, --users Invalidate all users
-g, --group=STRING Invalidate particular group
-G, --groups Invalidate all groups
-n, --netgroup=STRING Invalidate particular netgroup
-N, --netgroups Invalidate all netgroups
-s, --service=STRING Invalidate particular service
-S, --services Invalidate all services
-a, --autofs-map=STRING Invalidate particular autofs map
-A, --autofs-maps Invalidate all autofs maps
-h, --ssh-host=STRING Invalidate particular SSH host
-H, --ssh-hosts Invalidate all SSH hosts
-d, --domain=STRING Only invalidate entries from a particular
domain
Help options:
-?, --help Show this help message
--usage Display brief usage message
}}}
We need:
* add option `--sudo-rules=STRING` for invalidating only STRING named
sudo rule,
* add option `--sudo-rules` for invalidating all sudo rules,
* change option `--everything` for invalidating sudo rules too.
For those changes we will provide new function
`sysdb_search_sudo_rule()` in `db/sysdb_sudo.{hc}`.
{{{
#!C
errno_t
sysdb_search_sudo_rules(TALLOC_CTX *mem_ctx,
struct sss_domain_info *domain,
const char *filter,
const char **attrs,
size_t *num_hosts,
struct ldb_message ***hosts)
/* Synopsis is inspired by other `sysdb_search_*()` functions. */
}}}
This new function be able to find sudo rule by given name (via filter).
On the other hand there is function
`sudosrv_get_sudorules_query_cache()` in
`responder/sudo/sudosrv_get_sudorules.c` which has very similar
behavior. Maybe it is candidate for proxy and moving to
`db/sysdb_sudo.{hc}`.
--
Petr^4 Cech
6 years, 4 months
[PATCH] Resolve IPA external group members during getgr* requests
by Jakub Hrozek
Hi,
the attached patches implement https://fedorahosted.org/sssd/ticket/2522
Here is what I tested:
1) topgr -> bottomgr -> extgr -> administrator(a)win.trust.test
- this is a simple case to test a member of an external group
2) ipa_uni -> ipa_uni_ext -> unigroup(a)win.trust.test
|
+-- userfromchild(a)child.win.trust.test
\- anotheruser(a)win.trust.test
- this is to test that a universal group with members from two
domains resolves correctly
3) idm_admin -> idm_admin_ext -> extgroup(a)win.trust.test
\- puser(a)win.trust.test
-> someuser(a)win.trust.test
- tests that a combination of user and group members work
4) toc_admin -> toc_admin_ext -> someuser(a)win.trust.test
-> someuser(a)child.win.trust.test
- tests that two users with the same name from different domains
work correctly
I also tested adding and removing group members and found some bugs in
our groups processing (#2940, #2952)
Please feel free to suggest more tests. If the patches are accepted,
I'll also add unit tests for the nested groups code, but currently we
need to make the patches available to upstream.
I also tested a combination of user lookups and group lookups,
especially with someuser to test that the initgroups and group lookups
play well together. And that's where I found one issue that I think we
should fix in master -- the initgroups code adds the external members as
direct members of the POSIX group, so I did the same in the group
lookup code. This is safer, but doesn't allow us to remove the hack we
have (6fac5e5f0c54a0f92872ce1450606cfcb577a920) to retain external
members.
I think in 1.14 it would be more systematic to store the group
membership as:
gr -> ext_gr -> ad_member
rather than:
gr -> ext_gr
-> ad_member
The reason we can't remove those hacks is that if the external group is
up-to-date and only the top group is resolved, we would only write the
group memberships as stored in LDAP, effectively removing the AD
memberships. This of course depends on fixing the issues in memberof
plugin, but I still think it's worth it. The current code works well,
though, so I guess we can accept it for 1.13.
Our initgroups code should be well equipped to handle that and we could
remove the hacks we have at the moment.
6 years, 4 months
