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:
CSS in HTML emails? (2003)
Bookmarked URL with cart (1998)
OT: Alias/Shortcut on Windows server (2003)
shipping formula (2000)
page redirect in webDNA (1997)
Problems getting parameters passed into email. (1997)
Secure Server (1999)
Question about replacing words (1998)
WC2.0 Memory Requirements (1997)
multi-paragraph fields (1997)
Dashes and dots in credit card (1998)
RE: Nesting [ListFiles] (1998)
WebCat Problem? (1999)
ReturnRaw and redirect one last question (1997)
Calendar using WebCatalog? (1997)
No luck with taxes (1997)
Robots fill event log (1997)
Permission denied? (2004)
different show next (1997)
Trouble with formula.db (1997)