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, 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
On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
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:
- the backend would schedule a periodic task to download all rules,
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
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.
On 12/01/2011 10:41 AM, Stephen Gallagher wrote:
On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
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:
- the backend would schedule a periodic task to download all rules,
that apply only to this host, right? You do not need rules that do not apply to the host.
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
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.
I think we can start with the approach Jakub suggested and document the assumption about netgroups. If we are asked to change it, we will consider but I would say our general theme is "use groups".
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Dne 1.12.2011 16:41, Stephen Gallagher napsal(a):
On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
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:
- the backend would schedule a periodic task to download all rules,
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
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.
Actually sudo does consider netgroups aswell. It performs two LDAP lookups. The first is against matching username, groups and ALL keyword. The second one is for the netgroups.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Dec 02, 2011 at 08:57:11AM +0100, Pavel Březina wrote:
Dne 1.12.2011 16:41, Stephen Gallagher napsal(a):
On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
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:
- the backend would schedule a periodic task to download all rules,
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
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.
Actually sudo does consider netgroups aswell. It performs two LDAP lookups. The first is against matching username, groups and ALL keyword. The second one is for the netgroups.
Yeah, sorry. I was mainly trying to illustrate that we actually *can* limit the lookups and don't have to download all the rules all the time.
Sorry for the confusion.
On Thu, 2011-12-01 at 16:27 +0100, Jakub Hrozek wrote:
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:
- the backend would schedule a periodic task to download all rules,
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
ACK. Simo.
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Pavel Březina -
Simo Sorce -
Stephen Gallagher