Re: unix permissions theory applied to db security? Or...?
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 31607
interpreted = N
texte = This is the track I am on, so thanks guys for confirming...John 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:
This is the track I am on, so thanks guys for confirming...John 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:
RE: WebCatalog2 for NT Beta Request (1997)
database visibility (2000)
form data submission gets truncated (1997)
Include a big block of text (1997)
Another question about credit cards (1997)
Can't Update records (1997)
Problems with [Applescript] (1997)
Installing 4.5 under 10.2 (2002)
Information on Vieworders.tpl (1998)
Cold Fusion Buster (1997)
SiteEdit NewFile.html ? (1997)
WebDNA CAPTCHA (2008)
RE: Suggestions for Topics to be covered in an Advanced WebDNACourse... (1998)
[WebDNA] v6.2 dependencies? (2010)
Progress !! WAS: Trouble with formula.db (1997)
[SearchString] usage (1997)
Attn: Bug in GeneralStore example b15 (1997)
Admin Edit prob. (1997)
insecure client not shown (1998)
Webcat bannersleuth Qs (2001)