On Tue, Feb 23, 2016 at 04:08:52PM +0100, Petr Cech wrote:
> 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.

This is not described in this design page. Did you talk to Pavel who
will work on providing the API for triggering the refresh?

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

I assume you meant --sudo-rule (singular) here?

> * 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}`.

I'm all for consolidating functions in one place.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org

Reply via email to