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

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 31593
interpreted = N
texte = 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 3A 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.HTHJohn 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 Associated Messages, from the most recent to the oldest:

    
  1. Re: unix permissions theory applied to db security? Or...? (John Peacock 2000)
  2. Re: unix permissions theory applied to db security? Or...? (John Butler 2000)
  3. Re: unix permissions theory applied to db security? Or...? (John Butler 2000)
  4. Re: unix permissions theory applied to db security? Or...? (John Peacock 2000)
  5. Re: unix permissions theory applied to db security? Or...? (Kenneth Grome 2000)
  6. Re: unix permissions theory applied to db security? Or...? (Clement Ross 2000)
  7. unix permissions theory applied to db security? Or...? (John Butler 2000)
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 3A 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.HTHJohn 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 John Peacock

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:

bug in [SendMail] (1997) back button loses cart (2000) questions on variations of Ken's [text multi=T]var1=&var2=[/text] (1999) Huge databases and RAM (1998) Assign Variable Value (1998) Transfer prob (2001) Before I Can Begin . . . (1998) Monthly Help File (1997) Re:quit command on NT (1997) Fun with Dates - finally resolved but.... (1997) WebCat2b15MacPlugin - [protect] (1997) [WriteFile] problems (1997) Redirect in 4.0 (2000) browser reliability on large file upload (2004) GoLive CyberStudio 1.0.1 (1997) [countWords]? (1997) RE: IIS4b2 and WebCatalog b19 (1997) Re[2]: 2nd WebCatalog2 Feature Request (1996) RE: 2nd WebCatalog2 Feature Request (1996) Hiding words (2000)