Re: Houston, we have a problem...

[Aaron Turner <aturner@linuxkb.org>]

On Wed, 29 Dec 1999, Jason Pincin wrote:

> Nope.  I've already considered that.  Believe me... I've considered MANY
> different ways to handle object location... they all have they're ups &
> downs.
> 
> Tracking object location by "parent only" is nice for re-categorization.
> Where it SUCKS is security.
> 
> I went back and forth for this for a long time.  The root of the problem
> is that we're implimenting the LinuxKb as script that loads, executes, and
> unloads.  So what I decided is that, in the long term we will ideally

Huh?  Thought it was a dynamically generated site?  What is loading,
executing, and then "unloading"?  Sounds like my zip drive :)

> reach location tracking by parent id only, but for now, we must track the
> entire location of an object.  Here's why:
> 
> Say I have a category called DNS, and under there I have two applications,
> once called named, and the other called nslookup.  under each of those
> applications are several articles.  Now, I want to assign someone as a
> "moderator" for the "DNS" category, and I want them to hav certain
> privleges over ALL articles, categories, etc under that DNS category.  To
> do this I have 2 options... I can either assign the permissions ONCE, to
> the DNS category and mark it as a recursive permission, or I can assign
> the SAME permission to EVERY object beneath that category.  So I thought,
> well, if I enable recursive permissions, I'm going to save a helluva lot
> of space in the permissions DB, which in turn will allow for much quicker
> access to user/object security info which will be needed on nearly every
> page load.  Thats a good thing methinks.  Plus, it reduced the chance of

I don't understand why permissions are an issue for avg. joe. user. using
the site to find an answer.

> page bugs screwing up and missing some permission re-assignments etc.  So
> I took the approach of enabling recursive permissions.

Following so far... (cept that every page load thing)

> Now... In order to do that, you need to know all the parents of an object
> in order to scan for any recursive permissions set on parents.  To do this
> when only tracking parent ID's of objects would involve monster/multiple
> slow queries.  You'd have to query the first parent, find out what it's
> parent was, then query that parent for it's parent, etc. all the way up
> the line until there were no more parents.  

Ok, I get that.  

> The deeper you drilled the
> more massive the permissions query would become.  I thought this was bad.
> In order to correct this problem, each object had to store it's entire
> heritage.  This makes the permissions scan small and quick no matter how
> deep you go, but complicates re-organization.  

Well I see two things that make this much less of an issue:

1) Realize that these security queries are going to run less than 1% of
the total queries, just because the time the cat. maintainers spend
working on the site is relatively small compared to the rest of the site's
activity.  Hence the overall load on the DB is rather small, so we don't
need to optimize it much compared to the rest of the site.

2a) Since the creation of new categories and their recategorization are
known events there should be an easy way to create a "security" table.
Basically you have easy place to lookup all the "parents" for a specific
category, kinda like a xref table.  This would be rather fast I would
think.

2b) Create the security table once per day via a perl script, kinda like
we create the DB.PHP.CACHE file.  Reality is that if a category isn't
properly protected for say 6 hours (run it 4x day) it isn't a big deal.
We're not working with people's credit card info after all.

> I figured, permissions scans would be happening on nearly every page load,
> and re-organization's would be once-and-done type queries... so I opted
> for the approach you see before you.

I don't see why.  There's no need to do a permission scan for avg. joe
user who is using the site.  Only category admins.
 
> This will be a total pain in the ass to re-organize at the sql cmd-line
> level, but the admin pages can handle it very easily.

Are you say converting to my proposal will be difficult?  It would be VERY
easy to do in Perl.  Maybe 20 lines of code, max.

> And re-organizations will not affect permissions at all since permissions
> are stored by object id, not object location.

???

> The only other option for this would be to store location via parent
> object id, and have object locations updated via DB triggers, but MySQL
> does not support triggers, so we're screwed there as well.

???  What's a trigger, and how would that help?  Just curious.

> Thoughts/Comments/Suggestions welcome.
> 
> Jason
> 
> 
> 
> On Wed, Dec 29, 1999 at 11:37:47AM -0800, Aaron Turner wrote:
> > 
> > I just found a "problem".  It's more of an annoyance really.  Take this
> > example- you have two parent categories:
> > 
> > 1.3 Networking
> > 1.42 Sys_Admin
> > 
> > I decide I want to move the Networking category under Sys_Admin:
> > 
> > 1.42.3 Networking
> > 
> > Easy enough.  Except that all the categories/articles under Networking:
> > 
> > 1.3.5 DNS
> > 1.3.23 PPP
> > 
> > No longer exist on the web site.  They're kinda like orphaned children
> > because the parent left them.  This means that if we ever move a category,
> > we have to find all the old children and move them manually one by one.  A
> > far better solution is to store cats/arts in the db not by specifying the
> > whole location, but just the parent ID.  This way you can move the parent
> > and all the children automatically follow it.
> > 
> > As far as I can tell, this is just a matter of fixing functions.php3 to
> > work with the DB in a slightly different manner.  Probably a significant
> > bit of work though.
> > 
> > Comments?
> > 
> > --
> > Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
> > Linux Knowledge Base Organization  http://linuxkb.org/
> > Because world domination requires quality open documentation.
> > aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
> 
> -- 
> Jason
> http://vodka.linuxkb.org/~chardros
> 

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net