Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memcache bypasses access restrictions (Trac #3018) #3018

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 10 comments
Closed

Memcache bypasses access restrictions (Trac #3018) #3018

elgg-gitbot opened this issue Feb 16, 2013 · 10 comments
Labels
Milestone

Comments

@elgg-gitbot
Copy link

Original ticket http://trac.elgg.org/ticket/3018 on 41162597-06-28 by trac user miguel, assigned to unknown.

Elgg version: 1.7

With memcache active, the function get_entity($guid) can return objects not viewable by the current user, as long as the entity is found in memcache.

If it is not found, usual access restrictions work, because they are checked inside get_entity_as_row. This is with Elgg 1.7.7.

@elgg-gitbot
Copy link
Author

trac user mrclay wrote on 41254359-03-28

For persistent key-value stores like Memcache, the entity and some information about its access should be stored separately. E.g.:

Add a function:

/**
 * Can a user access an entity?
 * return bool
 */
function elgg_user_can_access_entity($user_guid, $entity_guid) {
  // quick as possible DB check (don't hydrate the entity)
}

Each time an entity is stored in Memcached, this key/value must be stored separately:
"u{$current_user_guid}-sees-e{$entity_guid}" = true

When get_entity() finds an entity in Memcached, it must also check this "sees" key for the current user. If missing, it must call elgg_user_can_access_entity(), populating the "sees" key if it returns true. I don't suggest saving false because it's probably not a common case.

@elgg-gitbot
Copy link
Author

ewinslow wrote on 41254796-07-05

You mean like this: http://reference.elgg.org/engine_2lib_2access_8php.html#af5f7246dfad0743a6568820d19858188?

@elgg-gitbot
Copy link
Author

trac user mrclay wrote on 41256114-07-05

evan, yep!

The remaining problem is that, when an entity's access changes, I see no way to invalidate the per-user visibility caches.

Perhaps a better design would store the access info more like the DB:

KeyValueStore.set("e123-acl") = 234 // or "public"/"private"/"loggedIn"

...as well as caching the ACL member lists:

KeyValueStore.set("acl234-guids") = [35,235,643]

Now you still have a straightforward way to see if user 643 can see entity 12, and better, when either entities or ACLs change, we can immediately reflect this in the key/value store without managing tons of keys or waiting for values to expire.

@elgg-gitbot
Copy link
Author

cash wrote on 41258144-08-12

I prefer the later solution (storing access information in memcache).

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.9 by ewinslow on 41500292-02-22

@elgg-gitbot
Copy link
Author

trac user ebogdanov wrote on 41996978-06-15

We are using Elgg, and have the same issues,
If it is possible, I'll vote to fix that issue in upcoming Elgg release. It is almost critical, since memcache is unusable with that defect.

@elgg-gitbot
Copy link
Author

trac user coldtrick wrote on 42760735-04-19

Pull request by Steve

#399

please apply!!!!!!!!!!!!!!!

@elgg-gitbot
Copy link
Author

trac user Steve Clay wrote on 42776711-03-05

Fixes #3018: Checks DB for access before using memcache-stored entity (suggested by Jerôme Bakker)
Changeset: 5c069bb

@elgg-gitbot
Copy link
Author

trac user Evan Winslow wrote on 42776711-03-17

Merge pull request #399 from mrclay/3018-memcache-access

Fixes #3018: Checks DB for access before using memcache-stored entity
Changeset: 84bf489

@elgg-gitbot
Copy link
Author

Milestone changed to Elgg 1.8.9 by cash on 42939842-04-26

brettp pushed a commit to brettp/Elgg that referenced this issue Feb 21, 2013
brettp pushed a commit to brettp/Elgg that referenced this issue Feb 21, 2013
Fixes Elgg#3018: Checks DB for access before using memcache-stored entity
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

1 participant