Re: unix permissions theory applied to db security? Or...?

This WebDNA talk-list message is from

2000

It keeps the original formatting. numero = 31617
interpreted = N
texte = I'm sorry, I didn't realize you really had a tree structure. I would suggest using a linked list model then. Let's see if I can do this from memory (you would be better off getting a book on C/S algorythms, rather than relying on my very suspect rememberances).Each record contains a key that points to its parent. You need to havesomething like a pointer so you can walk up the tree; the SKU will do,since you really only need something you can lookup at each step. Theuser record contains the highest branch that that user can edit. Let'suse the following diagram (with trivial SKU values): 1 / \ 2 3 /\ /\ 4 5 6 7Chose a record (let us say 7). Any user with a access value of 7, 3, or 1 would be able to edit that record. You would examine record(7) and compare it to the user's access level; if it was not exactly 7, you would look at the record corresponding to 7's parent record (3) and perform the same test. So on and so on. Note that node 1 has itself as a parent (or you can code it as [BLANK]).Note, that it will not be easy to walk the tree down (i.e. to know thatuser with access of 2 can also edit 4 and 5), because of the way that you are storing the record information. If you can guarantee that any level will only have two lower subtrees, you can use black/red (or left/right) for the children records. Since you are not trying to do a B-Tree, and you have basically sequential records, you can probably limit yourself to the parent-only schema.The only thing that I have not examined is how you can do this testing in WebDNA!!! I think you might be able to write a small routine whichcould be called recursively to walk the tree until either you found a match for the user's access level or you hit the top level. Think ofan include file which either resolves to a button to EDIT or callsitself with the user's access level and the SKU of the parent to the current record.Hope this give you some ideas.John PeacockJohn Butler wrote:> > John,> the only thing about what you wrote here is that it does not account for the need to> restrict record access to just the heirarchy branch the user is responsibel for (or anyone> with a better security number *in that particular branch*). So for example just because a> level 3 user can edit one particular set of level-3 records does not mean he can edit ALL> the level 3 records... And a level 2 user doesn't necessarily get to edit any level 3> records . He can edit the level 3 record only if that level 3 record is in subset of *his*> level 2...> > I guess I have to:> (note that field names are in single 'quotes' while field values are in double quotes)> > 1) put fields in that Main.db to not only identify that record's 'level' (1, 2, or 3> etc.), but also that record's 'LowestGroupCanEdit'- which for each record has a value> equal to the lowest group that can edit that record.> 3) create a Groups.db which has a field 'groups' (and each record has a value for 'groups'> equal to the group that record is associated with), and fields like 'EditorName' and> 'EditorPass' which have values identifying that user and his password. So if some new group> had 97 members then that would add 97 records in this db all with the same value for the> 'groups' field, but each having different values for 'EditorName' and 'EditorPass' to> reflect each of those editors, etc.> 4) When someone tries to edit a record in the Main.db, then notice the value for> 'LowestGroupCanEdit' in that main.db record, and then search for all the record's in the> Groups.db that have a similar value in the 'groups' field and see if any of those found> records contain the 'EditorName' and 'EditorPass' that the would-be-editor logged in with.> If so permit the edit. If not then not.> > Thanks for reading all that and responding :-) if you see any flaws or better ideas.> > -John>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Associated Messages, from the most recent to the oldest:

Re: unix permissions theory applied to db security? Or...? (John Peacock 2000)
Re: unix permissions theory applied to db security? Or...? (John Butler 2000)
Re: unix permissions theory applied to db security? Or...? (John Butler 2000)
Re: unix permissions theory applied to db security? Or...? (John Peacock 2000)
Re: unix permissions theory applied to db security? Or...? (Kenneth Grome 2000)
Re: unix permissions theory applied to db security? Or...? (Clement Ross 2000)
unix permissions theory applied to db security? Or...? (John Butler 2000)

I'm sorry, I didn't realize you really had a tree structure. I would suggest using a linked list model then. Let's see if I can do this from memory (you would be better off getting a book on C/S algorythms, rather than relying on my very suspect rememberances).Each record contains a key that points to its parent. You need to havesomething like a pointer so you can walk up the tree; the SKU will do,since you really only need something you can lookup at each step. Theuser record contains the highest branch that that user can edit. Let'suse the following diagram (with trivial SKU values): 1 / \ 2 3 /\ /\ 4 5 6 7Chose a record (let us say 7). Any user with a access value of 7, 3, or 1 would be able to edit that record. You would examine record(7) and compare it to the user's access level; if it was not exactly 7, you would look at the record corresponding to 7's parent record (3) and perform the same test. So on and so on. Note that node 1 has itself as a parent (or you can code it as [BLANK]).Note, that it will not be easy to walk the tree down (i.e. to know thatuser with access of 2 can also edit 4 and 5), because of the way that you are storing the record information. If you can guarantee that any level will only have two lower subtrees, you can use black/red (or left/right) for the children records. Since you are not trying to do a B-Tree, and you have basically sequential records, you can probably limit yourself to the parent-only schema.The only thing that I have not examined is how you can do this testing in WebDNA!!! I think you might be able to write a small routine whichcould be called recursively to walk the tree until either you found a match for the user's access level or you hit the top level. Think ofan include file which either resolves to a button to EDIT or callsitself with the user's access level and the SKU of the parent to the current record.Hope this give you some ideas.John PeacockJohn Butler wrote:> > John,> the only thing about what you wrote here is that it does not account for the need to> restrict record access to just the heirarchy branch the user is responsibel for (or anyone> with a better security number *in that particular branch*). So for example just because a> level 3 user can edit one particular set of level-3 records does not mean he can edit ALL> the level 3 records... And a level 2 user doesn't necessarily get to edit any level 3> records . He can edit the level 3 record only if that level 3 record is in subset of *his*> level 2...> > I guess I have to:> (note that field names are in single 'quotes' while field values are in double quotes)> > 1) put fields in that Main.db to not only identify that record's 'level' (1, 2, or 3> etc.), but also that record's 'LowestGroupCanEdit'- which for each record has a value> equal to the lowest group that can edit that record.> 3) create a Groups.db which has a field 'groups' (and each record has a value for 'groups'> equal to the group that record is associated with), and fields like 'EditorName' and> 'EditorPass' which have values identifying that user and his password. So if some new group> had 97 members then that would add 97 records in this db all with the same value for the> 'groups' field, but each having different values for 'EditorName' and 'EditorPass' to> reflect each of those editors, etc.> 4) When someone tries to edit a record in the Main.db, then notice the value for> 'LowestGroupCanEdit' in that main.db record, and then search for all the record's in the> Groups.db that have a similar value in the 'groups' field and see if any of those found> records contain the 'EditorName' and 'EditorPass' that the would-be-editor logged in with.> If so permit the edit. If not then not.> > Thanks for reading all that and responding :-) if you see any flaws or better ideas.> > -John>-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to John Peacock

DOWNLOAD WEBDNA NOW!

Re: unix permissions theory applied to db security? Or...?

2000

Top Articles:

Related Readings: