<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 12/01/2011 10:41 AM, Stephen Gallagher wrote:
    <blockquote
      cite="mid:1322754119.2474.7.camel@sgallagh520.sgallagh.bos.redhat.com"
      type="cite">
      <pre wrap="">On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Hi,

As we work on the Sudo integration with Pavel, I'm thinking about how
should we handle our cache.

On one hand, I think our cache should be complete and possibly up to date
to allow seamless offline operation. In the first prototype we have now,
we just download the whole tree during every request. That's not going
to scale, obviously. There can be many rules and downloading them all can
get expensive.

I think we can use the following mechanism:

1) the backend would schedule a periodic task to download all rules,
</pre>
      </blockquote>
    </blockquote>
    <br>
    that apply only to this host, right?<br>
    You do not need rules that do not apply to the host.<br>
    <br>
    <blockquote
      cite="mid:1322754119.2474.7.camel@sgallagh520.sgallagh.bos.redhat.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">much like the current enumeration task. There may be an option to
fine tune how often should the task start.
2) when a request comes, we would update the cache that affects the
user only(*). We keep an in-memory timeout per user so that subsequent
requests from the same user are handled fast.

Does that sound OK?

* even native sudo only searches for
  "(|(sudoUser=ALL)(sudoUser=username)(sudoUser=%group1)(sudoUser=%group2))"
  so we can limit the online update the same way
</pre>
      </blockquote>
      <pre wrap="">
It's interesting that native SUDO only supports lookups that way. It
doesn't take into account the possibility of rules that affect the user
as a member of a netgroup applying to a rule. Granted, most netgroups
are used as a mechanism for restricting the *host* rather than users,
but it's still a possibility that we should consider.

Unless we're going to make the assumption that it's sufficient to trust
netgroup membership to the enumeration task instead.

</pre>
    </blockquote>
    <br>
    I think we can start with the approach Jakub suggested and document
    the assumption about netgroups.<br>
    If we are asked to change it, we will consider but I would say our
    general theme is "use groups".<br>
    <br>
    <blockquote
      cite="mid:1322754119.2474.7.camel@sgallagh520.sgallagh.bos.redhat.com"
      type="cite">
      <pre wrap=""></pre>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/mailman/listinfo/sssd-devel">https://fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>