> > Then you can start on command operand authorization...8-) > Oh no... you gave Chucky a new idea. We'll blame you for all that > comes out of this.
Oh, we've been chatting about this one for a long, long time...he's long since corrupted. The problem is finding a way to juggle priorities to let him do it...8-) > Most CP commands right now only allow the ESM to audit, not to control > access. If the ESM gets granular access control, we need a a lot of > new error messages to reflect that. Or just one: HCPnnnnE Command option not permitted by security profile. RC=1234 Exactly what isn't permitted isn't the end user's business (to prevent gaming the system and determining what options are permitted by trial and error), but should be recorded in the ESM log. > An easy API for > RACROUTE might be nice to avoid yet-another-list of powerful users > (especially since some weasels want that all disks with lists of > powerful users are protected against reading). Takes us back to either a universal *RPI service provider built into CP that we can connect to with pipes and do our own ESM, or supplying a default ESM that's more granular than the classic CP model, doesn't it? -- db
