Re: unix permissions theory applied to db security? Or...?
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 31616
interpreted = N
texte = 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.-JohnJohn Peacock wrote:> I have to agree with Ken, this has nothing to do with Unix security. All > WebCat databases are accessed exclusively by the one user (nobody), and > record level security is nonexistant. > > If I had to set up this sort of thing from scratch, I would establish a > hierarchy for both records and users. A top level record/user would > have a security of 1, second level record/user would have security of 2, > etc. In other words: > > 1 > / \ > 2 2 > / \ / \ > 3 3 3 3 > > A user could modify any record with security <= their own security. > Users would append records at security == their own. All record > changes need to be moderated based on a lookup of the user security vs > record security. > > HTH > > John Peacock > > John Butler wrote: > > > > Could someone think out loud with me on this- ? > > > > I have a main.db with 10,000's of records (possibly 100,000's in the future) and each > > record can be appended/replaced/deleted by a user belonging to the specific group > > associated with that record PLUS everyone belonging to a group above him in the > > hierarchy of groups (but no one in a more lowly group). Imagine a tree with branches > > and the person at the trunk can edit any record, while the few people at the level of > > the first branches can edit 75% of the records, while people at the fine twig level can > > only edit a few records... But the trunk man can of course edit a twig record... > > > > I came up with a solution but someone suggested to me that this is really just a > > permissions issue and so could be more efficiently handled than the way I thought of. > > Can we apply the priciples of the way unix permissions work to efficiently allow just > > the security I need for this db? (I have never run a unix box myself...) Or do you > > have any thoughts on this at all you could share with me? > > > > Thanks for the time! > > :-) > > > > -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 ------------------------------------------------------------- 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:
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.-JohnJohn Peacock wrote:> I have to agree with Ken, this has nothing to do with Unix security. All > WebCat databases are accessed exclusively by the one user (nobody), and > record level security is nonexistant. > > If I had to set up this sort of thing from scratch, I would establish a > hierarchy for both records and users. A top level record/user would > have a security of 1, second level record/user would have security of 2, > etc. In other words: > > 1 > / \ > 2 2 > / \ / \ > 3 3 3 3 > > A user could modify any record with security <= their own security. > Users would append records at security == their own. All record > changes need to be moderated based on a lookup of the user security vs > record security. > > HTH > > John Peacock > > John Butler wrote: > > > > Could someone think out loud with me on this- ? > > > > I have a main.db with 10,000's of records (possibly 100,000's in the future) and each > > record can be appended/replaced/deleted by a user belonging to the specific group > > associated with that record PLUS everyone belonging to a group above him in the > > hierarchy of groups (but no one in a more lowly group). Imagine a tree with branches > > and the person at the trunk can edit any record, while the few people at the level of > > the first branches can edit 75% of the records, while people at the fine twig level can > > only edit a few records... But the trunk man can of course edit a twig record... > > > > I came up with a solution but someone suggested to me that this is really just a > > permissions issue and so could be more efficiently handled than the way I thought of. > > Can we apply the priciples of the way unix permissions work to efficiently allow just > > the security I need for this db? (I have never run a unix box myself...) Or do you > > have any thoughts on this at all you could share with me? > > > > Thanks for the time! > > :-) > > > > -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 ------------------------------------------------------------- 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 Butler
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Word wrapping (1997)
[include] affect on filepaths for links? (1997)
WebCat2b15MacPlugin - showing [math] (1997)
Sum of [founditems] ? (2004)
GIF Converter vs. Clip2Gif (2000)
Can this be done? (2003)
Press Release hit the NewsWire!!! (1997)
password authentication schemes (2003)
restarting webcatalog (2002)
chat opinion ... (2002)
Multiple Newcarts (1996)
Nesting FoundItem Context (1997)
PCS Frames (1997)
[!] not working? (1999)
TinyStore example templates (1998)
Multiple catalog databases and showcart (1997)
Emailer port change (1997)
Cancel Subscription (1996)
vs (1997)
Uploading out of FMP (2001)